Alex Danilo: > > This is incorrect. If an implementation does SVG Full fonts, then the > > content can contain <use> elements. Levantovsky, Vladimir: > I am not sure what you mean by content. Would plain sequence of > Unicode codepoints be considered a content? I think Alex means the content of the <glyph>, i.e. you can have <svg …> <defs> <path id="a" d="M …"/> </defs> <font> <glyph> <use xlink:href="#a"/> … </glyph> </font> </svg> > > 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? In cases where you have a complex script that isn’t supported directly by SVG Font’s ligature and Arabic form features, then you can use <altGlyph> to select an explicit glyph to use for a run of Unicode characters. For example: <font> <glyph id="complex"> … </glyph> </font> <text>The <altGlyph xlink:href="#complex">xyzzy</altGlyph> glyph.</text> -- Cameron McCormack ≝ http://mcc.id.au/Received on Thursday, 30 June 2011 23:01:39 GMT
This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:41 GMT