Arabic ligature diacritic mis-positioning

[aaronbell]

I'm trying to understand an observed behavior in the new Cascadia Code Arabic font.

Here is a sequence used for the lam_lam_heh-ar ligature, with a couple of diacritics added:
uni0644 uni064E uni0644 uni064F uni0647

The output of such is:

With the sequence (LTR, for convenience):
lam_lam_hehar uni064E uni064F LIG
(The LIG is an empty glyph added to maintain alignment with the monospace grid)

However, the output should look like:

I can achieve this output by removing the substitution that adds the LIG character:
sub [lam_lam_heh-ar allah-ar] @vocal damma-ar' by damma-ar LIG;

As far as I can tell, the OT mark to ligature feature in the font is working as expected, and this is purely on the rendering engine side (macOS renders it correctly). It appears that the presence of the LIG character is changing how Harfbuzz analyzes the mark positioning and thus is causing the mark next to the LIG to be incorrectly positioned.

While I have a workaround (shift the position of the LIG to before the ligature), I was wondering if you could help clarify what is causing this behavior.

Thanks!

For convenience, here is the latest version of the font:
CascadiaCode.ttf.zip

[khaledhosny]

My hunch would be that splitting the damma-ar glyph is causing HarfBuzz to miscalculate what component it applies to.

[behdad]

This was done intentionally to match Uniscribe. I can't find the commit right now. But basically there was a case demonstrated by one of the popular MS fonts, whereas if first eg. A,B ligated into AB, and then that AB ligated with a C into ABC, then a mark attached to second component of that ABC expected to be positioned on C, NOT B. That is, the AB would be considered one ligature component after the ABC was formed.

What would our Uniscribe backend do?

[khaledhosny]

That would be 7b84c53.

$ hb-view CascadiaCode.ttf -u 0644,064E,0644,064F,0647

hb-view.exe CascadiaCode.ttf -u 0644,064E,0644,064F,0647 --shaper=uniscribe

hb-view CascadiaCode.ttf -u 0644,064E,0644,064F,0647 --shaper=coretext

[behdad]

That would be 7b84c53.

No not that one. Let me try harder to find.

[behdad]

No not that one. Let me try harder to find.

commit fe20c0f
https://bugzilla.gnome.org/show_bug.cgi?id=437633

[behdad]

Thinking more, this is supposed to work. Debugging.

[behdad]

Okay so when you do a MultipleSubst on a mark, we are not retaining its ligature-component properties I suppose. Let me try.

[behdad]

Should be fixed.