OpenType GPOS Lookups for Urdu

Ivan

I am trying to understand the rendering of "بڑ" (Urdu - Unicode 1576, 1681) with a font Jameel_Noori_Nastaleeq.ttf. 

The string is converted into glyphs [607, 460, 471, 1651] by the GSUB table. I can detect the correct anchor-attachment of the second glyph under the first one. But I can not find an appropriate GSUB rule, that would position the third glyph on top of the first one. Here, the left one is correct, the right one is what my program does at the moment.

Could you look into the OTF file (and possibly use your favourite software) and explain to me, what rule precisely is responsible for positioning the third glyph? I see, that the "mark" feature defines several lookup tables for that glyph (one of type 4: Mark-to-base and the rest of type 5: Mark-to-ligature), but I can not match the previous glyph with any of them.

Erwin Denissen

FontCreator reveals it is due to the second mark-to-ligature lookup:

Ivan

Oh, thank you very much! My engine could not match it with this lookup. So when looking for a preceding ligature glyph (for which the lookup is defined), we should skip all preceding mark glyphs? Even when the "ignoreMarks" flag of the lookup is not set (as it is not set in case of MarkToLigature2)?

Also, how do I choose a "component" of ligature, to which the mark should be attached to? In Mark-To-Ligature subtables, a ligature has several "components", and each component has its own attachment points (for each mark class). 

Adam Jagosz

The Adobe apps don't support Mark-To-Ligature lookups, right? All of the Adobe fonts just implement ligatures as precomposed overlapping glyphs.

John Hudson

Adobe's World Ready Composer engine does support Mark-to-Ligature lookups for Arabic and Indic scripts. I'm not sure whether it does so for European scripts.

Adam Jagosz

Is this the correct way to implement this? This is for an experimental font that aims to overwhelm with ligatures.

feature liga {
  lookup ccmp {
    sub aacute by a acutecomb;
    sub rcaron by r uni030C;
    sub i by dotlessi uni0307;
    # etc.
  } ccmp;

  lookup liga {
    lookupflag IgnoreMarks;
    sub r a by r_a.liga;
    sub b dotlessi by b_dotlessi.liga;
    # etc.
  } liga;
} liga;

Works like a charm in the browsers, MS Word, GIMP, etc.

In InDesign, only non-accented ligatures kick in. The only thing that the World-Ready Composer changes is that the ligatures with i work as well, and the tittle is positioned correctly. So the problem is rather that the app pre-emptively recomposes the diacritic glyphs right after they are separated, not allowing the ligature substitution to happen, regardless whether the first lookup is in liga or ccmp.

I don't think there is a way to work around this in Adobe apps, I've tried for a long time when working on another project.

I suppose it would be a viable workaround to provide precomposed ligatures for the most common dicaritic combinations in a handful of widely spoken languages.

John Hudson

So the problem is rather that the app pre-emptively recomposes the diacritic glyphs right after they are separated, not allowing the ligature substitution to happen, regardless whether the first lookup is in liga or ccmp.

Yes, this is a long-standing InDesign bug.

Frankly, I think Adobe should give up on all its own text processing engines and switch to Harfbuzz for all scripts, including Latin.