Prebase consonants in the USE

Simon Cozens

Microsoft's USE guide says this: (emphasis mine)

Cases which require reordering should use the 'pref' feature to identify the glyph or glyphs that is or are to be reordered. Rather, the font designer is expected to use the 'pref' feature to signal when a glyph belonging to this class should be reordered through the application of the pref feature.

What does this mean? How do you use an OpenType feature to "identify" a glyph or send a "signal"? Do you really signal to the shaper that it "should" do the reordering for you?

Would it be more accurate to say "Prebase medial consonants (CONS_MED_PRE) do not get reordered automatically by USE. If you need this, do it yourself using the 'pref' feature" - or am I missing something really clever?

John Hudson

My understanding is that USE will reorder output from the pref feature to before the base, and this means the pref feature can, conceivably, take a glyph as input and as output, and in this manner signal to USE that the glyph should be reordered.

In Javanese, which is processed by USE, I use a contextual substitution in the pref feature to convert the medial Ra into a pre-base stub form in some contexts. It's a nice trick.

Simon Cozens

Ah, OK. That is really clever. I am having trouble getting it to work in Harfbuzz though:

$ cat javanese.fea
feature pref {
    script java;
    sub uniA9BF by glyph01;
} pref;
$ hb-shape Fallback-Javanese.otf -u 'A995 A9BF'
[uniA995=0+600|glyph01=0+600]

The substitution is done correctly (pref feature processed) but the reordering doesn't happen. Digging into the Harfbuzz source a bit, it looks like the substitution flag on the glyph is being set, but is cleared somewhere and is not set when it comes to record which glyphs were affected by the pref feature.

Is this a bug or is (more likely) my expectation incorrect?

John Hudson

That sounds like a bug. Have you tested with the MS and Apple USE implementations?

John Hudson

This is the pref GSUB lookup from the Javanese Text font (in VOLT syntax):

ꦏꦿ but ꦙꦿ</code>DEF_LOOKUP "j.pref._RaMed" PROCESS_BASE PROCESS_MARKS "j.marks_below_all" DIRECTION LTR
EXCEPT_CONTEXT
 LEFT GLYPH "jPangkon"
 LEFT GROUP "j.X.2postscript"
END_CONTEXT
IN_CONTEXT
 LEFT ENUM GLYPH "jQa" GLYPH "jJnya" GLYPH "jJha" END_ENUM
 LEFT GLYPH "jPangkon"
 LEFT GROUP "j.letters_full"
END_CONTEXT
IN_CONTEXT
 LEFT GLYPH "jPangkon"
 LEFT GROUP "j.X.2subscriptpref"
END_CONTEXT
IN_CONTEXT
 LEFT ENUM GROUP "j.base.3070" GLYPH "jRaAgung" END_ENUM
 LEFT GLYPH "jPangkon"
 LEFT ENUM GROUP "j.X.2cr.1940" GROUP "j.X.2cr.2480" END_ENUM
END_CONTEXT
IN_CONTEXT
 LEFT ENUM GROUP "j.base.2480" GLYPH "jSha" END_ENUM
 LEFT GLYPH "jPangkon"
 LEFT GROUP "j.X.2cr.1940"
END_CONTEXT
IN_CONTEXT
 LEFT GLYPH "jPangkon"
 LEFT GROUP "j.X.2cr.all"
 RIGHT GLYPH "jSignU"
END_CONTEXT
IN_CONTEXT
 LEFT GLYPH "jJha"
END_CONTEXT
IN_CONTEXT
 RIGHT GLYPH "jSignUu"
END_CONTEXT
AS_SUBSTITUTION
SUB GLYPH "j_RaMed"
WITH GLYPH "j_RaMed.pre"
END_SUB
END_SUBSTITUTION
END
</pre><div>Some of the contexts are complicated because the pref lookup is the first one applied and, because it is pre-reordering, all the contexts have to be expressed as the glyphs are delivered straight from cmap.<br><br>This works fine with both the Windows and Apple implementations of USE:<br><img src="https://us.v-cdn.net/5019405/uploads/editor/rt/r5ogavrphkxj.png" alt="" title="Image: https://us.v-cdn.net/5019405/uploads/editor/rt/r5ogavrphkxj.png"><br>The test string is KRa vs JhRa:<br><pre class="CodeBlock"><code>

Simon Cozens

Yes, it looks like I've unearthed a Harfbuzz bug. CoreText performs the reordering correctly. The issue is related to HB stashing internal information in the GDEF data, which seems to fail when no GDEF information is provided for the glyphs involved.