Anchors on RTL Ligatures

[clsn]

When editing anchors on a ligature glyph that is meant for use in an RTL script, you can get a modal dialog box complaining that the anchors are out of order. What's worse is that once you hit "OK", fontforge apparently tries to fix the problem by incrementing the ligature-element index of the anchor, which only causes the same error again, and no matter what you try you aren't given a chance to fix the problem; the program goes into an endless loop that you have to kill it out of. (This may actually not be specifically due to the ligature being RTL, but it's what's causing the problem for me, since the anchors kind of need to be "out of order" in such a case. There's no way to tell FF that the direction of writing is RTL.)

Note that I mean a ligature glyph that is not a normal Unicode-encoded glyph, but an unencoded glyph (or one in the PUA, which is universally LTR per Unicode). Working on cooking up an example; there are a lot of moving parts to this bug.

Maybe make the error non-modal, or not try to "correct" the problem? I've managed some workaround because if you order your activities right, you can enter an "invalid" location and have it not get around to checking it.

[clsn]

OK, attaching an example (based on a font from the Culmus project, so there should be no IP problems). Attached here as a .txt file because Github doesn't let me attach an sfd.

Note the anchor for ordinary base chars and for ligatures, with two combining marks using it. The ordinary anchor is added to a few characters, just for demonstration purposes. Note the ligature character, "shel_liga" (not a standard Hebrew ligature, not encoded in Unicode), which has two ligature-base anchors, with the left one numbered #2 and the right one #0, which is what we want, because Hebrew is RTL (why #2 and not #1? Not sure; it works, though).

Open the shel_liga glyph, select the left vowel-anchor, and hit Ctrl-I to edit its information. Hit the up-arrow next to its X-coordinate, as if to move it a pixel to the right. You'll get an error message about how it's out of order. Hit "OK". The error message comes back again, immediately, and again and again as you hit "OK" each time, as the FF keeps increasing the X-coordinate in the hopes it'll eventually get big enough to pass the other anchor. Which it eventually will, but I think asking the user to hit "OK" several hundred times still counts as a bug. You basically cannot do anything else while this is being handled; you have to kill the process. OR, hit the up-arrow next to the Ligature Index, to increase the ligature-index. Again, you'll get an infinity of modal dialog boxes, as FF endlessly increases the ligature index this time. (after nine or ten error messages, FF seems to notice something is wrong, as it gives a different error message, that the index is much larger than the next one, but then it goes back to trying to fix it the same way.) This won't even fix after hundreds of "OK" clicks.

LigExample.sfd.txt

[iorsh]

This should not be an error at all, at most warning. There is no requirement that anchors actually follow the writing direction (https://learn.microsoft.com/en-us/typography/opentype/spec/gpos#MLP).

[clsn]

If it really isn't a requirement, it def shouldn't be an error. It doesn't even make sense: I could easily imagine a writing system where the elements of a ligature aren't necessarily in the right order. In fact, as I understand it, in the LAM-ALEF ligature in Arabic, ﻻ, in one version of the orthography, the upright on the right (the first one) is the ALEF and not the LAM, see https://www.unicode.org/L2/L2022/22025-aldani-alefs.pdf

I'll slice out the check and put it up as a PR, or someone else can do a more elegant job.