> > 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