Glyph combinations used as components not kerned

[SCarewe]

Hello, I seem to remember this was a feature introduced with some update a while back: glyph combinations that are used as components in other glyphs (such as /one.dnom /fraction in /onehalf) were kerned by Kern On, regardless of importance on the pair frequency list.

In my example, I have /careof and /accountof created using /c.sups, /fraction, /o.dnom, /a.sups and /c.dnom. However, the combinations I didn't define in models (for example, /c.sups /fraction) are not kerned.

Same for /f_f /l, by the way, which I both have in /f_f_l, despite having defined /f /l as a model.

Is this the intended behaviour and if not, why?

[Tim Ahrens]

Hello, I seem to remember this was a feature introduced with some update a while back: glyph combinations that are used as components in other glyphs (such as /one.dnom /fraction in /onehalf) were kerned by Kern On, regardless of importance on the pair frequency list.

Yes, this is how it should work since about a year ago.

It’s strange that these pairs are not kerned in your case.
Can you send me the file?

[Tim Ahrens]

Thanks for the file. This is a bug in Glyphs that was introduced at some point in 2023. I reported it to Georg in December.

To demonstrate it you can use:

Code: Select all

for layer in Font.selectedLayers:
    print( layer.parent.name )
    for c in layer.components:
        print( c, c.alignment, c.alignmentType() )
    print()

In some cases Glyphs returns the wrong alignmentType.

Two examples from your font:

Code: Select all

careof
<GSComponent "c.sups" x=0.0 y=0.0> 0 2
<GSComponent "fraction" x=337.0 y=0.0> 0 3
<GSComponent "o.dnom" x=592.0 y=0.0> 0 2

onehalf
<GSComponent "one.numr" x=0.0 y=0.0> 0 3
<GSComponent "fraction" x=309.0 y=0.0> 0 3
<GSComponent "two.dnom" x=536.0 y=0.0> 0 3

3 is GSAlignmentHorizontal and correct whereas 2 is GSAlignmentAligned and wrong. At least this is inconsistent; I cannot see any reason why onehalf and careof are not identical in terms of the role and positioning of the components.

Kern On checks for GSAlignmentHorizontal, this is why it fails to detect the kerning pairs in careof.

Sorry but it seems we need to convince Georg to fix this, at least I cannot think of a different mechanism that works as a work-around.

[Georg Seifert]

What distinction do you base on that property?

[Tim Ahrens]

I need to identify composite glyphs in which the positioning of the components is affected by kerning.

[Georg Seifert]

can you try `Layer.hasAlignedWidth()`

[Tim Ahrens]

You mean something like this?

Code: Select all

for layer in Font.selectedLayers:
	if not layer.hasAlignedWidth():
		continue
	kernedComponents = []		
	for c in layer.components:
		if c.alignment == 0:
			kernedComponents.append(c.name)
	if len(kernedComponents) >= 2:
		print( layer.parent.name, kernedComponents )

No, this also catches ordinary accented letters.

[Tim Ahrens]

Btw, I am working in Objective C, of course. Georg, you can see the current code in the shared Github repo.

[Tim Ahrens]

Next attempt:

Code: Select all

for layer in Font.selectedLayers:
	if not layer.hasAlignedWidth():
		continue
	pairs = []
	prevComponent = None
	for c in layer.components:
		if c.alignment == 0 and prevComponent and prevComponent.alignment == 0:
			if c.alignmentType() == 3 or prevComponent.alignmentType() == 3:
				pairs.append(prevComponent.name + c.name)
		prevComponent = c
	if pairs:
		print( layer.parent.name, pairs )

This correctly identifies all required kerning pair but it also outputs wrong, anchor-based composites.

[Tim Ahrens]

Using this code:

Code: Select all

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

I am getting this output:

Code: Select all

onehalf hasAlignedWidth? True
<GSComponent "one.numr" x=0.0 y=0.0> 0 3
<GSComponent "fraction" x=309.0 y=0.0> 0 3
<GSComponent "two.dnom" x=536.0 y=0.0> 0 3

ordfeminine hasAlignedWidth? True
<GSComponent "a.sups" x=0.0 y=0.0> 0 3
<GSComponent "_ord.bar" x=-6.0 y=1.0> 0 3

This means that, based on the properties I can request, it seems impossible to reliably distinguish between anchor-based composites and kerning-based composites in the current version of Glyphs (it did work with the Glyphs version from about a year ago). It’s a bit frustrating to see that changes in Glyphs are breaking a functionality of my plug-in and I am wasting my time trying to fix things.

Any ideas?

[Georg Seifert]

Can you try this in 3.1.2? That was released before you got it to work. And in it, I get the same results for your script in 3.1 and the latest 3.2. And if I look at the code, I can’t see why it should?

[Tim Ahrens]

I can’t test the script in 3.1.2 as it complains about missing Python 3. I am certain that is worked at some point, as I tested it when I implemented it in February 2023.

In any case, I think what Kern On needs to detect is clear: Composites in which kerning affects the positioning. It would be very good if that could be achieved again.

[SCarewe]

Has there been any progress on this? It would be really great to be able to properly determine kerning-affected composites like Kern On wants to. I currently need to manually set auto pairs.

[Tim Ahrens]

Yes, we finally got it to work last week! I sat down with Georg to resolve this. It will be included in the next release.

Do you want me to send you my current in-house version if it’s urgent?

[SCarewe]

Thanks for the offer, that's very kind, but it's not too urgent. I have simply set the affected pair to auto in all masters.

Thanks to you and Georg for getting to the bottom of this!