Le mercredi 19 avril 2023 à 06:02 +0000, Werner LEMBERG a écrit :
> No, we can't.
>
> For FreeType, a bounding box ('bbox') of a glyph is set up by the
> minima and maxima of all its contours (omitting single-point
> contours). Computing this is very slow. However, much faster to
> compute is the control box ('cbox'), which consists of the minimum and
> maximum values of all points all contours of a glyph. In well-formed
> fonts (i.e., fonts that have a curve points at all contour extrema),
> the bbox and cbox dimensions are identical.
>
> Note that the bbox/cbox information is *not* part of an OpenType font!
> Only the advance width together with the left-side bearing ('lsb',
> which is negative for Emmentaler's glyph 'f') is stored in the 'hmtx'
> table. While the advance width is an arbitrary value set by the font
> designer, the lsb is not.
>
> For LilyPond, the term 'bbox' means something completely different: It
> is an artificial box suited for LilyPond's needs but *completely
> decoupled* from the actual glyph dimensions. For a glyph's width,
> breapth, height, and depth, the OpenType SFNT tables only deliver
> 'width'.
>
> FT_Pos hb = m.horiBearingX;
> FT_Pos vb = m.horiBearingY;
>
> FreeType computes these values from the glyph's 'cbox' while loading
> the glyph for retrieving its metrics.Thank you, Werner! This is much clearer to me now. What's I don't yet see clearly is how this will interact with SMuFL support, but I haven't completely looked into it.
signature.asc
Description: This is a digitally signed message part
