Questions about viewport and metrics

I'm noticing some behavior with svg opentype in Firefox that I don't fully
understand.

The default viewport seems to be 1000x1000 font units. This is mentioned
here https://wiki.mozilla.org/SVGOpenTypeFonts#Structure_of_the_SVG_Document
but not here http://www.w3.org/2013/10/SVG_in_OpenType/. The latter
document leaves it unspecified what the default viewport is, which seems
like a problem.

I'm finding that distances in percent will map '100%' to 1000 font units.
The only way I have found to change how lengths in % behave is by changing
the transform attribute on the svg element. Specifying a viewBox scales to
the 1000x1000 font unit square, and while values without units scale,
values in % remain unaffected.  Without a viewBox, specifying width and
height attributes on the svg effectively does the same thing as a viewBox
of '0 0 width height' (with a viewBox it appears width and height are
ignored).  With a font using 2048 upem, if I set transform="translate(0,
-ascent) scale(2.048)" I get behavior more in line with what I expected,
100% maps to 2048 font units.  But really what I'd expect is that width and
height attributes on the svg element define the view portsize in upem.  It
seems a more straightforward way for me to indicate what 100% means.

The 2013/10 document also doesn't say what happens to measurements in other
units (em, px, cm...).  Are the units ignored? Disallowed? Is behavior
unspecified? Does '1em' map to the font's upem? It would help if the spec
were a bit more explicit about these issues.

The way I stumbled across this is by trying to build a font using
public-domain SVG images of country flags (from wikipedia) and mapping them
to ligatures built from unicode regional indicator symbols.  The SVG's all
render fine standalone, but as glyphs they behave very differently
depending on the units their drawing commands use. Some are fine, some are
too large or too small, and some have a mixture of units and render
inconsistently. I was having difficulty using the public spec to resolve
this.

Received on Wednesday, 25 February 2015 20:48:51 UTC