GSHorizontalTypesetter improvements: Enable Kerning (Currently Disabled)

[IOOI-SqAR]

I asked the Kimi AI how to further improve GSHorizontalTypesetter. Here is what it came up with:

https://www.kimi.com/share/19d34cdb-8242-8fc9-8000-00001fd46e3b

Enable Kerning (Currently Disabled)

The kerning code is commented out as a "major bottleneck" but this significantly degrades text quality. Implement with caching:

// PROPOSED: Add kerning cache to avoid repeated font metrics calls
struct {
    NSGlyph prevGlyph;
    NSGlyph currGlyph;
    float kernAdjustment;
} *kerningCache;
size_t kerningCacheSize;

// Use conservative kerning: only query when glyph pair changes
if (lastGlyph && lastGlyph != NSNullGlyph && glyphEntry->font == font) {
    float kern = [font advancementForGlyph: lastGlyph].width + 
                 [font advancementForGlyph: glyphEntry->glyph].width -
                 [font advancementForGlyphPair: lastGlyph : glyphEntry->glyph].width;
    if (kern != 0) {
        position.x += kern;
        glyphEntry->nominal = NO;
    }
}

We should of course check if this is a bottle neck.

[DTW-Thalion]

Looking at the current code, explicit kerning from NSKernAttributeName is already applied: around Source/GSHorizontalTypesetter.m:712, position->x += glyphEntry->attributes.kern when an explicit kern attribute is set. What is missing is automatic pair kerning from the font's own kerning table. The scaffolding for it (lastGlyph, lastPosition) is present, but lastPosition is currently set and never read, which is the -Wunused-but-set-variable warning the file already emits, so no pair kerning happens.

Enabling it means querying the font for each adjacent glyph pair during layout, which is the performance concern the description mentions. I would want to measure the cost on real text before turning it on, and confirm the font API for pair advancement. It is not a quick change. @fredkiefer worth pursuing, or leave explicit kerning as-is for now?

[DTW-Thalion]

@fredkiefer thoughts on this? I am willing to take a swing at it if you feel it worth the time.

[fredkiefer]

I don't think this area is worth the effort. All these issues where AI generated and one has to admit not by a very good one. I did discuss this with Lars before he added these issues. They are not completely wrong but the AI had a very simplistic view on what should be done here and how.
In the long run we should not implement the text layout code within GNUstep, rather we should switch to libraries like Harfbuzz and PanGo. Any effort in this direction is far better spend then adding unnecessary features that make our code even slower.