Expose available code points/glyph id mappings

[CptWesley]

As far as I can tell, it is currently not possible to obtain a list of defined code points (or similarly, a list of all available glyph mappings) in a font. This feature can be useful in case someone wants to use this library to extract font information or for my particular use case: to automatically generate glyph maps for OpenGL.

From my quick investigation it seems to be relatively easy to add a function to the Font or FontMetrics type that exposes the list of defined code points and also expose the GlyphId defined in GlyphMetrics. This would in turn allow users to relatively easily reconstruct these glyph mapping tables themselves.

I also took the time to implement this and create a pull request: #308

[JimBobSquarePants]

Hi there, interesting idea.

I'm not sure what you mean here by "defined code points". A glyph might be represented by multiple code points.

e.g.

Base Character CodePoint + Variation Selector CodePoint.

[CptWesley]

To maybe clarify a bit more. The functionalities that I am after are somewhat similar to https://fontdrop.info/ which shows all glyphs, their names and their corresponding unicodes in fonts that are submitted.

[JimBobSquarePants]

Yep. That's what it does.

What I'm trying to clarify is what are the exact requirements so that we can ensure the resultant API is correct. In your PR you return an empty array from Format14SubTable which means variant selectors are not included in your output.

The reason I highlighted variant selectors is that they are required in some instances to return the correct glyph.

As an aside I think I've just spotted a potential issue in our

CmapTable.TryGetGlyphId(CodePoint codePoint, CodePoint? nextCodePoint, out ushort glyphId, out bool skipNextCodePoint)

method which means we do not return an id when we should if a selector is passed.

[CptWesley]

The emtpy array return from Format14SubTable was based on the fact that the glyph id retrieval always returning false.

[JimBobSquarePants]

Yep because that table requires both the base and variation to return a result. What I'm trying to ascertain is should variations be included in the returned CodePoint collection.

[CptWesley]

For my personal use case it would be incredibly useful if variations were included, but I can imagine that the number of variations can increase quite rapidly for some fonts, so I'm not sure how feasible that is. I must admit that I'm not an expert on fonts or font rendering.