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

(Replying to yours and Leonard Rosenthol's email together here)

On Wed, Jul 31, 2019 at 6:24 PM Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> 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.
>

Okay, thanks. Just for my own knowledge, could you point me to the right
section in the OT-SVG specs which backs this statement up? Just out of
curiosity, does this statement stay valid when animation is taken into
consideration? I am not sure if bounding boxes make any sense in animated
glyphs.

On Wed, Jul 31, 2019 at 6:24 PM Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> 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.
>

On Wed, Jul 31, 2019 at 6:37 PM Hin-Tak Leung <htl10@users.sourceforge.net>
wrote:

> I think this is a bug - or lack-of-feature, of the library concerned, or
> how you are using it. It is quite legal to draw on the whole range of the
> co-ordinate system. Have you look at perhaps, how inkscape, or other svg
> editor, determine the extent of an svg file?
>

I am sorry if my emails gave the impression that there's something wrong
with the SVG rendering libraries. There isn't. Please have a look at
Example 2 of OT-SVG specs. I'll quote the example here for reference:
https://docs.microsoft.com/en-us/typography/opentype/spec/svg#examples

<svg id="glyph7" version="1.1" xmlns="http://www.w3.org/2000/svg">
>   <defs>...</defs>
>   <rect x="100" y="-430" width="200" height="430" fill="url(#grad)" />
>   <rect x="100" y="-635" width="200" height="135" fill="darkblue" />
> </svg>
>

Try rendering this via any SVG rendering library or any browser. You'll see
no result. This one doesn't have a viewbox, just assume that the
units_per_EM is 1000 and the viewBox is "0 0 1000 1000", it doesn't make a
difference. I have seen fonts with exactly these numbers. Any SVG renderer
will render just an empty 1000x1000 picture here, however, if I just add
`viewBox="0 -1000 1000 1000"` to the root node and then view it in a
browser, I'll see the expected glyph, and this I believe is the correct
behavior too from an SVG point of view.  Every SVG library that I have
dealt with, `librsvg', `resvg' and even Adobe's `svgnative' all behave the
same way. These libraries do provide means of changing this of course, at
least their graphic backends do. For example, you can use a
`cairo_translate(cr, 0, 1000)` and get the rendering correctly. I totally
agree that it's perfectly legal to draw anywhere in the SVG coordinate
system, however, these libraries won't render the actual content by itself,
you'll have to figure out the extents of the drawing and use appropriate
`translate' transforms to get the drawing rendered properly.

Yea, I should perhaps take a look at how things like Inkscape get the
extents. There are many ways, SVG libraries often provide functions to do
this. There are also things like `cairo_recording_surface' which could be
used.

These rather came from the rendering.
>

> I think you are perhaps confusing two issues -
>

Yes, you're right. I have been confusing the two. I think that these are
more or less the same things (apart from an scale factor).


> 1. how to determine the extent of a svg drawing, *without* and *before*
> actually drawing it. (that's quite difficult if not impossible ; there are
> hints from heights/widths/viewBox but they are not always present, nor
> always correct).
>

Yes, this is hard to get because of all kinds of transforms and clippings.
But in my experience with different SVG libraries, getting these is
IMPORTANT in order to properly render the glyph as I explain above. And for
a tight rendering, the extents must be tight, else you'll get redundant
un-inked pixels which I don't want in FreeType.


> 2. the library you are using is not telling you the extent of an svg
> drawing, *after* it has done the rendering ; or perhaps you have not
> figured out how to get at that information.
>

It'd be great if the library can tell me the drawing extents (in pixels).
That means, I could use the hints from the viewbox width/height for a big
non-tight bbox and get a good rendering (which may not be tight), Then I
could use this information to crop the unnecessary parts. So far, I haven't
found such a feature.