W3C home > Mailing lists > Public > www-svg@w3.org > June 2010

Re: SVG Fonts [...]

From: Chris Lilley <chris@w3.org>
Date: Fri, 4 Jun 2010 10:30:05 +0200
Message-ID: <921226834.20100604103005@w3.org>
To: "Robert O'Callahan" <robert@ocallahan.org>
CC: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>, www-svg@w3.org
On Thursday, June 3, 2010, 12:52:26 AM, Robert wrote:

ROC> 2010/6/3 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
ROC>  I think, the main advantage of SVG fonts is,
ROC>  that if an author needs 20 exactly defined glyphs
ROC>  for an SVG document, he can create them
ROC>  with the same tools as the other content of the document
ROC>  without the need to care about other formats or software.
ROC>  This is a very big advantage.
ROC>  It is an option to get high quality and predictable results,
ROC>  if this matters, with low efforts.

ROC> In general SVG fonts are going to be lower quality, in terms of rasterization.

You have stated that without demonstration. What is your source for the statement?

ROC>  Of course, if there is no such option or viewers to not interprete
ROC>  this option, many authors will just use a feature from programs
ROC>  like inkscape to convert text into inaccessible paths, difficult to edit
ROC>  afterwards and not readable anymore without the graphical
ROC>  representation.

(That is exactly the situation that SVG Fonts were designed to address)

ROC> It would be easy to create a very simple tool to convert SVG
ROC> glyph outlines into an Opentype font

Again, it would be nice to see this statement backed up. SVG glyph outlines can contain arbitrary path commands, be self-intersecting, can have overlap, and do not require control points placed at extrema. TrueType glyph outlines can only use a single type of Bezier curve, cannot self intersect or overlap, and are constrained to have control points at specific places.

So a conversion does not seem straightforward.

Conversion of outlines in the other direction is of course straightforward.

ROC>  --- and back again, for the
ROC> simple cases that can be represented with SVG.

ROC> Opentype is not a cryptic or obscure format. It is the font
ROC> format used by almost all font designers. There are very many
ROC> free and non-free tools that work with Opentype. Probably more
ROC> people work with Opentype daily than SVG.

Yes, OpenType is widely deployed and the patents on the TrueType hinting by Apple and Microsoft are believed to have expired recently.

OpenType has superior internationalisation capability compared to SVG Fonts, and allows hinting (although for rasterisation at non-integer pixel sizes, or at arbitrary rotations, the hinting instructions will not work).

SVG Fonts are the equivalent of PostScript type 3 fonts - graphically rich and programable.

Personally it seems clear that both OpenType (as WOFF) and SVG Fonts have a place in SVG, serving different needs.

ROC> It would be a mammoth task to extend the SVG Fonts spec to
ROC> handle all the features of Opentype, especially shaping for all
ROC> the world's complex scripts. 

Yes, it would. I don't think it is worth doing. 

OpenType also does not cover all the world's scripts, of course. I did present a paper at a Unicode conference on what would be neeed to extend SVG Fonts with Graphite, which would give more script coverage than OpenType. But again, i don't think that is the way to go at this point.
ROC> Then of course SVG implementors
ROC> would have to add shaping engines for those scripts. 

Yes, for OpenType. (Graphite does not require this).
ROC> (We already
ROC> have the shaping engines implemented for Opentype.) This is never
ROC> going to happen. For this reason alone, SVG Fonts are a dead end
ROC> as a general-purpose font format.

ROC> That would require us to limit SVG fonts to just what is
ROC> possible in Opentype, 

No real point in doing so.

ROC> so then we're talking about yet another kind of SVG Fonts:
ROC> a) SVG 1.2 Tiny Fonts
ROC>  b) SVG 1.1 Full Fonts
ROC> c) SVG ... Opentype-Compatible Fonts

ROC> (I'm not sure if (c) and (a) are the same or not; it sounded
ROC> like "overlaps" are possible in (a) but not (c)?)

Correct, among other restrictions.

a) is currently well supported by authoring tools and by implementations on mobile; inconsistently supported by implementations on the desktop.

b) is the more interesting case, because it allows things that OpenType does not - scriptable fonts, animated fonts, video fonts, multicoloured fonts, and so forth.

c) is pointless.

 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Friday, 4 June 2010 08:30:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:26 UTC