- From: Doug Felt <dougfelt@google.com>
- Date: Wed, 25 Feb 2015 17:34:16 -0800
- To: public-svgopentype@w3.org
- Cc: Behdad Esfahbod <behdad@google.com>
- Message-ID: <CAK9MbuL0j5svG7NzEv1ZNrzUGBeU=WkoA9GA3PZuLVt=UmVpqQ@mail.gmail.com>
I'm also finding that I can't set a clip-path. Not sure if this is because clipping isn't supported in this context, or because having the clipPath be a descendant of the referencing svg element isn't supported in this context, or what. It works standalone. On Mon, Feb 23, 2015 at 1:21 PM, Doug Felt <dougfelt@google.com> wrote: > 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. > > -- Doug Felt | Software Engineer | dougfelt@google.com <https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=dougfelt@google.com> | 1-650-253-2089
Received on Thursday, 26 February 2015 01:35:04 UTC