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?
Comments