Cursive Positioning handling in Uniscribe, CoreText and Harfbuzz

Simon CozensSimon Cozens Posts: 433
edited July 2 in Font Technology
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], ;

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 CozensSimon Cozens Posts: 433
    (Update: I reckon there is a CoreText bug, so I filed feedback ID FB7841236.)
  • 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 CozensSimon Cozens Posts: 433
    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 CozensSimon Cozens Posts: 433
    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.
  • 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.
  • Those kinds of glitching and confusion makes me want to use a renderer that does not handle directionality or combining, etc. whatsoever.
Sign In or Register to comment.