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