Re: SVG 2 Features and Approach

Tab Atkins Jr.:
>
> Or, as stated earlier in this thread, embed SVG outlines in an
> OpenType table, which already works in Firefox.
>
> ~TJ

There are some other options as well, continue to use SVG 1.1 or SVG tiny 1.2.
Especially it cannot be expected, that already published viewers interprete
such new methods, not specified at all.
For authors there is a situation with several older viewers being able to
interprete SVG fonts and a few browsers, that do not want to interprete
it, but provide maybe other methods, not available for those viewers,
who already interprete SVG fonts for years. 
It does not really help authors to know, that ~10 viewers interprete
a subset of SVG fonts, some current versions of some (~4) browsers
interprete WOFF and one version of one browsers yet another
method to note OpenType within the SVG document in a way, that
is not specified at all and surely not using SVG path data notation - or
to put the SVG path data into another binary file format with methods
not available with a text editor - why to do all this, is one simply can
note the SVG path data in the same SVG file without the need for
specific programs and methods to create font format files, one is not
interested in?

For those viewers, who have bugs and gaps, one can simply add 
generic font families like serif or sans-serif to keep the content 
at least accessible for those, who use such viewers.
Additionally on can use a switch with requiredFeatures to display a
warning, that users may use a more advanced viewer to see the
intented graphical document representation ;o)
Or one can use other switch methods to provide a simple text
alternative only (for example as pure XHTML instead of SVG).

I think, authors really using SVG will be not much motivated
to learn yet another language to provide the path data for
glyphs in such another format, if they already know how to
specify such paths in SVG.
And to learn to put the SVG path data into another format
sound ridiculous, because already a simpler method is
specified, how to put it directly into the SVG file. 
Therefore to use fonts in other formats is only an option, 
if one wants to reuse only fonts from other people, who 
are familar with the other formats.
If one wants to provide some text with some 'crazy' own
glyphs, one wants to use SVG to specify them, not another
format. If some viewers have bugs or gaps in interpreting
this, it is reasonable to downgrade their display to a pretty
basic level as the mentioned pure XHTML instead of SVG
graphics to keep the users informed about the essential
content without advanced graphic repesentation ;o)

But if one really wants some 'crazy' glyphs for all viewers and
browsers, best choices is still, to use only arbitrary path
data with usual command combinations, because this
is interpreted correctly in all viewers and browsers.
There are typically only a few bugs in path data interpretation
with unusual command combinations, one can simply avoid.
Therefore this really works and is not a mysterical illusion.


Olaf

Received on Friday, 11 January 2013 11:14:25 UTC