[HarfBuzz] Streamlining hb_font_t some more

[Jonathan Kew]

On 26/10/15 15:37, Nikolay Sivov wrote:
> On 26.10.2015 11:30, Simon Cozens wrote:
>> On 09/10/2015 15:09, Khaled Hosny wrote:
>>>> should just use the typographical ascender/descender of the font and
>>>> hence not
>>>> need glyph bounding boxes in Sile at all.
>>>
>>> Yes please, an approach similar to what browsers do would be much
>>> appreciated.
>>
>> OK; I've implemented support in Harfbuzz for getting these metrics out
>> of the OS/2 table.
>
> I don't think it's that simple, according to specs you need to check
> with fsSelection (bit 7), and use sTypo* metrics only when this bit is
> set. But of course there's no guarantee that font was generated properly
> and sTypo* values are meaningful when this bit is set or garbage if it's
> not. Also this bit selector is supposed to be consistent with os/2
> version being >= 4; otherwise an option is to use usWin* metrics. And
> usWin* metrics are broken too sometimes, just recently I had to fix and
> issue when signed value was written to unsigned usWinDescent, which
> won't play nice as you can imagine. Also there is an 'hhea' table that
> could provide 'similar' functionality, but not always...

Indeed. It's a mess out there.

> But probably more important is that this functionality doesn't seem to
> belong to harfbuzz in a first place, as it never needs global metrics
> internally (or does it?). If you only need a couple of fields it's easy
> to get them manually from font blob.

I'm inclined to agree. There's no single "clearly right" algorithm for 
deciding what metrics to use, and it's likely that the "best" answer 
will depend on the nature of the client application (what's appropriate 
for a plain-text editor may be different from what's appropriate for a 
web browser; and a typesetting application may want something different 
again).

Reading the relevant fields from font tables isn't hard, given a 
"get_table" function. The tricky part is deciding which of the 
potentially-conflicting values to use, and we shouldn't put those 
heuristics into harfbuzz, which cannot know what's likely to be most 
appropriate for the client.

(Sure, any given client could still ignore the harfbuzz API and do its 
own thing. But putting such an API into harfbuzz will tend to give the 
impression that it's the "correct" thing to use, and may tempt app 
designers to ignore an issue to which they should actually be giving 
conscious attention.)

JK