Expose internal infrastructure AND/OR provide indirect to these features through new infrastructure

[vivianvea]

Hi!

I am planning to utilize this library (and sibling library *.Drawing) for a .NET 5 PDF producing library I am working on.

For this purpose, I'm in need of a sort of FontWriter alternative to the already existing (internal) FontReader. in order to embed fonts in my generated PDF. I am also interested in being able to only write a given set of glyphs, to avoid embedding the entire font.

A very simple way for this would be to expose the tables, FontReader, and other internal infrastructure, so that I could more easily implement the FontWriter myself. Alternatively, a FontWriter and other infrastructure could be added directly to the library, to give consumers of it a lot more power when it comes to font managing without exposing all of the internal infrastructure.

I am very much willing to contribute this work myself, but I'd like feedback on what direction to take the implementation in.

This issue sorta relates to #87.

[tocsoft]

Hmm... I do like this as an idea, however;

The library isn't actually targeting the general font file manipulation use-case, what it's trying to target instead is an API for text layout/rendering and the API is designed specifically with that use case in mind with the font loading we having actually being just an internal implementation detail, which is why we don't even have all the tables etc defined as we only support reading the ones we actually use.

That font loading/sub-setting scenario is definitely something that's of interest but it feels like it would be better in a separate library than our current code (Where this lib may end up taking a dependency on it, at least at a sources level, and we remove the loading code we currently have here).

Having said all that depending on exactly the API surface that would be needed we would be happy to receive a PR adding some form of sub-setting API... as long as it doesn't muddy up the public surface, so something simple like a single public class/method that takes one of the loaded Fonts and some text and writes to a stream a new ttf font with the subset of glyphs used..

[lyhyl]

Here is my case, I am planning to use this library for generating font atlas of a game. I think it would be great to expose the internal infrastructure like TextLayout, GlyphLayout and CodePoint.

[beeradmoore]

which is why we don't even have all the tables etc defined as we only support reading the ones we actually use.

Even with the font tables being used, some of the data is still inaccessible. Would it make sense to expose some of the data that is already being populated? Eg. recently I needed to get the postscript name for a font (unless I am doing something wrong, but this is where the value I needed was) but NameTable is object is private in FontDescription. NameTable itself is internal, as is the NameIds enums that are inside it.

Would it make sense to make NameIds public and then expose NameTables GetNameById through to FontDescription so then the data is accessible, or was there some reason that only FontName, FontFamily and FontSubFamilyName were exposed in this way?

[JimBobSquarePants]

Yeah, let's have a look at making NameIds public. If the info is important and can be exposed without also exposing inner workings that could be subject to change we should expose them. @beeradmoore fancy raising a specific issue to capture this?

[beeradmoore]

Done. Is all in #206