- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 17 Aug 2016 09:54:32 +0800
- To: Sairus Patel <sppatel@adobe.com>, Chris Lilley <chris@w3.org>, public-svgopentype@w3.org, Jonathan Kew <jfkthame@gmail.com>
Hi Sairus,
On Wed, Aug 17, 2016, at 05:43 AM, Sairus Patel wrote:
> I’d also heard of a Firefox bug in which unitsPerEm is assumed to be
> 1000.
>
> Could Jonathan, Cameron, or someone else at Mozilla please confirm that
> this is still a known limitation of Firefox’s OT-SVG impl?
Firefox should honour the unitsPerEm in the head table to determine how
to scale glyphs when rendering:
http://searchfox.org/mozilla-central/rev/03b3c20a6ec60435feb995a2a23c5926188c85a1/gfx/thebes/gfxFont.cpp#2186-2193
But I notice that we do use 1000x1000 as the size of the "window" when
setting up the SVG document:
http://searchfox.org/mozilla-central/rev/03b3c20a6ec60435feb995a2a23c5926188c85a1/gfx/thebes/gfxSVGGlyphs.cpp#134-153
This can affect how percentage values in the SVG content are resolved if
the root <svg> element does not specify a width="" and height="". For
example, assume you have a font with unitsPerEm = 2048:
<svg xmlns="http://www.w3.org/2000/svg">
<g id="glyph0">
<rect width="100%" height="128"/>
</g>
</svg>
will define glyph 0 with a rectangle that is 1000 units wide, regardless
of what the unitsPerEm value is, but the height of the rectangle will
still take up 2048 / 128 = 16th of the height of the em square.
(This is just from code inspection; I didn't test.)
This is something that should be clarified in the specification. Do you
know what other implementations do for percentage values like this? Are
they resolved against a window size derived from the unitsPerEm?
Thanks,
Cameron
Received on Wednesday, 17 August 2016 01:54:57 UTC