Struggling to get kerning to match what SVG generates in browser...

[avisra]

I am using the following code in attempt to draw "PLAYER NAME" in the "Kelly Slab Regular" font (from google).

I need it to match an SVG preview which is being provided on the web. Here is what the SVG preview displays using CSS fonts

But when I try to generate this with SixLabors using the below code, I receive the following:

image.Mutate(ctx => ctx.DrawText(new RichTextOptions(font) { KerningMode = KerningMode.Auto, Origin = new PointF(x, y) }, "PLAYER NAME", color));

If I try changing the KerningMode to None, the Y and E get better (they no longer touch) but then there is a significantly larger gap between the A and Y. How can I get this closer to what renders in the SVG? Please keep in mind that in my application/SVG the text and font are dynamic - so I'm looking for a one size fits all solution

[avisra]

For the record, even skia sharp generates the A and Y spaced apart like the above. I was only able to fix it in SkiaSharp by using the richtext kit plugin here: https://www.toptensoftware.com/richtextkit/

I'm not sure this is helpful at all... but maybe there is something we could borrow from their plugin for glyph spacing?

And as far as the browser goes with the SVG, if I set font-kerning: none on the element - then it matches that SixLabors is producing. But if I set font-kerning: auto, it produces what you see in the blue screenshot at the top - which is something I have not been able to get SixLabors to produce

[tocsoft]

It seems like the kerning is being applied to the wrong character pair, looking at how all the character are spaced in both the 'with kerning' and 'without kerning' images when kerning is enable, the E (and subsequent letter) have been moved to the left rather than the Y moving to the right, as the AY spacing is consistent in both images.

Not that I know what the fix is or what could be causing it but it seems to effect all kerning in the font, kerning pairs targeting capital V are also effected and not just with A but things like a, o, L also trigger the behaviour.

Also this behaviour doesn't trigger with all fonts, Open Sans for example isn't affected so it must be a font specific thing where there is an in font setting that is triggering this issue.

[JimBobSquarePants]

There's a couple of different online tools I use to compare the output.

FontKit
https://fontkit-demo.vercel.app/

Crowbar (Harfbuzz)
https://www.corvelsoftware.co.uk/crowbar/

The latter is extremely useful when debugging substitution and positioning

Both get this correct.

Looking at the reference source for FontKit it becomes obvious that we have been applying the kerning offset to the wrong glyph.

Fonts/src/SixLabors.Fonts/Tables/General/Kern/KerningTable.cs

Lines 58 to 73 in e546be3

	public void UpdatePositions(FontMetrics fontMetrics, GlyphPositioningCollection collection, int left, int right)
	{
	if (this.Count == 0 || collection.Count == 0)
	{
	return;
	}
	ushort previous = collection[left].GlyphId;
	ushort current = collection[right].GlyphId;
	if (this.TryGetKerningOffset(previous, current, out Vector2 result))
	{
	collection.Advance(fontMetrics, right, current, (short)result.X, (short)result.Y);
	}
	}

Most fonts do the kerning via the GPOS tables (using Kern and VKern feature tags) so we hadn't picked up on the issue in our existing tests however this font relies on the KERN table.

A quick update to the table and calling methods and we can get the correct result.

Unfortunately, the fix will contain a breaking change because there are public calling methods that implement the wrong semantics. Unavoidable though.

[JimBobSquarePants]

PR here. #405

[avisra]

Holy moly. I was not expecting to wake up this morning to a fix. Thanks @JimBobSquarePants!!

[JimBobSquarePants]

Even better… The release is on NuGet now. 😀