Re: [ft-devel] GSoC: OT-SVG: Update on the whole bounding box issue
Got it. Will do soon. :) On Tue, Aug 6, 2019 at 6:28 PM Alexei Podtelezhnikov wrote: > >> 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. > > > Currently, in `ft_glyphslot_preset_bitmap', after getting the cbox, some > math is done on it and ultimately top-left and sizing is set. > > ft_glyphslot_preset_bitmap is by no means perfect and should be split > between the native renderers. I am just asking to detach bbox > calculation (or rather bitmap size and pixel position) from rendering. > There are applications that need the size and position well before the > bitmap is allocated and rendered. Do not assume otherwise. > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC: OT-SVG: Update on the whole bounding box issue
>> 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. > Currently, in `ft_glyphslot_preset_bitmap', after getting the cbox, some math > is done on it and ultimately top-left and sizing is set. ft_glyphslot_preset_bitmap is by no means perfect and should be split between the native renderers. I am just asking to detach bbox calculation (or rather bitmap size and pixel position) from rendering. There are applications that need the size and position well before the bitmap is allocated and rendered. Do not assume otherwise. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC: OT-SVG: Update on the whole bounding box issue
> > 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
Re: [ft-devel] GSoC: OT-SVG: Update on the whole bounding box issue
> > 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. > Yes, currently for TTF/CFF outlines, `FT_Load_Glyph' calls `ft_glyphslot_preset_bitmap' but the function only works for traditional outlines. Instead it should find the right rendering module, and use its interface to get the bounding box and using that bounding box, perform presetting. I need to check a few things about this to make sure whether this can work for SVG glyphs or not. Will let you guys know how it goes. :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC: OT-SVG: Update on the whole bounding box issue
> > 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 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. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
