Prebase consonants in the USE

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?

Comments

  • John Hudson
    John Hudson Posts: 3,221
    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
    Simon Cozens Posts: 752
    edited January 2020
    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
    John Hudson Posts: 3,221
    That sounds like a bug. Have you tested with the MS and Apple USE implementations?
  • John Hudson
    John Hudson Posts: 3,221
    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>


  • 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.