LTR ligatures work with U+2D7F but not with U+200D; RTL ligatures don't work

[simoncozens]

Older versions of this font did not have a languagesystem tfng dflt declaration, and went through the standard shaper. We've added one, meaning that the font now goes through the USE.

The font has a lookup in ccmp to form ligatures and it looks like this:

    sub yam-tifi uni200D yah-tifi by yam_yah-tifi;
    sub yam-tifi consonantjoiner-tifi yah-tifi by yam_yah-tifi;

With no tfng script declaration:

$ hb-shape master_ttf/NotoSansTifinagh-Regular.ttf -u 2d4e,2d7f,2d40,2d4e,200d,2d40
[yam_yahtifi=0+740|yam_yahtifi=3+740]

With tfng:

$ hb-shape master_ttf/NotoSansTifinagh-Regular.ttf -u 2d4e,2d7f,2d40,2d4e,200d,2d40
[yam_yah-tifi=0+740|yam-tifi=3+557|space=3+0|yah-tifi=5+779]

Oops, ccmp is scoped to the cluster and U+200D is in a different cluster, so no ligature. (I think I remember @dscorbett suggesting that this behaviour with a bug, but it certainly is the current behaviour so we've got to work with it.)

What to do, I wonder? Remove the tfng declaration and go through the standard shaper?

Another issue is that when the direction is set to RTL, Very Strange Things happen with reordering, regardless of whether there is a tfng languagesystem or not:

$ hb-shape -V master_ttf/NotoSansTifinagh-Regular.ttf -u 2d4e,2d7f,2d40,0020,2d4e,200d,2d40 --direction=rtl
trace: start reorder    buffer: <U+2D40=6|U+2D4E=4|U+200D=4|U+0020=3|U+2D40=2|U+2D4E=0|U+2D7F=0>
trace: end reorder  buffer: <U+2D40=6|U+2D4E=4|U+200D=4|U+0020=3|U+2D40=2|U+2D4E=0|U+2D7F=0>

Notice that even before Harfbuzz starts reordering, things have moved around. The buffer has been reversed, which I would not have expected, but the U+200D and U+2D7F joiner glyphs have stuck to their cluster, meaning that you have to write rules like:

sub yah-tifi yam-tifi.RTL consonantjoiner-tifi by yam_yah-tifi.RTL;

for anything to work.

This just seems wrong to me, and perhaps for that reason, RTL ligatures have never worked in this font particularly well (unless I completely don't understand how they should work):

$ font-v report ~/Downloads/android_fonts-master/api_level/28/NotoSansTifinagh-Regular.ttf

/Users/simon/Downloads/android_fonts-master/api_level/28/NotoSansTifinagh-Regular.ttf:
----- name.ID = 5:
Version 1.05 uh
----- head.fontRevision:
1.050
$ shape ~/Downloads/android_fonts-master/api_level/28/NotoSansTifinagh-Regular.ttf -u 2d4e,2d7f,2d40,0020,2d4e,200d,2d40 --direction=rtl
[gid20=6+1755|gid34=4+1325|gid3=4+0|gid3=3+532|gid20=2+1755|gid34=0+1325|gid62=0+0]

$ shape ~/Downloads/android_fonts-master/api_level/28/NotoSansTifinagh-Regular.ttf -u 2d4e,2d7f,2d40,0020,2d4e,200d,2d40 --direction=ltr
[gid65=0+1455|gid3=3+532|gid65=4+1455]

Coupled with #8, I wonder if the RTL version of this font is actually functional. I don't have enough expertise with Tifinagh to know.

So things we need to decide:

• Remove the tfng declaration and go through the standard shaper to make ZWJ work as a joiner, or not?
• What to do (if anything) about RTL support?

[dscorbett]

The default shaper is sufficient for Tifinagh, but if you do want to use USE, which might be a requirement for pyftmerge, you can just do all the U+200D and U+2D7F ligatures in 'rlig'.

The “Very Strange Things” are happening because HarfBuzz does not include Tifinagh in its list of scripts that can go in either direction (https://github.com/harfbuzz/harfbuzz/issues/1000). There is no standard for which scripts get that treatment: they are only added to HarfBuzz when someone finds a problem in a particular font.

[moyogo]

For U+200D in tfng, it doesn’t seem to work in ccmp on Windows with Uniscribe with Ebrima either.

Using rlig instead of ccmp seems to work! Thanks @dscorbett

[simoncozens]

266263e will fix this if that Harfbuzz PR gets merged.

[simoncozens]

That PR Is merged and the fix is in, so this should be fixed going forward.