Difference between revisions of "SVGFonts"

Revision as of 09:42, 10 March 2011

A proposal for an alternative to SVG Fonts by Robert O'Callahan is here: SVG OpenType Fonts

A technical comparison of WOFF vs. SVG formats

WOFF fonts

WOFF is essentially a wrapper that contains sfnt-based fonts (TrueType, OpenType, or Open Font Format) that have been compressed using a WOFF encoding tool to enable them to be embedded in a web page. The format uses zlib compression (specifically, the compress2 function), typically resulting in a filesize reduction from TTF of over 40%. (source: Wikipedia)

W3C Specification: WOFF file Format 1.0

SVG Fonts

SVG Fonts is a feature of SVG that allows SVG to be used as glyphs when displaying text (applied using the CSS @font-face rule).

There are actually two versions of SVG Fonts with different capabilities (which are unfortunately constantly being conflated in discussion and on this page). SVG Tiny Fonts from the SVG Tiny 1.2 specification allows only path outlines in glyphs. SVG Full Fonts from the SVG 1.1 Full specification allows arbitrary SVG content in glyphs.

yapgraph : Do you think that we should separate SVG Tiny and SVG Full in the table ? And add Roc SVG Opentype proposal ?

Features comparison Table

¹ using data: URIs.

² But planed for SVG 2.0.

³ Through Mozilla CSS-SVG filters extension.

⁴ Or "Link flowed text" text, proposed in the SVG 1.2 Draft and adopted by Inkscape

⁵ very limited support for shaping: ligatures and some very simple Arabic support only

⁶ Will receive all the benefits of the font industry's ongoing efforts to improve the OpenType specification with new font features and language support

⁷Font files can be edited with a text editor using ttx It suppose at least two conversion to manipulate a file, and TTX can't manipulate WOFF file in the latest version. you have to rely on woffTools, which can't generate a ttx file from a WOFF file now.

⁸ SVG 1.1 Full allow to draw anything and define it as a glyph

jrmuizel: please take out entries that are the same for both woff and svg / yagraph: Is it working for you with background colors ? / jrmuizel: I don't see the point of having them at all / yagraph: Some people (including me) may suppose that an unlisted feature is not supported by one part (example with Text in a Shape), so I prefer to let it be visible and known /

jrmuizel: what does "arbitrary glyphs" mean? / yagraph : SVG allow to draw anything and define it as a glyph, including shapes that are supposed to be "forbidden" in Opentype glyphs. As Roc listed in his SVG OpenType Fonts proposal : Editable text where the glyphs display a "shiver" effect, Draw freehand graphics with self-intersecting curves and use them as glyphs, Japanese "emoji" with colored glyphs. And I can add a blurred character with SVG filters, Animated glyphs, Gradient filled glyphs, Spiro spline curves drawed glyphs...

yagraph : Removed "Subpixel antialiasing" feature : it's not a format feature but a render engine feature. Depending on the render engine, SVG is most of the time antialiased, as Opentype

Size Comparison

yagraph

WOFF: With @font-face generator, the DejaVu font converted to WOFF result in a 23,6 Kio file.

jrmuizel: does the woff file include additional tables that svg file does not? / yagraph : I don't think so... But I'm not sure. I asked for the same subsets. jrmuizel: if you convert the SVG font to WOFF how big a file do you get? yagraph: I can't find any tool able to do to such a conversion, sorry.

SVG: With @font-face generator, the DejaVu font converted to SVG result in a 52,5 Kio file (uncompressed).

SVGZ : With @font-face generator, the DejaVu font converted to SVGZ result in a 13,5 Kio file.

roc

I uploaded the DejaVu Sans Book Regular font from http://www.fontsquirrel.com/fonts/DejaVu-Sans (DejaVuSans.ttf, 622020 bytes) to the Generator with the default options, except I enabled SVGZ format. In the resulting package, dejavusans-webfont.ttf was 538612 bytes, dejavusans-webfont.svg was 1485741 bytes, dejavusans-webfont.svgz was 317012 bytes, and dejavusans-webfont.woff was 287516 bytes.

A comparison of the tools available for creating SVG vs WOFF fonts

WOFF creation tools

Most of the time, a WOFF file is obtained through a converter tool jrmuizel: I don't think it's valuable to include conversion tools here

• FontForge (FOSS font editor tool)
• sfnt2woff command line tool
• The python command line woffTools used with TTX/FontTools.
• Font Squirrel online converter : @font-face generator
• Fontographer
• FontLab Studio

SVG Fonts creation tools

SVF Font can be obtained from converters, but they also come from creation tools (textual or graphical). jrmuizel: converting from other formats takes away most of the advantages that SVG fonts could have. It's also important to note whether a tool produces just SVG or actual SVG fonts.

• any text editor
• FontForge (FOSS font editor tool)

jrmuizel: Does FontForge support any features with SVG fonts that it doesn't support with other formats? / yagraph: I not aware of any. SVG font is an output among others in Fontforge. /

