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.
Comments
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).
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.
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.