>
> 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 FT_Renderer_Class is equipped with 'get_glyph_bbox',
> separate from 'render_glyph'. It is not currently used however and an
> outline glyph sets up its top-left and the bitmap size based on the
> outline cbox.
>
> In other words, 'ft_glyphslot_preset_bitmap' should be looping through
> appropriate renderers calling 'get_glyph_bbox'. This is how it is
> supposed to work.
>

So, after taking a close look at this function, I have a few concerns.

Currently, in `ft_glyphslot_preset_bitmap', after getting the cbox, some
math is done on it and ultimately top-left and sizing is set. If we instead
set up a loop which will iterate different renderers and get the bbox via
`get_glyph_bbox', it'll still work fine for traditional glyphs. But SVG
glyphs have their own coordinate system and their bounding box will be in
their coordinates, so it will become a mess. One way around this is, I
write `get_glyph_bbox' for the `ot-svg' module in such a way that it
converts the SVG bounding box to the equivalent bounding box in TTF/CFF
coordinate system. But that's too much work and I don't know what would be
the advantage of doing it this way.
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Reply via email to