Add as_ttf_face to Font, exposing the ttf_parser interfaces

[danieldg]

This allows using ttf_parser's more advanced APIs without needing to parse the font twice.

[alexheretic]

I keep ttf-parser out of the ab-glyph public API intentionally. This means I can avoid major version increments whenever ttf-parser does (which has worked out quite well so far).

If you need stuff that isn't covered by ab-glyph there's a possibility of adding it, it's at least worth proposing. However, if it's out of scope it's best to use ttf-parser separately, perhaps even if that means parsing the font twice.

[danieldg]

Would exposing this by implementing the owned_ttf_parser::AsFaceRef trait still have the same issue? That would at least force users to depend on that crate to import the trait, though they would have to match the versions used if they did use it. Not sure if that still justifies major version updates or not; it probably does if you are being conservative.

I am specifically interested in glyph_raster_image to handle fonts or codepoints that don't contain outlines, which I am guessing is out of scope.

[alexheretic]

Would exposing this by implementing the owned_ttf_parser::AsFaceRef trait still have the same issue?

Unfortunately yes, in that case ttf-parser bumps could break user builds so I'd have to make breaking bumps to ab-glyph.

I am specifically interested in glyph_raster_image to handle fonts or codepoints that don't contain outlines, which I am guessing is out of scope.

Ah I haven't used pre-baked glyph images myself at all. But, on the face of it, it doesn't seem wrong to have this in the ab-glyph API. We'd need to avoid exposing ttf-parser types. Is this method enough, or are you using others alongside?

[danieldg]

While I haven't run into a font that uses it, glyph_svg_image looks similar enough that it may be useful to support both (maybe using the same structure for output, with a larger enum than ttf_parser::RasterImageFormat). I don't find the width/height/pixels_per_em fields of RasterGlyphImage are useful, since any use of the resulting data will naturally produce these as part of decoding and re-scaling the image.

[alexheretic]

Yeah that makes sense. So you're thinking GlyphImage::Png(&[u8]), GlyphImage::Svg(&[u8]) kinda thing?

Let's start with a PR adding a as simple as possible API exposing glyph_raster_image and try to get that working with the image example or some new example. If we can find a font that uses svg we can add that too.