Finding glyph control point information in recent versions.

[Mavichist]

Hi all,

Back in 1.0.0-beta13, it was possible to access the control point information for any glyph via the GlyphInstance class. This appears to have been abstracted away, the GlyphInstance class being refactored out.

Is there an equivalent way to access control point information these days? I've been combing through the repository and much of what I can find is internal or inaccessible.

Regards, Mavi

[JimBobSquarePants]

The property now lives in Glyph.GlyphMetrics.CodePoint.

You can also use the SpanCodePointEnumerator and SpanGraphemeEnumerator to enumerate through strings to analyze codepoint information.

[Mavichist]

Resurrecting this question as the API appears to have changed again in the latest version. The CodePoint class doesn't appear to contain any information pertaining to control points and glyph contour geometry. I know mine is a niche use-case in the wider context of the library, but it is nonetheless a powerful feature to be able to access this information, and I'd love to stay abreast with the latest library version if possible.

Where is this information now located and is it still publicly accessible?

Regards, Mavi.

[Mavichist]

For some context; this is the kind of information I would like to be able to access (and have been able to access in the past):

https://github.com/SixLabors/Fonts/blob/30c8f15fda01ac1cfd49ed8130d7f9af0ad4fdee/src/SixLabors.Fonts/Tables/TrueType/Glyphs/ControlPoint.cs

The above is True-Type-specific, and I live in hope that there may be a publicly-available abstraction I've missed that exposes this kind of information publicly. There was a time previously when this was possible and quite invaluable to me.

[JimBobSquarePants]

The method returns the glyphs for that codepoint, not all of them for the font. We’ve never exposed the raw control points. You can get the vectors from the glyph.

[JimBobSquarePants]

BTW. The API has been stable now for two major versions.

[Mavichist]

We’ve never exposed the raw control points.

The API did indeed expose them in an earlier beta version as described here by the ControlPoints, OnCurve and EndPoints properties. I am searching for equivalent functionality in the current API.

You can get the vectors from the glyph.

Forgive me, but, how? I see no mechanism exposed for retrieving this information. Everything is either marked internal or has been moved to the true-type-specific implementation (which is also internal).

BTW. The API has been stable now for two major versions.

I will be glad for the stability going forward, but I have not kept abreast of the changes since December 2022. There have been many changes since that time.

I'm quite happy to be proven the fool here, if this functionality exists and I've overlooked it, I will be glad to be corrected.

[JimBobSquarePants]

Sorry for the slow reply. I've been having network problems which is severely limiting my ability to communicate.

What I meant was that no stable version of the library has exposed the raw control points. That beta predates CFF support which makes the ability to do so impossible since we have to normalize the internal layout for our public types.

@tocsoft has pointed you in the correct direction though, A custom IGlyphRenderer that captures and stores the vectors is the best approach. I'd forgotten that the Glyph.RenderTo method was internal (I'm not convinced the parameters we use in the method are good for a public API yet)

[Mavichist]

The public-facing mechanism for doing this is apparently part of SixLabors.ImageSharp.Drawing (via the TextBuilder class) rather than directly through SixLabors.Fonts.

if (SystemFonts.TryGet(fontFamily, out var family))
{
    var font = family.CreateFont(size);
    
    foreach (var character in characters)
    {
        var paths = TextBuilder.GenerateGlyphs(character.ToString(), new TextOptions(font));
        foreach (var path in paths)
        {
            var simplePaths = path.Flatten().ToArray();
            foreach (var simplePath in simplePaths)
            {
                foreach (var point in simplePath.Points.ToArray())
                {
                    Console.WriteLine($"{point.X}, {point.Y}");
                }
            }
        }
    }
}
else
{
    throw new ArgumentException($"The {fontFamily} family of fonts could not be loaded.");
}

This is acceptable for my needs, though in my opinion; a mechanism for retrieving the original control point data (in font-unit, em grid coordinates) would be beneficial for the following reasons:

1. API completeness of SixLabors.Fonts
2. It would be advantageous to be able to directly retrieve raw font-unit coordinates for glyph contours, as much of the available online TTF documentation works in this space.
3. It would reduce the number of library dependencies necessary to access the data (as SixLabors.ImageSharp.Drawing references SixLabors.Fonts and not the other way around).
4. It would avoid any additional computation performed by TextBuilder.GenerateGlyphs (and the underlying TextRenderer.RenderText call) if all you want is the raw point data.

[tocsoft]

you can also implement an custom IGlyphRenderer without the need to reference SixLabors.ImageSharp.Drawing. I do as much in https://github.com/tocsoft/FontInspector/blob/main/FontInspector/SvgTextFontRenderer.cs where render fonts to an SVG instead of a bitmap image with zero dependencies on ImageSharp at all

[Mavichist]

I was just perusing BaseGlyphBuilder in SixLabors.ImageSharp.Drawing wondering if that's the direction I should take. The FontInspector example is excellent, thank you!