> Instead of handling all of this in `woff2_open_font', I have
> introduced a new variable in `sfnt_open_font' (woff2_num_faces), and
> I use this to set `face->root.num_faces' if the input font is a
> WOFF2. (I believe) this solves all the issues. I've implemented
> this in commit b25c352.
On Mon, Aug 5, 2019 at 3:31 AM Werner LEMBERG wrote:
>
>
> > Instead of handling all of this in `woff2_open_font', I have
> > introduced a new variable in `sfnt_open_font' (woff2_num_faces), and
> > I use this to set `face->root.num_faces' if the input font is a
> > WOFF2. (I believe) this
Hi Werner, Toshiya,
I wanted to give an update on the whole bounding box issue that has
remained open for a really long time now. From my discussions in the OT-SVG
list, my conclusions so far are:
* For any particular glyph ID, the bounding box of the OT-SVG glyph and the
bounding box for the
>
> So, I guess I should instead rely on the bounding box functions that the
> libraries provide now? Let me know your views.
>
In practical terms, we need the bounding box to initialize the
top_left and the bitmap size. These values might be needed even if the
actual memory allocation and
>
> In practical terms, we need the bounding box to initialize the
> top_left and the bitmap size. These values might be needed even if the
> actual memory allocation and rendering is postponed indefinitely. One
> should *not* expect immediate allocation of memory and rendering. For
> this purpose
