expose font metrics (ascender / descender etc)

[cmyr]

I'm sure this is on some font roadmap I'm too lazy to look for, so feel free to close as a dupe if appropriate:

When drawing text (via RenderCtx::draw_text) we supply a position where the text should draw. This is an origin in "text space", that is with (0,0) at the intersection of the baseline with the left edge.

Unfortunately, there's no way to know where the baseline is relative to the overall height. (There's also no real way of getting the overall height, afaict, although what "height" means is not well defined; I would settle for "the union of the bounding boxes of all glyphs in the font").

Anyway: this is more a practical issue than a font-metaphysics issue. It would be nice if we could, in the general case, draw some text in a box with equal padding on the top and bottom. A reasonable first step for this would be exposing general metrics like ascender/descender.

[raphlinus]

We just talked about getting line height metrics in, using a similar pattern as DirectWrite line height metrics. This basically gives you the top of the line, the baseline, and the bottom of the line (which is equal to the top of the next line).

There are other potential alignment metrics (ascender, descender, x-height, etc), but those get pretty complicated, and the quality of the metadata in fonts is variable (see the vertical metrics wiki for glyphs, among other sources).

I think we should get the basics in now, then do another pass in a few months with an effort to getting it really right, especially for multilanguage cases when lines take (in some cases) significantly more vertical space than in Latin and CJK. This has been a perennial pain point for Android, and it's been hard for them to get it fixed because of backwards compatibility.

[cmyr]

That sounds good to me.

[jjl]

Hello,

I thought I'd write a terminal emulator with druid for fun, on the basis that we normally use these with fixed width fonts so we might be able to do it with druid's text as it currently is.

Unfortunately, this still requires font metrics. As a workaround I printed some lines of text with different guesses for what they were for the one font i'm choosing to currently support.

I guess I'm looking for suggestions of workarounds for the lack of font metrics in piet. That way I'd be able to change the font without having to remeasure with my eyes.

[jjl]

Update: I've found this in font-kit, i can just load the same font separately https://docs.rs/font-kit/0.5.0/font_kit/metrics/struct.Metrics.html