SVGFonts

From MozillaWiki
Jump to navigation Jump to search

This page is build from suggestion of Jeff Muizelaar on Implement SVG Font bug, Thanks to him.


A technical comparison of WOFF vs. SVG formats

jrmuizel: this would be better off as a table

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 file Format 1.0

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.
  • Absolute coordinates, most of the time not pixel perfect.
  • can be embeded in a SVG file as a DOM element among others without adding or linking more files (SVG as a "document" format).
  • DOM access to glyphs or subsets
  • fully editable in a text editor, with human-readable tags
  • can be used for regular text through @font-face, but not meant to
  • can be stylized with CSS
  • can have 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)
  • specification is very large, so it's difficult to implement, and can introduce security problems (ex : <iframe> in a <glyph> tag) : have to be scoped.
  • very 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

SVG Fonts creation tools

SVF Font can be obtained from converters, but they also come from creation tools (textual or graphical).

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 Borris 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

jrmuizel: what subsets do other browsers support?

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 suppressed the Erik Dahlström list, irrelevant here as Rob 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.

Retrieved from "https://wiki.mozilla.org/index.php?title=SVGFonts&oldid=289437"