|
|
| Line 12: |
Line 12: |
| 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 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 = | | = Approach = |
|
| |
|
| Brainstorming exercise: what if we defined an XML serialization of OpenType fonts? Like TTX except better:
| | Embed SVG glyph data in OpenType fonts, and render those glyphs. Use OpenType data for everything else (measurement, shaping, etc). |
| * 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.
| |
| | |
| == Compatibility With SVG 1.1 Fonts ==
| |
| | |
| We should design the serialization to be compatible with a subset of SVG 1.1 Fonts wherever it's easy to do so. If we do this, the proposal can be viewed as taking a subset of SVG 1.1 Fonts, redefining it to be based on OpenType (except for the actual glyph rendering), then adding in syntax for OpenType features such as complex shaping and whatever else is needed. It seems plausible that this would end up being compatible with most SVG 1.1 Fonts usage.
| |
| | |
| == 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)
| |
| * Potentially we could also add an API to convert binary OpenType font data to a DOM subtree
| |
| | |
| == Implementation ==
| |
| | |
| The simple way to do it would be to generate actual OpenType font data, excluding SVG glyph content, and pass that data to Harfbuzz for shaping. Then when drawing glyphs, call back to layout to draw glyphs that have SVG content. For bonus points, convert glyphs consisting of SVG paths into OpenType glyphs when possible, so we get subpixel rendering.
| |
|
| |
|
| = Style Inheritance = | | = Style Inheritance = |