[Question] about Metrics.Height

[danaugrs]

Hi, we are using this library for g3n and it's working nicely. We just started using font metrics (thanks for adding that 😄) to better position text and it simplified the math since the metrics already take into account the point size and DPI.

For all the fonts I tried, I noticed that Metrics.Height < Metrics.Ascent + Metrics.Descent. Why is that the case? I know that the docs state that "Height is the recommended amount of vertical space between two lines of text" but shouldn't that be the same as the height of the font?

The only difference I see between how Height is calculated and the other metrics is that it is not divided by fUnitsPerEm.

Thanks in advance!

[nigeltao]

The ascent and descent are scaled versions of the numbers given in the TTF data, but currently, the height is independent of whatever it is the TTF says. Instead, if you ask for a 10 point font face (at 144 dpi), then you will get a height of 20 pixels, regardless of what's in the TTF data.

Longer term, yes, we probably want to fix that, although that will also have knock-on effects on the algorithms necessary to lay out lines of text containing multiple font faces, even if every face is nominally e.g. a 10 point font face.

Personally, I don't have much free time to work on this any time soon. Sorry.

As for dividing by fUnitsPerEm, the a.scale field is already in (fixed point) pixels, not in font units. It is a fixed.Intt26_6 value. The other numbers are based on the Font (not the Face) fields f.ascent and f.descent. These fields are in Font Units, not pixels. A truetype.Font generally works in FUs, a truetype.Face generally works in pixels.

[dmjones]

Are there any plans to look at this? I can help out, perhaps with a few pointers of where to start.

As I understand it, without this fix, we cannot layout text precisely within a bounding box.