[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Glyph extents

From: Jean Abou Samra
Subject: Re: Glyph extents
Date: Fri, 21 Apr 2023 10:15:59 +0200
User-agent: Evolution 3.46.4 (3.46.4-1.fc37)

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.

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]