• Inkscape (FOSS SVG authoring tool) yagraph: Since v0.47, Inkscape include an Initial SVG Fonts support, and can be included in a font creation workflow
• Font Squirrel on line converter : @font-face generator
• SVGmaker

An estimation of the added code complexity required

for implementing SVG fonts

Said simply, it seems important.

Maybe we can start with Acid3 compliance. Then SVG Tiny 1.2 Font module, can be a good subset. Ultimately, Mozilla had once claimed to target the full SVG 1.1 Fonts module implementation.

But part of the spec is already implemented.

(--yagraph : I have no real skill for such an estimation, so if you know more, please precise)

If SVG fonts are implemented as anything more than monochrome glyphs, they will need to go through a different code path than other fonts.

An estimation of the additional security risk of implementing SVG fonts

As Boris Zbarsky points out "Once you put an <iframe> in a glyph, all sorts of issues arise". SVG is powerful, so security holes can be proportionally important.

But SVG Fonts do not introduce particularly more dangerous behaviors the the rest of the SVG Spec. After all, we can put an <iframe> in any <path>, and it should not behave more badly than in a <glyph>.

Probably, some features will have to be scoped for security reasons, but iframes in glyph aren't an expected feature of SVG Fonts.

(--yagraph : I have no real skill for such an estimation, so if you know more, please precise)

A suggested subset of SVG to be supported in fonts

SVG Tiny 1.2 Font module can be a good starting subset.

Part of the spec is already implemented.

The "Implement SVG Font" bug report contain additional infos, patchs and test cases

Most important elements for a good start :

• text-decoration (bug report).
• kerning
• word spacing
• font
• glyphs
• glyph-name
• missing-glyph
• d
• unicode
• lang

What subsets do other browsers support ?

• Comparison of various Scalable Vector Graphics element support (Wikipedia)
• Webkit : Webkit SVG status
• Opera : SVG Attributes support in Opera Presto 2.4
• IE9 : none

jrmuizel: this section needs to contain information on what svg font subset other browsers support. i.e. do any of them support color?

A list of use-cases for SVG fonts

that are not well supported by existing technologies

• Fancy, animated titles and presentation on the web, keeping semantic, without any @font-face linking (here is a mostly working example, rely on WOFF to compensate lack of SVG Fonts in Firefox, and here is another, but text is converted to path).

roc: What's wrong with @font-face linking? It's just a different syntax for referencing a font. / yagraph: In some context, we can't link another file with @font-face, for example a SVG animation to add in Wikipedia, or in SVG as a single document linked in an email context.

jrmuizel: The fancy titles use case seems mostly served by an svg image with alt text. / yagraph: You're right, but you loose text selection, and an alt attribute do not have the same semantic value than a text tag ...

• Produce a SVG document with some text in Inkscape, Adobe Illustrator, or any SVG authoring tool, and render it correctly within Firefox.

jrmuizel: does Adobe Illustrator produce SVG fonts? Inkscape does not seem to. / yagraph: Since v0.47, Inkscape include an Initial SVG Fonts support, can use them, and can be included in a font creation workflow... But do not seem to be able to produce an SVG Font on it own. Illustrator can save to SVG, but I don't know if it can produce an SVG Font

• Sozi support without killing semantic
• Typism support

jrmuizel: seems like javascript could also just construct a woff file. yagraph: true, but it's a lot of triggers and complexity, for something that can be clean and elegant with SVG Fonts thanks to DOM access. / jrmuizel: there's no reason a javascript library can't provide a clean and elegant api / yagraph: I was not only thinking to construct a WOFF file, but more to manipulate and create glyphs, edit them, etc.

• Could be used for any web-based typographic or typing game with SMIL or Javascript (potential example source (good luck to start such a project with no DOM access !))

roc: We already have Web-based typing games that use Opentype fonts and @font-face. / yagraph: same argument than above : true, but it's a lot of triggers and complexity, for something that can be clean and elegant with SVG Fonts thanks to DOM access

yagraph: I've removed the Erik Dahlström list, irrelevant here as Roc pointed.

Internationalization Issues

SVG fonts support only the most basic shaping controls. For example, Indic languages cannot be reasonably supported by SVG fonts. Also, SVG fonts have no support for positioning diacritics, so all combinations of diacritics and base characters have to be explicitly encoded as ligatures with their own glyphs.

Almost all use-cases for SVG fonts are as valid for Indic and other complex-shaping languages as they are for Latin text. It's not good enough to only solve them for Latin text; the Web needs solutions that work for at least the vast majority of the world's population --- and that can ultimately be extended to work for the entire population.

Therefore, as currently specified, SVG fonts are inadequate for the use-cases listed above. We have two options: extend SVG fonts with support for complex shaping, or find a way to extend some other technology to address the use-cases for SVG fonts.

To date, no-one has shown interest in extending SVG fonts for complex shaping. However, leveraging OpenType shaping to address the use-cases for SVG fonts is definitely possible. See SVGOpenTypeFonts.