Difference between revisions of "SVGFonts"
m (Typo fix: "on line" -> "online") |
m (typo fix: "Borris" --> "Boris") |
||
Line 256: | Line 256: | ||
== An estimation of the additional security risk of implementing SVG fonts == | == An estimation of the additional security risk of implementing SVG fonts == | ||
− | As [http://developers.slashdot.org/comments.pl?sid=1713004&cid=32847010 | + | As [http://developers.slashdot.org/comments.pl?sid=1713004&cid=32847010 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>. | 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>. |
Revision as of 19:47, 8 March 2011
This page is build from suggestion of Jeff Muizelaar on Implement SVG Font bug, Thanks to him. A proposal for a third way solution by Robert O'Callahan is here : SVG OpenType Fonts
Contents
- 1 A technical comparison of WOFF vs. SVG formats
- 2 Size Comparison
- 3 A comparison of the tools available for creating SVG vs WOFF fonts
- 4 An estimation of the added code complexity required
- 5 An estimation of the additional security risk of implementing SVG fonts
- 6 A suggested subset of SVG to be supported in fonts
- 7 A list of use-cases for SVG fonts
- 8 Internationalization Issues
A technical comparison of WOFF vs. SVG formats
Comparison Table (tentative)
Features | WOFF Fonts | SVG Fonts |
---|---|---|
Coordinates | Flow | Absolutes |
Main context | Flowing text and headings in an HTML page | Fixed text and headings in a vector graphic file |
Pixel perfect | Yes | No, most of the time |
Vector outlines | No | Yes always |
@font-face linking | Yes | Yes |
embeddable in a single SVG file | Yes1 | Yes |
CSS styling | Yes | Yes |
Metadata | Yes | Yes |
DOM access | No | Yes |
XML human-readable tags, editable with a text editor | No | Yes |
Javascript interaction | Yes, but difficult | Yes, easy |
Compression | Yes (built-in) | Yes (SVGZ) |
Text decoration | Yes | Yes |
Kerning | Yes | Yes |
Hinting | Yes | No |
Word spacing | Yes | Yes |
Overflow | Yes | No2 |
SVG Filters | Yes3 | Yes |
SVG SMIL Animation | Yes, in a SVG file, but not at a glyph level | Yes |
Can be put along a path | Yes, in a SVG file | Yes |
Gradiant text | Yes, in a SVG file | Yes |
Arbitrary glyphs | No ? | Yes |
Text in a Shape4 | No ? | Yes4 |
Interaction with other SVG modules | Mostly ? | Yes |
Complex shaping languages support | Yes, advanced | Yes, but basic and incomplete5 |
Opentype forward-compatible6 | Yes | No |
Implementation strategy | Wrap Opentype | Implement W3C spec |
Security issues ? | No (well tested) | Potential, have to be scoped |
jrmuizel: please take out entries that are the same for both woff and svg yagraph: Is it working for you with background colors ?
1 using data: URIs.
2 But planed for SVG 2.0.
3 Through Mozilla CSS-SVG filters extension.
4 Or "Link flowed text" text, proposed in the SVG 1.2 Draft and adopted by Inkscape
5 very limited support for shaping: ligatures and some very simple Arabic support only
6 Will receive all the benefits of the font industry's ongoing efforts to improve the OpenType specification with new font features and language support
WOFF fonts
what is it ?
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: Wikipédia)
W3C Specification
WOFF Features
- Meant to be used in a flow of text in an HTML document
- Pixel perfect with a correct render engine
- Essentially the same features than Truetype or Opentype fonts, but compressed and with metadata, to be embedded on the web as a "package" file, in a similar way than an image.
- can be used for regular text through @font-face
- can have metadata
- stylised with CSS
- kerning
- hinting
- full support for shaping for any language supported by OpenType
- forward-compatible: will receive all the benefits of the font industry's ongoing efforts to improve the OpenType specification with new font features and language support
- text decoration
- overflow
- can be put along a path
- can receive SVG filters through Mozilla CSS-SVG filters extension
- no DOM access to glyphs or subsets
- not meant to be animated
- not meant to be used as a drawing element in a vector context (no alignment, transform, etc.)
roc: I have no idea what this means. You can use WOFF fonts in SVG just fine.
- concise spec, so easy to implement
SVG fonts
what is it ?
All versions of the SVG 1.1 specification, including the SVGT subset, define a font module, allowing the creation of fonts within an SVG document. The SVG specification allows for CSS to be applied to SVG documents in a similar manner to HTML documents, and the @font-face rule can be applied to text in SVG documents. (source: Wikipédia)
W3C Specification
SVG 1.1 Fonts module SVG Tiny 1.2 Font module
SVG Fonts Features
- Sub-set of the Scalable Vector Graphics specification. Meant to be used in a vector design context with all SVG features and others modules.
- Vector outlines
- Absolute coordinates
- DOM access to glyphs or subsets
- Can be embeded in a SVG file as a DOM element among others without adding or linking more files (SVG as a "document" format).
- Editable in a text editor, with human-readable tags
- Can be styled with CSS
- Works with @font-face
- Can contain metadata
- Kerning
- Word Spacing
- Text Decoration
- Can be animated
- Can receive gradients
- Can be put along a path
- Can receive SVG filters
- No hinting
- No overflow (but planed for SVG 2.0)
- Limited support for shaping: ligatures and some very simple Arabic support only
Size Comparison
Yagraph
WOFF: With @font-face generator, the DejaVu font converted to WOFF result in a 23,6 Kio file.
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
- 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
SVG Fonts creation tools
SVF Font can be obtained from converters, but they also come from creation tools (textual or graphical).
- any text editor
- FontForge (FOSS font editor tool)
- Inkscape (FOSS SVG authoring tool)
- 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
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.
- 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
- 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.