14
edits
SVGOpenTypeFonts: Difference between revisions
no edit summary
No edit summary |
|||
| Line 47: | Line 47: | ||
A better design would be to specify new values for 'stroke', 'fill' and 'stroke-width' such as 'text-stroke', 'text-fill' and 'text-stroke-width' to be used in glyphs. These new values would automatically grab the stroke, fill and stroke-width from the text, rescaling them as necessary. | A better design would be to specify new values for 'stroke', 'fill' and 'stroke-width' such as 'text-stroke', 'text-fill' and 'text-stroke-width' to be used in glyphs. These new values would automatically grab the stroke, fill and stroke-width from the text, rescaling them as necessary. | ||
= Where We Are At The Moment = | |||
== The SVG table == | |||
We define a new optional OpenType table '<code>SVG </code>'. This table contains a UTF-8 encoded SVG document. | |||
== Structure of the SVG Document == | |||
Two additional attributes are supported in this SVG document: <code>glyphid</code> and <code>glyphchar</code> which may be used on graphics elements or container elements. <code>glyphid</code> is a number specifying which glyph ID is associated with this glyph. | |||
<code>glyphchar</code> is a string of at most one character optionally followed by a unicode variation selector. The glyph ID to associate with the glyph is then resolved using the <code>cmap</code> table. | |||
If two elements have the same glyph ID, then the first element in the document with that glyph ID is associated with it. | |||
== The SVG Glyphs == | |||
The glyphs themselves have an em-height of 1000 units (although maybe worth changing to 2048 to match TrueType convention) with the baseline at y=0. The width:height ratio of the glyph is to be the same as in the TrueType font. | |||
There are two new paint values <code>objectFill</code> and <code>objectStroke</code> for use in SVG glyphs. These values inherit the paint from the outer object. We also plan on adding things like <code>objectStrokeWidth</code>, <code>objectStrokeDasharray</code>, etc. | |||
== Adobe's Proposal == | |||
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 think we should just allow the author to specify a specific frame to use when not animating; I can't really think of any use case where the static version wouldn't be a frame of the animated one. | |||