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
_______________________________________________
HarfBuzz mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
