[HarfBuzz] Streamlining hb_font_t some more

[Behdad Esfahbod]

On 15-10-05 07:35 PM, Simon Cozens wrote:
> On 03/10/2015 01:51, Behdad Esfahbod wrote:
>> So, how does that sound?  I expect that it will only make easier for most
>> clients.  Like to hear what Jonathan has to say.  Chrome, Android, Pango,
>> XeTeX, Sile should all either benefit from this or be unaffected.
> 
> This all sounds great but if it's a question of priorities I would like
> to see more on getting the OT features complete and being able to drop
> FT support - so that means CFF and everything else. That's where the
> real speed increase is; if OT is not a complete replacement for FT, we
> can't use it yet, no matter how fast it is...

Right.  You seem to want glyph bounding boxes, for which we need CFF
implemented.  However, let me point out a conceptual design point that I hope
I can convince you on:

In TeX font model, glyphs contain a *logical* bounding box.  That's what's
used in the line stacking.  In OpenType, we don't have that.  We only have ink
bounding box.  For TrueType, the bounding box is written out in the font.  One
can lie about the ink bounding box and essentially get a logical bounding box
in TrueType fonts.  But that will be a bad font.  In CFF, we just don't have
anything other than the outline, and hence ink bounding box.  So, from my
point of view, you should NOT use this for line height calculation.  You
should just use the typographical ascender/descender of the font and hence not
need glyph bounding boxes in Sile at all.

I'd be happy to elaborate.

behdad