font formats and SVG2 (was Re: minutes, SVG WG Auckland F2F, day 3)

[cross-posting to the general SVG list]

>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 09:53:39 UTC