Broken fonts: Noto Looped Thai and Noto Looped Lao

[ohbendy]

Unfortunately the FontMake build process failed to build the mark positioning correctly for our Noto Looped fonts, and every mkmk combination is broken:

Thai:

Lao:

Likewise, two marks below fail:

Lao:

These combinations work fine when exporting directly from Glyphs, but the mkmk feature seems to have gone awry. My suspicion is that it failed because we used a 'replace feature' custom parameter on the KERN and MKMK features, to be able to input different values in each instance. Perhaps FontMake didn't know what to do with that and then didn't write any code at all for those features. (IIRC Marek had also asked us to copy those custom parameters to the Master settings as well as the instances, but I can't remember the thinking there.)

Marek has now removed the broken fonts from the repo until we can fix this issue, as we don't want broken versions of them to start circulating.

[marekjez86]

@simoncozens : @ohbendy said you might look at it

[marekjez86]

@ohbendy : I believe it also applies to the UI font versions ( NotoLooped{Lao,Thai}UI ) but please confirm

[ohbendy]

Indeed it does, those are broken in the same way.

[simoncozens]

Will take a look tomorrow. Replace Feature sounds a likely culprit.

[behdad]

What does Glyphs "replace feature" do?

[twardoch]

In a custom parameter, you can provide a different feature definition for a given instance than the one defined in the main definitions (which are per font project).

[simoncozens]

OK, I see the problem. Replace feature is fine as far as I can see. The problem is with ufo2ft's handling of a manual mkmk. Not the issue mentioned above, which is just about how ufo2ft orders mark classes, but the order of the mark/mkmk features.

You specified a manual mkmk feature. ufo2ft then added (1) an automatic mark feature and (2) an automatic mkmk feature. It put (2) in the correct place before your manual mkmk. However, it put (1) at the end of the feature file. Because features are processed in the order of lookups, the mkmk gets done first and then the mark, with predictably wrong results.

A simple workaround is to add a manual mark feature just containing automatic code. I'll provide a PR to do this. A better fix is to ensure that ufo2ft outputs its automatic features in the right order.

(An even better fix is for ufo2ft to use fontFeatures, which was actually designed for this kind of thing. ;-)

[ohbendy]

Thank you so much Simon. That explains why the manual 'replace feature' for KERN was still working while the MKMK was not.

[simoncozens]

@ohbendy, I'm just testing the Lao now and I want to confirm the correct text sequence:

• ກ່ຼຸ (ko, mai-ek, lo, u) now shapes with the u under the lo.
• ກຸ່ຼ (ko, mai-ek, u, lo) forms a collision.

I'm presuming that the first sequence (lo-u) is how the text should be keyboarded, and you don't expect to have swap lookups so that u-lo gets automatically changed to the right order?

[ohbendy]

Tonemarks always come after vowel marks above and below in Thai and Lao so the correct ordering would be <consonant> <coeng Lo> <vowel> <tonemark> or for these sequences ko, lo, u, mai ek. There's no reordering for those sequences, but we did put in reordering with the phinthu and combining macron below in the Thai fonts because the canonical order of combining marks gives the wrong sequences.

[simoncozens]

That would explain the dotted circles in my github post, then. :) Great, I will add ກຼຸ່ to the regression test. (It passes, now that my fix has been applied.)

[ohbendy]

The Noto Looped Thai fonts are published again at https://fonts.google.com/noto. No sign of the Looped Lao there.

Still broken however.