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
[ft-devel] GSoC: OT-SVG: Update on the whole bounding box issue
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 corresponding TTF/CFF glyph don't have to be the same at all. They are usually close to each other, but don't have to be. For example, for Bixa Color, it isn't. * Thus, instead of using the bounding boxes from TTF/CFF outlines we should just use native library methods or something like a `cairo_recording_surface'. I know that both of these don't give accurate bounding boxes in cases where clipping has been used (Toshiya illustrated this quite some time ago). But that's okay. That situation is analogous to how the control box isn't always accurate for TTF/CFF outlines. It can be bigger. We should handle this situation in the exact same way. Just assume that it is the correct bounding box. `bitmap_left' and `bitmap_top' will adjust accordingly and combined with the transparent parts, the end result should be exactly the expected one. :) ( This last point is just my understanding, please ignore if it's confusing and if anyone thinks that I have misunderstood something please correct me) * I think that the requirement for a bounding box only comes up because of the nature of FreeType (it isn't connected to OT-SVG in any way). FreeType just returns rendered pixel data for glyphs and to ensure that each glyph is properly rendered we need to know the bounds. I realized this by looking at Direct2D's support for OT-SVG. In cases like Direct2D, everything is mostly just vector graphics all to be drawn on some canvas (similar to a cairo recording surface). Thus, OT-SVG support is simple, just get all the graphics from the SVG document, and using some transform place the origin (of SVG coordinate system) where you want the glyph origin to be and the character would just land right where it's supposed to be and things like `bitmap_left' and `bitmap_top' are automatically handled for since this information is already there in the SVG document. I guess, ultimately, they will also be calculating the extents (when they render the whole thing) but that part wouldn't be connected to OT-SVG in any way (it existed way before). So, to conclude, the need for bounding boxes is something connected with rendering vector graphics, not with OT-SVG. So, I guess I should instead rely on the bounding box functions that the libraries provide now? Let me know your views. Moazin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
