SVGOpenTypeFonts: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "= Introduction = == Use Cases == SVG Fonts address some kinds of use-cases which cannot be addressed using current OpenType-based solutions: * Glyphs of arbitary SVG content (i...")
 
No edit summary
Line 23: Line 23:


Then we could extend the format to allow arbitary SVG content for some or all of the glyphs. We would use OpenType to shape text and apply typographical features, then use SVG just to render the glyphs.
Then we could extend the format to allow arbitary SVG content for some or all of the glyphs. We would use OpenType to shape text and apply typographical features, then use SVG just to render the glyphs.
== API ==
* Support referencing SVG Opentype Font elements from @font-face and the SVG 'font' attribute
* Add an API that takes a DOM reference to a font element and returns a [http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob Blob] for a binary OpenType font (SVG glyphs will be discarded)

Revision as of 04:31, 8 March 2011

Introduction

Use Cases

SVG Fonts address some kinds of use-cases which cannot be addressed using current OpenType-based solutions:

  • Glyphs of arbitary SVG content (including animation)
    • Editable text where the glyphs display a "shiver" effect
    • Draw freehand graphics with self-intersecting curves and use them as glyphs for a font
    • Japanese "emoji" with colored glyphs
  • Create and manipulate structured font data via script and/or text editor
    • Web-based font editors

Internationalization

SVG Fonts have very weak shaping support, which makes them unusable with Indic and other languages. Therefore we need a solution to address the above use-cases that also handles complex shaping. OpenType already supports shaping for most of the world's languages and because of the large ongoing investment in OpenType fonts and processing engines, will broaden its support over time. So, can we leverage OpenType to handle the above use-cases?

SVG OpenType Fonts

Brainstorming exercise: what if we defined an XML serialization of OpenType fonts? Like TTX except better:

  • Use attributes instead of elements where possible.
  • Where values have sensible defaults, allow them to be omitted.
  • Where values are defined in the spec as being easily computable from other font data, compute them in the user-agent. Automatically computing bounds for glyphs would help a lot.

Then we could extend the format to allow arbitary SVG content for some or all of the glyphs. We would use OpenType to shape text and apply typographical features, then use SVG just to render the glyphs.

API

  • Support referencing SVG Opentype Font elements from @font-face and the SVG 'font' attribute
  • Add an API that takes a DOM reference to a font element and returns a Blob for a binary OpenType font (SVG glyphs will be discarded)