RE: SVG Fonts inside of OpenType fonts? [Cross-post from]

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,

> 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:32 UTC