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

The original design for OT-SVG required that the bounding boxes match – or in the case where they did not, the “classic” glyph description wins.   I would consider any font that doesn’t comply with that as “invalid” or “out of spec”.  It’s up to you if you wish to then support them in FT.

Concerning the rendering in +x/+y (or not), there is nothing in the (OT-)SVG spec that says that rendering only occurs in the positive – so that if you have a library that isn’t giving you the whole thing, that would be a bug in the library and I would either fix it myself (since in this case, the one mentioned is open source), get the maintainer to do so (not likely in this case) or switch libraries to one that does.

Leonard

From: Moazin Khatri <moazinkhatri@gmail.com>
Date: Wednesday, July 31, 2019 at 6:31 AM
To: Hin-Tak Leung <htl10@users.sourceforge.net>
Cc: "public-svgopentype@w3.org" <public-svgopentype@w3.org>, Werner LEMBERG <wl@gnu.org>, "mpsuzuki@hiroshima-u.ac.jp" <mpsuzuki@hiroshima-u.ac.jp>
Subject: Re: Some questions about OT-SVG glyph metrics and bounding boxes
Resent-From: "public-svgopentype@w3.org" <public-svgopentype@w3.org>
Resent-Date: Wednesday, July 31, 2019 at 6:31 AM

First of all, I apologize if I lack knowledge of things pretty obvious to the font world. I am new here! :)

For what purpose do you want the side-bearing, and the ink-box? [...]

 The behavior of FreeType (for traditional fonts) is that it renders a glyph tightly* and gives two fields called `bitmap_left' and `bitmap_top'. These two fields give information about where to place the glyph with respect to the origin and the baseline. So, for example, in many fonts, a comma (,) and an apostrophe (') might have the same pixel data after rendering and the only difference will be in the values of `bitmap_top' and `bitmap_left'. Naturally, I want the same behavior with SVG glyphs too.

Now I'll describe issues with these:
1. Rendering a glyph (tightly or not): SVG glyphs are not necessarily in (+x & +y) quadrant of the SVG coordinate system. In fact, most of the time they aren't. If you directly send the SVG document to a rendering library like `librsvg' it will only render whatever is in the (+x & +y) quadrant. Which in most cases, doesn't have anything. To ensure that you are at least rendering the whole glyph (not some clipped part of it), you must use something like a `cairo_translate' to shift the whole image to the (+x & +y) quadrant. But, then the question is, how much to shift? You can either make good guesses and hope that you get the whole glyph rendered properly (and they won't be tightly rendered anyways) or you can use some functions which SVG libraries usually provide that can give you a bounding box (in SVG coordinates). With the knowledge of this bounding box, you can render the whole glyph properly (and in many cases, tightly). There's another way to get this bounding box which I describe in my first email. I just wanna know which one is the correct one.

2. `bitmap_left' and `bitmap_top': I get these from the bounding box in SVG coordinates. There is some scaling to be done of course, but the necessary information is there. These values directly correspond to the bearings (AFAIK) and that's the reason why I was asking about them.

My major question here is, what's the right way to get these bounding boxes? Using the functions SVG rendering libraries provide? Or assuming that the TTF/CFF outline bbox is the same as that for SVG glyph (the approach I describe in the first email).

[*] Please have a look at my attachments in the first email to see what I mean by the word `tight'. If there's a better term for that please let me know.