Autokern now kerns accents with glyphs

[SCarewe]

Hello, as per the changelog, the autokerning of glyphs involved in composites is fixed, which is great. However, I opened up Kern On on a document and found that accented glyphs were now also autokerned.

Oddly, this is only the case for accented capitals (with .case accents). as well as for gcommaaccent (which uses commaaccentcomb.alt).

Tim, you have the file I'm working on.

[Tim Ahrens]

This is strange. If I open the font with Glyphs 3249 and Kern On 1.31 then /H/macroncomb.case is not autokerned. Which version of Glyphs are you working with?

[Tim Ahrens]

Btw this is a script that can be used to inspect what Glyphs returns for certain layer and component properties:

Code: Select all

for layer in Font.selectedLayers:
    print( layer.parent.name, 'hasAlignedWidth', layer.hasAlignedWidth() )
    for c in layer.components:
        print( c, 'shouldAttach', c.shouldAttach() )
    print()

In my case, it prints:

Code: Select all

Hmacron hasAlignedWidth True
<GSComponent "H" x=0.0 y=0.0> shouldAttach False
<GSComponent "macroncomb.case" x=178.0 y=0.0> shouldAttach True

Adieresis hasAlignedWidth True
<GSComponent "A" x=0.0 y=0.0> shouldAttach False
<GSComponent "dieresiscomb.case" x=111.0 y=0.0> shouldAttach True

adieresis hasAlignedWidth True
<GSComponent "a" x=0.0 y=0.0> shouldAttach False
<GSComponent "dieresiscomb" x=77.0 y=0.0> shouldAttach True

If hasAlignedWidth True and there are multiple subsequent components with shouldAttach False then these are considered to be “ligature” type components, i.e. affected by kerning.

[SCarewe]

Odd. I tested in 3149 and 3151 and the result is the same. For Hmacron I get:

```
Hmacron hasAlignedWidth 1
<GSComponent "H" x=0.0 y=0.0> shouldAttach 0
<GSComponent "macroncomb.case" x=178.0 y=0.0> shouldAttach 0
```

So, for some reason, you get shouldAttach True while I get False for the macroncomb.case component. You might have a different version of the file, I'll send you the current one.

On a side node, how do I format code blocks and insert images in-line on this forum?

[Tim Ahrens]

What happens if you run the script in Glyphs 3.2? I cannot run any Python scripts in Glyphs 3151 because Glyphs says it cannot not find a compatible Python version.

One thing I noticed is that Hmacron seems to be completely unknown to my version of Glyphs. It doesn’t have a Unicode value and Glyphs does not even consider it to be a letter. If I may ask, why is it even in the font?

Screenshot 2024-04-02 at 17.30.55.png (173.15 KiB) Viewed 292 times

Do you have any info about it in you personal GlyphData.xml? That could explain the difference in behaviour.

Maybe specifying the missing data will help? It will certainly help Kern On generate correct autokerning. (Just like Glyphs, Kern On doesn’t know it is a letter, and it will not apply the implicit uppercase letters’ special spacing.)

On a side node, how do I format code blocks and insert images in-line on this forum?

Go to “Full Editor & Preview”, select the text and click the </> button.

[SCarewe]

Sorry. I meant 3249 and 3251. The latest 3.2.

Concerning the Unicodes: ask our client, I told him it's a ridiculous idea ;)

And it's not only the Hmacron, but a whole plethora of accented uppercase. Even Aacute, if I'm not mistaken. I'll check again tomorrow.

[Tim Ahrens]

Thanks for sending the file. Seems like we were not looking at the same file! Very similar but not identical, which made it easy to dig into it.

As it turns out, the PUA values for the .case accents are causing this strange behaviour.

What I tested:
• Open your latest file (with PUA for the .case accents).
• Check whether accented UC letters show the wrong shouldAttach values (yes, they do, i.e. False for both components).
• Remove the PUA value for the accent.
• Check whether accented UC letters show the wrong shouldAttach values (they still do, seems like this is not updated internally).
• Save, close and re-open the file.
• Check whether accented UC letters show the wrong shouldAttach values (not any more, as expected).

PUA always smells like a hack, and we always knew hacks can backfire.

On the other hand, this clearly seems to be a bug in Glyphs. The PUA accents behave like they are attached, why does the API return the wrong attached-ness? (Also, why don’t other combining accents that have a natural Unicode value trigger this bug?)

[Georg Seifert]

When you use a PUA code, the category and subcategory are set to "Private Use" and "None". if you then change the name or some other settings, the PUA code and category sticks around as that is what most people would expect. It should go back to default when the PUA code is removed.

If you need the PUA codes for the .case glyphs, you need to manually set the category/subCategory to "Mark"/"Nonspacing".

[Tim Ahrens]

Thanks for the explanation and the workaround, Georg.

I still don’t understand why you consider shouldAttach = False to be the correct return value in a case like this. The diacritic component is clearly attached (i.e. its position depends on the anchors). From a functional point of view, it does not differ at all from other attached diacritics, and one would not expect shouldAttach to depend on category or subcategory as it is irrelevant for the question.

[SCarewe]

Hello again. I've found KO now even kerns non-exporting components (such as _shoulder) against each other when I use them in a glyph (for example, I use _shoulder twice in a row in /m). The old behaviour was a lot better. Is there no other way of determining which composites need to be kerned?

[Tim Ahrens]

Whether to autokern non-exporting glyphs is an interesting question. At first glance it makes sense to automatically exclude them but there can be non-exporting glyphs in a font that should be autokerned, e.g. for fractions. So, the approach is to generously generate autokerning pairs and then disable them as necessary.

In your case, can’t you simply use “No kerning” for the glyphs (or glyph sides) in question? You only need to set it up once and the problem should be solved.

My advice is to use “No kerning” generously. It gives you peace of mind: it reliably does what it says, no questions asked. Also, it is handled on a glyph level, which is much less complicated than dealing with pairs. Checking which glyphs have “No kerning” set is also fairly easy because Kern On can give you an overview.

[SCarewe]

Yes, I understand about kerning non-exporting glyphs, which makes sense. However, if glyphs like _shoulder are exclusively used in a glyph where they are connected using #exit and #entry anchors, why should they be autokerned in the first place?

Is there any development on the issue with kerning accents and base glyphs? Is the only fix to set the case marks to Mark/Nonspacing? (And yes, I need PUA values for those in this specific case)

[Tim Ahrens]

I see. This brings up the same old question: “Find all composites in which the positioning of the components is affected by kerning.”

This was surprisingly difficult to implement, as you remember, even with Georg’s help. To be honest, the current code never felt very robust to me, and now we are seeing that it is still not correctly detecting what it is supposed to.

I will have another look and get in touch with Georg.