Re: Choosing the Set of Renderable Strings

On Thu, 17 May 2018 21:50:38 -0800
James Kass via Unicode <unicode_at_unicode.org> wrote:

> Richard Wordingham wrote,
>
> ⇒ Your example appears to be using the font called 'A Tai Tham KH
> New'.
>
> Exactly. The black boxes in the display were becoming tiresome. The
> font package is available from this Tai Tham web page:
> http://www.kengtung.org/download-font/
>
> (I'd downloaded a copy of "lamphun.otf", but the installer failed, so
> I had to go a-hunting.)

That threatens a long struggle. The WOFF files work on MS Edge on
Windows 10. Lamphun (and Da Lekh) depends on the rendering engine for
Indic reordering; more precisely, it relies on dotted circles to know
when reordering has failed. I don't think it can work possibly via
Uniscribe and DirectWrite.
 
> Is it correct to say that the average daily Tai Tham use is already
> being more-or-less served by the current state of the fonts and the
> USE?

Many fonts depend on bypassing the USE. I also have a strong suspicion
that they depend on HarfBuzz, though I'll have to recheck what is
happening on iPhones. I'm only set up there to check what happens with
Safari.

> And that many of the problems you are reporting with respect to
> things such as mark-to-mark positioning are happening with more exotic
> uses of the script, such as the input and display of Pali texts using
> the Tai Tham script?

Since changes to Indic Syllabic category for Unicode 10 unbanned
talk about nirvana (ᨶᩥᨻᩛᩣᨶ <NA, SIGN I, LOW PA, SIGN LOW PA OR HIGH
RATHA, SIGN AA, NA>, or with TALL AA instead; the vernaculars usually
inserts SAKOT before the second NA) and Tai Khuen (and Tau Lue?) monks'
names -in -dhammo (-ᨵᨾᩜᩮᩣ), the USE should have supported
uncontracted Pali. Pali is simple, though inter-Indic is complicated by
subscript forms not encoded with SAKOT. (There may be a similar
complication with the Myanmar script.)

The complications primarily come with writing the vernacular.
 
> ⇒ And how am I supposed to position MAI SAM to the right of the
> ⇒ rightmost of the level 1 marks above?

> Beats me, it's not happening here. If the GPOS look-up is for (e.g.)
> TONE-1 plus MAI SAM, and the string is being re-ordered by the system
> to MAI SAM plus TONE-1 before being submitted to the font, then *that*
> look-up won't happen. In which case, change the look-up to accomodate
> the re-ordered string. I suppose you've already tried that.

What makes you think the USE tries to address such matters? If the
developers had made the time to find out about such details (I think
their money tree must have died), we wouldn't have a problem with CVC
askharas. Also, the USE prohibits spelling where this rearrangement is
desirable. Hariphunchai and therefore Lamphun addresses the
positioning by having a separate position for MAI SAM, but that doesn't
work well when there is a top vowel in the syllable.

Now, the use of MAI SAM to indicate elision, as opposed to duplication
at the word or syllable level, is somewhat 'exotic'; many writers don't
do it. It's the use to indicate elision, written in accordance with
the accepted proposal, that the USE prohibits.

> ⇒ The correct sequence is <LOW PHA, SIGN E, SIGN AA, MA, NA, SIGN E,
> ⇒ SIGN AA>, which is rendered by the Lamphun font as shown in the
> ⇒ attached PNG file.
>
> ᨽᩮᩣᨾᨶᩮᩣ
> To confirm, the NAA ligature isn't happening with the 'A Tai Tham KH
> New' font.
>
> Changing the entry order to:
> ᨽᩮᩣᨾᨶᩣᩮ
> <LOW PHA, SIGN E, SIGN AA, MA, NA, SIGN AA, SIGN E>
> ... forms the NAA ligature and the vowel re-ordering matches the
> Lamphun graphic you sent. But that kludge probably breaks the
> preferred encoding model/order.

Exactly.

Richard.
Received on Fri May 18 2018 - 02:57:40 CDT