Confirmed users, Bureaucrats and Sysops emeriti
969
edits
SVGOpenTypeFonts: Difference between revisions
Add FontTools to the list of tools
(Add FontTools to the list of tools) |
|||
| (23 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
= Introduction = | = Introduction = | ||
This is an old page. More up-to-date work-in-progress documentation on SVG-in-OpenType can be found at http://dev.w3.org/SVG/modules/fonts/SVG-OpenType.html or, even more recently, here http://lists.w3.org/Archives/Public/public-svgopentype/2013Jul/0003.html | |||
== Use Cases == | == Use Cases == | ||
| Line 28: | Line 30: | ||
= SVG OpenType Fonts = | = SVG OpenType Fonts = | ||
[http://robert.ocallahan.org/2013/02/svg-in-opentype-new-approach-to-svg.html Robert O'Callahan's proposed alternative to SVG fonts] is to embed SVG glyph data in OpenType fonts, and draw glyphs by rendering that SVG. Use the OpenType data for everything other than glyph drawing (metrics, shaping, etc). | |||
The current status of this proposal is that it has [http://lists.w3.org/Archives/Public/public-svgopentype/2013Oct/0002.html worked its way through the W3C process] and is now a [http://www.w3.org/2013/10/SVG_in_OpenType/ proposal] that has been put forward by the W3C for consideration by the MPEG group (which owns the [http://mpeg.chiariglione.org/technologies/media-coding/font-coding Open Font Format] (aka OpenType) spec within ISO). | |||
== Tools == | |||
The current tools for creating SVG-in-OT fonts are basic, and possibly out of date. | |||
* [https://github.com/rocallahan/svg-opentype-workshop Robert O'Callahan's tools] | |||
* [https://github.com/edf825/SVG-OpenType-Utils Edwin Flores's tools] | |||
* [http://lists.w3.org/Archives/Public/public-svgopentype/2013Dec/0003.html Read Roberts's tools] | |||
* [http://www.fontlab.com/font-converter/transtype/ TransType] (conversion only) | |||
* [https://github.com/behdad/fonttools/releases FontTools] Can be used to convert an OpenType font to XML so that you can insert/view/edit SVG tables (in an XML/text editor) and then recompile the font back into otf or ttf. | |||
= Prototype Implementation = | = Prototype Implementation = | ||
| Line 45: | Line 59: | ||
!Description | !Description | ||
|- | |- | ||
|<code> | |<code>version</code> | ||
|<code>USHORT</code> | |<code>USHORT</code> | ||
|The | |The version of the SVG table—currently 1 | ||
|- | |- | ||
|<code>numIndices</code> | |<code>numIndices</code> | ||
| Line 54: | Line 68: | ||
|} | |} | ||
This is followed by <code> | This is followed by <code>numIndices</code> index entries: each entry specifies a range of glyph IDs and location of the SVG document in the table for those glyph IDs. The index must not contain any intersecting glyph ID ranges and entries must be sorted in ascending order by glyph IDs. Index entries may share <code>(documentOffset, documentLength)</code> pairs, but may not have intersecting non-equal document locations. | ||
{| class="wikitable" | {| class="wikitable" | ||
| Line 85: | Line 83: | ||
|The last glyph ID mapped by this entry | |The last glyph ID mapped by this entry | ||
|- | |- | ||
|<code> | |<code>documentOffset</code> | ||
|<code> | |<code>ULONG</code> | ||
|The | |The offset from the beginning of the SVG table where the SVG document can be found containing glyphs for this range | ||
|- | |||
|<code>documentLength</code> | |||
|<code>ULONG</code> | |||
|The length of the SVG document for this glyph range | |||
|} | |} | ||
Finally, the SVG documents themselves which are to be UTF-8 encoded, and whose length and offset are described by the document list above. | Finally, the SVG documents themselves which are to be UTF-8 encoded, and whose length and offset are described by the document list above. | ||
With this design, authors can easily create small fonts by putting all glyphs in a single document. They can also create efficient large fonts by putting each glyph in its own document. A UA could avoid managing too many SVG documents when rendering many glyphs, by rendering glyphs to a cache of glyph bitmaps and discarding their SVG documents as needed. | |||
== Structure of the SVG Document == | == Structure of the SVG Document == | ||
| Line 106: | Line 108: | ||
== SVG Glyphs == | == SVG Glyphs == | ||
The glyphs themselves have an em-height of 1000 units | The glyphs themselves have an em-height of 1000 units with the baseline at y=0. (Note that the SVG 'viewbox' attribute can be used to easily select a different coordinate system.) The ink bounding boxes specified in the OpenType metrics tables are ignored; the ink bounding-box of each SVG glyph DOM subtree is used instead. | ||
Two new paint server values are defined for use in SVG glyphs: <code>objectFill</code> and <code>objectStroke</code> (currently prefixed as <code>-moz-objectFill</code> and <code>-moz-objectStroke</code>). These values specify the fill or stroke applied to the text in the document that uses this font. Unlike SVG 1.1's style inheritance approach, they automatically take account of the change in coordinate systems from the document containing the text to the glyph document. | |||
Two new values for <code>fill-opacity</code> and <code>stroke-opacity</code> are defined: <code>objectFillOpacity</code> and <code>objectStrokeOpacity</code>, which evaluate to the fill and stroke opacity applied to the text in the document that uses this font. Either value can be used with either property. Also, if <code>objectFill</code> is a fully transparent color, <code>objectFillOpacity</code> evalutes to zero, and likewise for <code>objectStroke</code> and <code>objectStrokeOpacity</code>. (This allows authors to easily set the fill colors of glyph parts while still not rendering anything in those parts when the text is not being filled.) | |||
A new value <code>objectValue</code> is defined for the <code>stroke-width</code>, <code>stroke-dasharray</code>, and <code>stroke-dashoffset</code> properties. This value evaluates to the value from the text in the document using this font, appropriately adjusted for the scale in the coordinate systems from the text document to the glyph document. | |||
'''Question: is it worth supporting 'custom stroking' of SVG glyphs, or should we just make stroking stroke the path defined by OpenType, and remove all the special stroking-related properties above? It might be quite hard for authors to effectively use custom stroking.''' | |||
== Security == | == Security == | ||
For security's sake the SVG document is not allowed to refer to external resources—it may, however, contain resources in the form of <code>data</code> URIs. Moreover, | For security's sake the SVG document is not allowed to refer to external resources—it may, however, contain resources in the form of <code>data</code> URIs. Moreover, scripting is disabled in the glyphs document. | ||
Animation | Animation is enabled. (But not yet supported in Gecko.) | ||
== Example == | == Example == | ||
| Line 133: | Line 141: | ||
Adobe are keen on a similar idea, an early proposal of which can be found [http://lists.w3.org/Archives/Public/public-svgopentype/2011Oct/0000.html here]. | Adobe are keen on a similar idea, an early proposal of which can be found [http://lists.w3.org/Archives/Public/public-svgopentype/2011Oct/0000.html here]. | ||
The main differences I can see are that each glyph definition has a whole SVG document. Also, they have two glyph definitions per actual glyph -- one static, one animated. I don't think this is necessary, though; we can let static glyphs be the glyph without any animations applied. | The main differences I can see are that each glyph definition has a whole SVG document. Also, they have two glyph definitions per actual glyph -- one static, one animated. I don't think this is necessary, though; we can let static glyphs be the glyph without any animations applied. Note that it's easy to create a glyph DOM subtree containing separate "static" and "animated" glyphs such that if SMIL is enabled, the animated glyph is drawn, otherwise the static glyph is drawn. | ||