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.