DirectWrite and the Unicode PUA -Can they work together?

Daniel Yacob

Greetings,

This is a follow-up of sorts to the question that I posted last August.  Where this time I am stuck getting a substitution to work using symbols that are entirely in the Unicode Private Use Area. I recall that DirectWrite would have problems with text segmentation across scripts.  In this case, no script code is applicable, but all symbols are all within the same Unicode block. Is there a languagesystem code that is appropriate for unknown or undefined script?

The simplest form of the failing substitution under the PUA:

feature rlig {
   sub uniE01E uniE0A2 by uniE0C1;
} rlig;

Actually, the substitution does work in web browsers and LibreOffice, but not in Microsoft Word (Word for Mac 2021, Windows Word 2019), which is where I need it most. Oddly, Word's "Formats > Fonts > Advanced" Preview pane will display the correct substitution, it just won't appear in the body of a document as expected.

I've tried a number of variations to no avail,  using liga, ccmp, or a codeless glyph like uniE01D_uniE0A2.  Is there an OT or Word setting that I could be missing?

A 2nd question while I'm at it... In the above example, for efficiency, I'd like to express a list substitution in the form:

sub @consonants vowelA by @syllablesA;

Where the matching index in @consonants is used to reference the appropriate element in @syllablesA , and vowelA does not appear in the output. I haven't found a solution yet. Is this just not a possibility in OpenType?

thank you!

-Daniel

Peter Constable

In terms of OpenType Layout table formats, languagesystem tag isn't ever a blocking issue because the ScriptTable format has an offset to a default LangSys table that doesn't involve a languagesystem tag at all.

>Is this just not a possibility in OpenType?

Since you're not editing OTL tables directly, I think that question should really be worded "... using feature syntax FOO".

What you're asking about pertains to ligature substitutions, and for runtime operational reasons the formats are designed to have an array of LigatureSet subtables organized around the first glyph in each substitution. So, in your example, the number of LigatureSet subtables would be the number of glyphs in @consonants. The GSUB table formats don't allow organizing the data around a non-initial glyph in the input sequence.

However, that doesn't mean that font development tools used to describe ligature lookup actions couldn't support expressing actions in the way you're looking for. For example, Microsoft VOLT supports that.

Peter Constable

You didn't mention what script tag you were organizing your 'rlig' feature and its ligature lookup under. Itemizers in both DWrite and GDI/Uniscribe will map PUA characters (script = Zzzz) to the 'DFLT' script tag. It's possible for an app to itemize differently, but I wouldn't expect taht.

Daniel Yacob

Thank you @Peter Constable .  One of the permutations I tried was to add "script zzzz;" within the rlig block.  But it had the effect of making the ligature not work in the "Preview" window (with still no substitution in the document view).

Having no "script" statement present at least allowed the substitution to appear in the "Preview", window so I thought I was on the right track.

The document language is the default en-US, perhaps I need to configure it to use the "Zzzz"?

Peter Constable

The tag 'zzzz' is not a valid OpenType Layout script tag. The tag should be 'DFLT'.

You haven't mentioned what tools you're using, which could help. 

Daniel Yacob

I'm working with FontLab 8.3 and generated the TTF (OpenType TT) font directly.  Additionally exporting to UFO format and building the TTF font with fontmake.  The outcome has been the same though.

Thanks for correcting me on the script code -FontLab and fontmake didn't produce a warning.  They both did produce an error message when I used "dflt".  I didn't read error message carefully enough, they both indicate that "DFLT" should be used. 

I've tried with DFLT now after reading your reply, and it's back to the behavior where it is broken in Word's Font Format Preview.  It seems Preview doesn't want any script setting. 

thanks,  -Daniel

Peter Constable

Can you provide a screenshot of the UI where it isn't working?

Daniel Yacob

Seen below in Word for Mac v16.82 with Mwangwego letter GHO as a simple test case.   In the document body the diacritic is split from the letter base, the substitute glyph has not been applied.  However, in the Preview pane (Format > Font Advanced > Preview) the correct substitution has occurred (you may need to zoom in to see it).  This is the mystery that brought me here.  I greatly appreciate your persistence here in investigating the issue 

The "fl" ligature is thrown in as a sanity check to verify that ligatures are otherwise working ok.