Re: specification for Mozilla's SVG in OpenType proposal

On Feb 4, 2013, at 7:47 AM, Cameron McCormack wrote:

> 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.

The duplication of data has historically been a problem. For an example, go look through the OpenType spec and tell me where to find the descender value for a font. I'll wait until you have an answer.... Back? Okay, what's your answer? Nope. That's not the right answer. :-) There is no right answer because the descender can be specified in several places. In the past and present (and probably future) different OS/applications/environments pulled the value from different places. The value is stored differently in different places and that has led to rendering inconsistencies. That's bad. Even if you state in the spec that the hmtx value should be used and the values must be consistent, someone will make a mistake and pull the value from the wrong place.

>> 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.

I strongly disagree that this is not critical. Think about a workflow that doesn't allow these colors to be changed externally:

1. user wants to change the shadow color of a font
2. they have to download and install some software
3. they have to figure out how this software works
4. they have to modify the font and create a new version
5. they have to upload the new font

Designers/authors by and large don't want to make fonts. They want to use them. Telling them that they have to jump through hoops to make the text color match the color scheme of the website they are working on is...ouch.

>> 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.

The tools will come around once the spec is moving forward. If the spec is simple enough, it won't take long to add support. Based on an earlier reading of the spec, I'd estimate that it would take me about a day or two to make an extension for RoboFont that generates an SVG-in-OpenType file. But, I'm not going to do that until the spec is more stable.

Tal

Received on Monday, 4 February 2013 18:56:49 UTC