W3C home > Mailing lists > Public > www-svg@w3.org > November 2011

Re: Revisiting SVG Fonts

From: Charles Pritchard <chuck@jumis.com>
Date: Mon, 31 Oct 2011 18:21:02 -0700
Message-ID: <4EAF497E.7050102@jumis.com>
To: Alex Danilo <alex@abbra.com>
CC: Charles Lamont <charles@gateho.gotadsl.co.uk>, www-svg@w3.org
On 10/31/11 5:03 PM, Alex Danilo wrote:
> Hi Charles,
Two Charles's are on the thread. I started it, Mr. Lamont replied.

> --Original Message--:
>> On 31/10/2011 19:30, Charles Pritchard wrote:
>>
>>> I wanted to bring forward my strongest disagreement with Mozilla's stance
>>> against SVG font support.
>>  From the 1.1.2 spec it is not clear to me (being dense) whether or not SVG
>> fonts are meant to enable the production of multicoloured, or otherwise
>> decorated fonts.
> Yes, the SVG 1.1 recommendation as it stands supports font
> glyphs containing arbitrary SVG content, so multi-colour
> etc. is all possible.

Have UA or authoring tool vendors have implemented this?

I've used css sprites, SVG <use>, and I've also used VML with composite 
operations.
They've needed a DOM node for each multi-color [en-US] glyph.

I've seen authoring tools decompose glyphs into outlines and <use> 
references.
When all else fails, they fall back to exporting <image> with embedded 
data uris.

Those fallback methods may mean the file is a magnitude larger and/or 
slower to render.


More on fallback methods:

Authoring tools may not include all of the data needed to re-render the 
image.

Inkscape is a good example of an authoring tool including enough data 
for the image to be read-write. They did have to create a new namespace 
to do it.

Authors may simply use ecmascript to trigger painting, leading to a 
smaller file size but a still bloated DOM and some uncertainty as to 
when to capture a static image. Those files can no longer be used with 
HTML <img>.

David Dailey's SVG <replicate> and the InkML <channel> and <trace> 
elements provide for some more semantics which could be useful for 
advanced glyph placement and other presentational effects.


>> I would like to be able to create glyphs like this sort of thing:
>>
>> http://commons.wikimedia.org/wiki/File:North_Eastern_Railway_Dynamometer_Car_National_Railway_Museum_York_Object_Number_1975-7050.jpg
>>
>> http://commons.wikimedia.org/wiki/File:Carousel.jpg
>>
>> It seems to me that this is precisely the kind of thing SVG is supposed to
>> be for, and that no other potential mechanism exists.
The <use> mechanism would likely work in an authoring tool  but it 
certainly makes hand-coding a bit more work. I'm glad to learn SVG 1.1 
specs support these kind of glyphs.

>> It seem to me that it should be possible to take pretty much any piece of
>> SVG code, with CSS, maybe even with animation of the outline, or whatever,
>> and to declare it to be a character in MySpecialDisplay.SVGfont so that I
>> can use it to assemble text.
>>
>> It seems to me that it should be possible to do this all within SVG
>> without having to get involved in some other rigmarole.
>>
>> If SVG fonts is supposed to make this possible then this is a definite yes,
>> please. And if not, why not?
> It is a definite yes. However, the level of support in different
> browsers/SVG implementations varies. Mozilla and IE support
> no part of any SVG font capability yet.
>
https://developer.mozilla.org/en/SVG/Tutorial/SVG_fonts

"Firefox has postponed implementation indefinitely to concentrate on WOFF"

The issue is not one of resources. Firefox is an open source project.
I've seen posts from their developers and beleive that they will not 
accept a patch implementing SVG fonts in Firefox.

Microsoft, I believe, has signaled that they have not seen much client 
interest.
SVG was only recently implemented in IE.


> All SVG Tiny viewers shipped on close to a billion devices
> so far support the Tiny sub-set of SVG fonts, which supports
> only one path. That is limited in usefuleness since it doesn't
> give you much over a True/OpenType font but can be useful
> for embedded devices where system fonts may not be available
> or reliable display of content is needed.
>
> A few SVG viewers support Full fonts, notably the Batik
> toolkit which is an excellent example of how to 'do' SVG.

Batik is a well done project, as is Inkscape. They're both quite mature, 
and large. And complex :-)

What's the status of ligatures on those SVG Tiny viewers?

Is there a maximum length that a ligature can be?
For instance, could 80 characters be used?
Received on Tuesday, 1 November 2011 01:21:41 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:49 GMT