- From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
- Date: Thu, 30 Jun 2011 11:52:02 -0400
- To: Alex Danilo <alex@abbra.com>, "robert@ocallahan.org" <robert@ocallahan.org>
- CC: Erik Dahlstrom <ed@opera.com>, Tab Atkins <tabatkins@google.com>, "list.adam@twardoch.com" <list.adam@twardoch.com>, "www-font@w3.org" <www-font@w3.org>, "www-svg@w3.org" <www-svg@w3.org>, "www-style@w3.org" <www-style@w3.org>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>, OpenType List <opentype-migration-list@indx.co.uk>
On Wednesday, June 29, 2011 9:33 PM Alex Danilo wrote: > > Also, Vladimir wrote: ""This is exactly where the weakness of the SVG > is - the glyphs inside > SVG fonts are identified by the <unicode> strings and while this can be > made to work for > one-to-one and many-to-one mappings - it doesn't work for one-to-many > mappings in a generic way." > > This is incorrect. If an implementation does SVG Full fonts, then the > content can contain <use> elements. > I am not sure what you mean by content. Would plain sequence of Unicode codepoints be considered a content? > So, the glyph geometries themselves can just sit in a <defs> or > wherever, and you could > even use their 'id' as your glyph index. Then the <glyph> elements in > the SVG font can > reference an arbitrary number of them. i.e. one-to-m, n-to-m and n-to- > one mappings > are all possible with the SVG font spec. as is, no changes required. > > It is a fact that an authoring tool is capable of outputting SVG font > outlines for glyphs > etc. as a single self contained file with no rendering ambiguity. > Furthermore, language > dependent rendering can be achieved with <switch> if you wish. I am sorry, I don't understand half of the above (I'm sure due to my limited knowledge of SVG Full fonts). Maybe a simple use case could help illustrate this workflow better: I have an SVG Full font and a string of Unicode characters that belong to a complex script where each character may be represented by one of many glyphs available in SVG font, and where a number of various character combinations may need to be replaced by a single glyph (ligature). I expect to get a readable text displayed as the result. What would have to happen for a text to be rendered correctly? Thank you, Vlad > > ASV had animating SVG Fonts ages ago as do I. > > I don't see that shoving SVG Fonts into an OpenType container does > anything more > than force us to restrict them in arbitrary ways and so seems a bit > silly. > > If the existing SVG Font mechanism isn't sufficient for PDF->SVG > workflow (which > it isn't) then that's orthogonal. The glyph indice thing is a red > herring since the mappings > are all possible now and if the SVG Font is in the SVG file then the > rendering is > predictable, more so than PDF... > > XML compressed or not in a font file makes me queasy. > > Alex >
Received on Thursday, 30 June 2011 15:52:40 UTC