Re: Some questions about OT-SVG glyph metrics and bounding boxes

 Hi. (I am actually on freetype-devel too...).

AFAIK, the svg spec pretty much allows the whole of the postscript graphic operations, and more, but in xml syntax. A few things are skipped in svg-opentype, like animation(?). I think not having viewport nor width/height are perfectly legal; and given the range of operations allowed (translate, scale, clip, etc), it is almost impossible to know the ink-box/bound-box, without actually rendering the glyph. While the svg-opentype spec I think says rendering systems which don't understand svg should fall back to ttf/cff, the ttf/cff glyphs don't have to agree with the svg glyphs in any dimensions/offsets, perhaps other than advance-width, for obvious reasons. The advance width likely need to agree for pragmatic reasons - otherwise document layout would dramatically change. 

I think that's my impression of the whole thing, but others more knowledgeable, please feel free to correct.
     On Monday, 29 July 2019, 10:33:31 BST, Moazin Khatri <moazinkhatri@gmail.com> wrote:  
 
 Hi all,
I am a GSoC student working with the FreeType project where I am adding the support of OT-SVG fonts to FreeType. Werner LEMBERG and Toshiya Suzuki are my mentors. Ever since we started the project, I have had some questions about SVG glyphs. I wish I had discovered this mailing list earlier. I am writing here in the hope of getting the answers. My English is weak and I am usually unable to ask questions in the most efficient manner. I apologize if they are extra lengthy here. 
The questions are:
1. How do I render a glyph tightly while using an SVG rendering library. Please see the attachments `not-tight.png' and `tight.png' to see what I mean by `tight'. If you just send an SVG glyph to a rendering library, it'd just render everything in the ( +x & +y ) quadrant. In the case of most characters (characters like `j' are an exception) there's barely anything below the baseline. The solution I found is, get the tight bounding box for the glyph in SVG coordinates and then use `translate' and `scale' transforms to render exactly that bbox. This works perfectly, but the question is, how do I get the bounding box in SVG coordinates? Some SVG libraries do provide functions which can get these bounding boxes, but even they don't give accurate bounding boxes if `clipping' has been used. I realized that the bounding box in the SVG glyph is EXACTLY the same as that of CFF/TTF outline for the same character (apart from some `scaling' and `translation' between the two coordinate systems of course). So, the approach I am using now is I get the bounding box of the TTF/CFF outlines and then do the necessary `scaling' and `translation' calculations to get the bounding box of the SVG glyph in the SVG coordinates and ultimately use that to get a tight rendering. This has worked PERFECTLY for EVERY font and test font I tested with, except one that I encountered just yesterday. It's https://bixacolor.com. In the case of this font, the bounding boxes for both coordinate systems are different (the glyphs themselves are slightly different too), due to that there's minor clipping in rendering the SVG glyphs. Please tell me if my approach is correct or not? If it is not, please tell me which approach is the right one?
2. How do I get the bearingX (distance from the current pen position to the left edge of the bounding box of a glyph) and bearingY (distance from current pen position to the top edge of the bounding box of a glyph) for the SVG glyph? The approach I use is to simply get these from the bounding box I calculate as described in 1. Is that the right approach?
3. Can an SVG document that neither has a `viewbox' nor has `width'/`height' attributes on its root `svg' node be considered a legal document? Is it against the SVG specs or the OT-SVG specs? The SVG glyphs in `Bixa Color' are like this.
Thanks in advance. :)
Moazin