Re: SVG Fonts [...]

Boris Zbarsky:
>And the UAs in question support nothing outside SVG Tiny 1.2?

I think, this is just an intended coincidence, because what
ist noted in SVG tiny 1.2 about fonts is just a subset of SVG 1.1.
There is nothing significant new in it.
Those, that interprete already the font chapter of SVG 1.1 will have
no problem to present what is mentioned in SVG tiny 1.2 as well,
as long, as newer features from SVG tiny 1.2 not directly related
to fonts are avoided, for example the xml:id to identify the font.

For example the adobe plugin and Batik/Squiggle interprete
this part of the font issue. And both are no typical suspects to
interprete specifically SVG tiny 1.2 ;o)
For all (adobe plugin) or most (Batik/Squiggle) features really
specific for SVG tiny 1.2 both fail in my tests.

>>Erik Dahlstrom: 
>> And of course there are more implementations that support
>> SVG Fonts, e.g Inkscape, Illustrator and various other tools.

>Same question.

These are not specific viewers for SVG tiny 1.2 as well.
Indeed, the first time I have seen some individual font at
all was in a document created with the Illustrator and saved as SVG
with embedded glyphs.
And this was long before SVG tiny 1.2 appeared.

But of course, we can summarise:
There are no viewers currently that support SVG fonts somehow 
- well except of this larger amount, that simply does it ;o)
A few can only interprete the attribute variant (as currently Opera for
example), more can interprete arbitrary content for the glyph element as well.

Due to my tiny amount of tests, indeed there seem to be much more problems
with the use of external fonts, especially if referenced with the 
CSS-font-face rule (I have not seen, that this is interpreted in any viewer I 
have available). 
For authors there is a much better probability to get the intended 
effect today by using SVG notation and even better to embed the glyphs 
in the same document...


The SVG 1.1 font chapter itself has some minor problems. 
For example a few elements and attributes are not mentioned at all in the
prose, authors have to extract them from the DTD fragments and guess,
what might be the meaning of those features.
However, I think, someone cared already about this and added some prose
in the draft for the second edition ...
But I did not find a hint about using 'svg' as the value for the 
attribute 'string' of 'font-face-format' - at least there are some rumors 
around, that this might be a nice value for SVG fonts, but there is currently 
not really a recommendation for it and the question, why not to use a 
content/MIME-type in general- but this is a question for the CSS WG as well -
how to extent this feature, if new formats (like WOFF?) appear without
changing each time the recommendations?
By the way - what happened to the element 'definition-src' in the draft of
SVG 1.1 second edition?


Boris Zbarsky:
>All I claimed is that the various implementations of SVG 1.1 Fonts in 
>particular:
>
>1)  Are incomplete.
>2)  Implement different subsets of SVG 1.1 Fonts
>3)  Don't agree on some parts that more than one implements.

Similar applies currently for (most?) other chapters and sections of 
SVG 1.1 as well.
For example there are several issues about stroking in several 
viewers - does it mean, that there should be no stroking or does
it mean, that the bugs and gaps should be fixed?
I have seen bugs in presenting basic shapes and as well for 
the interpretation of the path d attribute - but can we draw
another conclusion as to analyse the bugs and gaps an fix them,
that authors simply can really start to use SVG?



Olaf

Received on Monday, 7 June 2010 15:55:00 UTC