Re: specification for Mozilla's SVG in OpenType proposal

On 4/02/13 10:45 PM, Tavmjong Bah wrote:
> The first thing I discovered was that the format for the glyphs doesn't
> follow the SVG 1.1 spec. Instead of using <glyph>, two new attributes
> have been defined so that any element can be used as a glyph. This makes
> it more difficult to use existing SVG glyphs as a source for SVG in
> OpenType and at the moment, in creating new SVG glyphs for use in OT. At
> first I thought I could use Inkscape to create the glyphs (Inkscape has
> the ability to create but not use SVG fonts), then use FontForge to
> create a "normal" OpenType font with the glyphs, and then insert the SVG
> table using the Python scripts. Since the SVG in OT glyphs are not
> defined with <glyph> it meant I had to create duplicates of each glyph
> (inverting the y-axis on one of them). My question is, why not just use
> <glyph>? One could create an SVG font, with a file to test it and then
> simply insert the <glyph> elements into the OpenType without having to
> manipulate it excessively. There are cases where one might want both a
> "stand-alone" SVG font and an SVG in OpenType font; having the same
> glyph format would make that easier.

There were concerns that <glyph> came along with a lot of "baggage", 
namely all of the font metric attributes.  In the past (apparently) 
there have been issues with fonts where there were multiple places where 
font metrics could be specified, resulting in confusion about which ones 
should be used and which ignored.  I think some people were worried that 
if we used <glyph> directly that people would use the SVG 1.1 metrics 
attributes on those elements, that these values would be in conflict 
with those in say the hmtx table, and that some implementations might 
incorrectly decide to follow those on the <glyph>.

> Another weakness I found in the current proposal is the inability to
> pass more than one or two color attributes (color in the case of HTML,
> fill and stroke colors in the case of SVG) into the glyphs.

Sairus brought that up in a previous mail, too.  I think it would be 
nice to support this, although I think it's not critical.  On the glyph 
definition side, I think we would obviously want to use CSS Variables to 
handle the parameter referencing, but how values would be passed in I'm 
not sure.

> One thing that became obvious to me, is that the whole process of
> creating an SVG in OpenType font has a tremendous amount of overhead. It
> requires font editing software with the knowledge of how to use it. This
> is not something that a typical graphic designer is likely to have. We
> talk about the desire that SVG should be "hand-editable." This is about
> as far from that as possible. The time invested in creating an SVG font
> may be worth it when creating reusable fonts but is definitely not
> something one likely would do to create a "one-off" title or even a
> handful of headings. An alternative method is still needed for providing
> accessibility in these cases.

Yeah I agree that it needs to be easier to create the fonts.  I would 
really like to see both (a) a tool that took an SVG <font> and turned it 
into an SVG-in-OpenType font, and (b) an online tool that took an "SVG 
document as would be embedded in an OpenType font" and let you easily 
specify the metrics, which it would then fill in in the right OpenType 
tables for you.

Received on Monday, 4 February 2013 12:47:53 UTC