Implement a simple API for fetching opentype metrics

[ebraminio]

Continuing #1396
Related to #1337

[behdad]

So previously I said we should get ascender/descender/linegap form hmtx/vmtx accelerators. Now I think it should be the other way around: those should get it from this API. Which means, this API should implement the logic there. The logic, for horizontal ascender/descender is that if face->table.OS2->fsSelection & USE_TYPO_METRICS then OS/2 values are used, otherwise hhea values.

Now, MVAR specifically refers to OS2 values, because there's wording somewhere else in OpenType 1.8 that says variable fonts should always have USE_TYPO_METRICS bit one. We can ignore that wording and continue the above logic. So, that logic needs to be implemented here if both tables are present.

[jfkthame]

On 30/11/2018 20:37, Ebrahim Byagowi wrote: Hmm, a font without OS2 is not that imaginable I believe.

Not sure if it's still true, but I think I remember that Apple used to ship some fonts that had no OS/2 table. (FWIW, it's documented as an optional table in their TrueType spec.) JK

[ebraminio]

Big majority of them have OS/2 but right there are apparently some that don't (comparing number of maxp and os/2 occurrence)

10.12.6 https://gist.github.com/ebraminio/7627d0e18989a25b16c55701118fc069

10.13.6 https://gist.github.com/ebraminio/d432e831b3f7ebe30245dde5775e1c7e

[ebraminio]

What's the justification for separate -internal.cc file and the regular .cc file?

You wanted to reuse the logic but we don't want to offer the API in hb-subset, which uses the table thus the API, so I had to separate it to use in the subset.

Let's add hb_ot_metrics_get_variation that doesn't do any scaling. I have a feeling that we will be encoding non-geometric values in there at some point, if it's not already... Anyway, that one should probably return a float.

Done, I think

I see that hb_ot_metrics_get_x/y_variation also return float. Probably a good idea, though technically should be hb_position_t. Not sure :(.

I turned it into hb_position_t as the scale already removed its precision but your concern is understandable.