- From: John Daggett <jdaggett@mozilla.com>
- Date: Wed, 2 Mar 2011 00:52:01 -0800 (PST)
- To: public-svg-wg@w3.org
- Cc: www-font@w3.org
>From the discussion at the SVG F2F, I still don't see a clear rationale for supporting SVG Tiny 1.2 Fonts (i.e. only glyphs with simple path definitions) in SVG2. The only thing that SVG Fonts offer compared to OpenType/WOFF fonts is the ability to edit and create with script. Is this really such a strong use case? I think in general defining font formats requires a lot of thought and effort. The design industry has standardized on OpenType. I don't see any reason or value in defining a different font format that attempts to mimic a very small subset of the features available in OpenType. SVG Fonts were useful when handsets were not able to support downloadable fonts. But that's no longer the case and I don't see any reason for burdening a *new* version of SVG with old requirements. I think all of SVG Fonts should be in a separate, optional module, including SVG 1.2T Fonts. John Daggett CSS3 Fonts editor Specific comments: > scribe: this will require SVG 1.2 Tiny Fonts for SVG 2, but to > leave out the complex fonts for a separate module > > AD: i think that's a sensible thing, since so many devices > already implement 1.2T SVG Fonts I think the criteria is not whether it's been implemented but whether it's been used widely. > AD: there are 100s of millions of devices with Tiny fonts out > there ... and there's lots of content on mobile that supports > it. all the ipad stuff is using Tiny fonts. The most recent revision of iOS for iPhone/iPad devices supports OpenType. Font vendors would like to drop SVG Font support, not add it. In fact, once Apple released the update supporting OpenType, Typekit *immediately* dropped SVG Font support. > JF: i'd like to talk about use cases in the japanese market in > the epub wg we talked a lot about the use of svg fonts and woff > fonts we found important use cases for svg fonts the first is to > use svg fonts to support emoji characters > > JF: which are part of unicdode 6.0 they can be animated opentype > cannot support emoji characters, but svg fonts can emoji is very > important for japanese, since there are many mobiles targetted > towards keitai users As noted, to support full-color versions of these would require the SVG Full 1.1 version of SVG Fonts that allow glyphs with arbitrary content, which is not widely implemented. I should also point out here that after these were defined there has been a general trend away from using emoji in Japan, switching to so-called "decomail" which is just HTML mail with embedded images. Decomail explanation: http://www.nttdocomo.co.jp/english/service/imode/make/content/deco_mail/mechanism/index.html Decomail, the video (Anthony you must watch this immediately): http://www.youtube.com/watch?v=T7rlJwHbe7w&feature=player_embedded > AD: corel draw e.g., you can click export and it will subset > system fonts and turn them into svg fonts Doing so will extract outlines for the default glyphs but it will completely lose all specialized font metrics, feature tables that allow access to alternate variant glyphs, language-specific variants, and support for complex shaping. > JF: yes the other use case includes in japan we need to support > variation characters the current implementation of browsers and > ereading systems does not support IVS yet but that's easy with > svg fonts. you can easily define variation characters using the > svg font mechiansm. you can just use the variation selector, so > that text content is a proper unicode sequence you can use svg > font defined variation characters > > BB: do you ever have e.g. novels where they want to use a new > character that's not in the set? > > JF: also there can be one or two special characters in a novel > that are not covered in unicode > > BB: with the unicode variant, is this a backwards compat issue? > i believe in firefox we allow variants to be selected from fonts > > RO: why wouldn't the variant selectors work with opentype? > > JF: because some leading systems, their OSes don't support > variation selectors and it's sometimes difficult to implement on > those systems Unicode variation selectors are supported in Firefox 4 on all platforms. The requirements are an OpenType font with a format14 character map, one that establishes the mapping between selector values and variant glyphs. An example would be Adobe's "Kozuka Mincho ProN". No commercially available OS ships with a font supporting IVS, not OSX, not Windows 7 nor any version of Android. (If there is I would love to be corrected). To support variation selectors in SVG Fonts would require extra work, work that's already been done with OpenType fonts. Why is this a use case for SVG Fonts? As for characters not in Unicode, I don't see why SVG Fonts is any different than OpenType, authors would need to define a font using PUA codepoints, this is typically what authors working with scripts not yet encoded in Unicode also do.
Received on Wednesday, 2 March 2011 08:52:36 UTC