Autokern now kerns accents with glyphs

Post Reply
User avatar
SCarewe
Posts: 109
Joined: 23 Apr 2021

Autokern now kerns accents with glyphs

Post by 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.
Attachments
Screenshot 2024-03-28 at 23.09.55.png
Screenshot 2024-03-28 at 23.09.55.png (374.14 KiB) Viewed 14671 times
User avatar
Tim Ahrens
Site Admin
Posts: 440
Joined: 11 Jul 2019

Re: Autokern now kerns accents with glyphs

Post by 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?
User avatar
Tim Ahrens
Site Admin
Posts: 440
Joined: 11 Jul 2019

Re: Autokern now kerns accents with glyphs

Post by 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.
User avatar
SCarewe
Posts: 109
Joined: 23 Apr 2021

Re: Autokern now kerns accents with glyphs

Post by 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?
User avatar
Tim Ahrens
Site Admin
Posts: 440
Joined: 11 Jul 2019

Re: Autokern now kerns accents with glyphs

Post by 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
Screenshot 2024-04-02 at 17.30.55.png (173.15 KiB) Viewed 14573 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.)
SCarewe wrote: 02 Apr 2024 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.
User avatar
SCarewe
Posts: 109
Joined: 23 Apr 2021

Re: Autokern now kerns accents with glyphs

Post by 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.
User avatar
Tim Ahrens
Site Admin
Posts: 440
Joined: 11 Jul 2019

Re: Autokern now kerns accents with glyphs

Post by 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?)
User avatar
Georg Seifert
Posts: 8
Joined: 29 Jul 2019

Re: Autokern now kerns accents with glyphs

Post by 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".
User avatar
Tim Ahrens
Site Admin
Posts: 440
Joined: 11 Jul 2019

Re: Autokern now kerns accents with glyphs

Post by 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.
User avatar
SCarewe
Posts: 109
Joined: 23 Apr 2021

Re: Autokern now kerns accents with glyphs

Post by 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?
User avatar
Tim Ahrens
Site Admin
Posts: 440
Joined: 11 Jul 2019

Re: Autokern now kerns accents with glyphs

Post by 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.
User avatar
SCarewe
Posts: 109
Joined: 23 Apr 2021

Re: Autokern now kerns accents with glyphs

Post by 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)
User avatar
Tim Ahrens
Site Admin
Posts: 440
Joined: 11 Jul 2019

Re: Autokern now kerns accents with glyphs

Post by 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.
User avatar
SCarewe
Posts: 109
Joined: 23 Apr 2021

Re: Autokern now kerns accents with glyphs

Post by SCarewe »

I'm running into a sort of counter-issue: I have a /percent glyph made up of: /_zero-percent-top, /fraction and /_zero-percent (not the best namings, don't blame me). They are, of course, auto-aligned.

Kern On correctly autokerns /_zero-percent-top with /fraction, but not /fraction with /_zero-percent. I have to manually activate autokerning for the latter. Why? Would the file help?

I noticed that the "top" component doesn't have a warning triangle in Kern On, whereas the "bottom" component does. Both are set to non-exporting.

BTW I still don't understand how I'm supposed to paste an image in-line, dragging the file onto the editor (in "Full Editor" mode) only adds it as an attachment.
Attachments
Screenshot 2024-05-10 at 11.55.38.png
Screenshot 2024-05-10 at 11.55.38.png (272.52 KiB) Viewed 13292 times
Post Reply