Cursive Positioning handling in Uniscribe, CoreText and Harfbuzz

Simon Cozens

I've found some interesting differences in the way cursive positioning is handled in the above shapers. Attached are two simple test fonts, with six glyphs - space, uni0628, uniFE91, uni06D2, uniFBAF and nukta. The isolated forms for glyphs uni0628 and uni06D2 are a cross situated on the baseline (Y=0). The nukta mark is situated below the baseline at around Y=-80. The feature code for the two fonts is as follows:

languagesystem arab dflt;
table GDEF {
	GlyphClassDef [uni0628 uni06D2 uniFE91 uniFBAF], , [nukta], ;
} GDEF;

feature init { sub uni0628 by uniFE91;       } init;
feature fina { sub uni06D2 by uniFBAF;       } fina;

feature ccmp { sub uni0628 by uni0628 nukta; } ccmp;

feature curs {
	lookupflag IgnoreMarks;
  pos cursive uniFBAF <anchor 701 525> <anchor NULL> ;
  pos cursive uniFE91 <anchor NULL> <anchor 11 100> ;
} curs;

Additionally the "rtl" font has "lookupflag IgnoreMarks RightToLeft" in the curs feature. Notice that the nukta mark has no anchors. Here's how the character string "628,6d2,20,6d2" is drawn in each font and shaper:



I don't have access to a Windows box, but my experiments with WINE and Uniscribe suggest that Uniscribe agrees with Harfbuzz in both cases.

Analysis: in the RightToLeft case, I think Harfbuzz is obviously correct and CoreText is obviously wrong. The cursive attachment rule tells it to IgnoreMarks, but CoreText does not ignore them, and raises the mark up above the baseline. (But then I would say that, because Harfbuzz is giving me the answer I like.) In the normal case, I don't know what is going on.

Is there a CoreText bug here, and if so, how do I best report it?

Simon Cozens

(Update: I reckon there is a CoreText bug, so I filed feedback ID FB7841236.)

Kamal Mansour

I'm pretty confident that CoreText doesn't have a bug in handling cursive attachment because it can handle Noto Nastaliq without any problems. Following is a simple test in Textedit of the text 0628, 06D2 set in both fonts (macOS 10.15.5 Catalina):

Simon Cozens

Thanks; I'm on 10.14, so maybe the bug is already fixed. Noto Nastaliq always attaches its mark glyphs, so is not really a test for this bug, which is about unattached mark handling.

Simon Cozens

Yeah, confirmed that this is fixed in 10.15 and iOS 13. This is really good news as it suggests a very simple approach to out-of-line mark positioning.

Kamal Mansour

I agree. It shouldn't meddle with an unattached mark, as in this case when the initial form of 0628 is raised to attach to 06d2.

Piotr Grochowski

Those kinds of glitching and confusion makes me want to use a renderer that does not handle directionality or combining, etc. whatsoever.