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

The section about “Text-Layout Processing” (https://docs.microsoft.com/en-us/typography/opentype/spec/svg#glyph-semantics-and-text-layout-processing) is very clear that
“When SVG glyph descriptions are used, text layout is done in the same manner, using the 'cmap', 'hmtx', GSUB and other tables. This results in an array of final glyph IDs arranged at particular x,y positions on a surface (along with applicable scale/rotation matrices). After this layout processing is done, available SVG descriptions are used in rendering, instead of the TrueType/CFF descriptions”

That is also followed up with the following:
“Glyph advance widths or heights are the same for SVG glyphs as for TrueType/CFF glyphs, though there may be small differences in glyph ink bounding boxes. Because advances are the same, switching between SVG and non-SVG rendering should not require re-layout of lines unless the line layout depends on bounding boxes.”

Animation is not permitted in SVG fonts (https://docs.microsoft.com/en-us/typography/opentype/spec/svg#svg-capability-requirements-and-restrictions).  It was considered but never introduced, the glyph bounding box issue being one of the reasons.


Back on the issue of rendering and viewports – see https://docs.microsoft.com/en-us/typography/opentype/spec/svg#svg-capability-requirements-and-restrictions

The size of the initial viewport for the SVG document is the em square: height and width both equal to head.unitsPerEm. If a viewBox attribute is specified on the <svg> element with width or height values different from the unitsPerEm value, this will have the effect of a scale transformation on the SVG “user” coordinate system. Similarly, if height or width attributes are specified on the <svg> element, this will also have the effect of a scale transformation on the coordinate system.

Although the initial viewport size is the em square, the viewport must not be clipped. The <svg> element is assumed to have a clip property value of auto, and an overflow property value of visible. A font should not specify clip or overflow properties on the <svg> element. If clip or overflow properties are specified on the <svg> element with any other values, they must be ignored.

Seems pretty clear what the viewport should be set to and how to handle clipping, etc.

Please do reach out as you continue your work – looking forward to the results!

Leonard

From: Moazin Khatri <moazinkhatri@gmail.com>
Date: Wednesday, July 31, 2019 at 11:33 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 11:33 AM

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

On Wed, Jul 31, 2019 at 6:24 PM Leonard Rosenthol <lrosenth@adobe.com<mailto: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<mailto: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<mailto: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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Fsvg%23examples&data=02%7C01%7Clrosenth%40adobe.com%7C5ffdbb44ff89479fba4808d715cc7075%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637001840148598198&sdata=RANDTQVXHr2k90l%2FGhbnh9NlFJF60vcyU1%2Fv1cS3rVM%3D&reserved=0>

<svg id="glyph7" version="1.1" xmlns="http://www.w3.org/2000/svg<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg&data=02%7C01%7Clrosenth%40adobe.com%7C5ffdbb44ff89479fba4808d715cc7075%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637001840148608192&sdata=wB7UvXteF6M7lEawKnVhqqfOdR3bsL0pHiZhWUm8Z2I%3D&reserved=0>">
  <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.