W3C home > Mailing lists > Public > www-svg@w3.org > September 2009

Re: Rendering arbitrary SVG content in SVG font glyphs

From: Erik Dahlstrom <ed@opera.com>
Date: Fri, 11 Sep 2009 10:07:10 +0200
To: robert@ocallahan.org, www-svg <www-svg@w3.org>
Message-ID: <op.uz2158jjgeuyw5@hit-nxdomain.opendns.com>
On Thu, 10 Sep 2009 23:55:37 +0200, Robert O'Callahan  
<robert@ocallahan.org> wrote:

> It seems to me that no major Web browser supports rendering arbitrary SVG
> content for an SVG Font glyph. For example, this testcase displays  
> nothing in Webkit and Opera:
> <svg xmlns="http://www.w3.org/2000/svg" >
>   <font id="Font">
>     <font-face font-family="Test" units-per-em="2048"/>
>     <glyph unicode="@" horiz-adv-x="1000">
>       <rect x="0" y="0" width="1000" height="1000" fill="cyan"/>
>     </glyph>
>   </font>
>   <text x="0" y="100" style="font-family:Test;  
> font-size:80px;">@@@</text>
> </svg>

Right, Opera implements something closer to what's defined in SVG Tiny  
1.2, which doesn't allow arbitrary child content for defining a glyph.

> A completely general implementation of this feature in a Web browser  
> would
> be very difficult. For example, the SVG content for a glyph could be
>   <foreignObject x="0" y="0" width="1000" height="1000"><html:iframe  
> src="
> http://mozilla.com"/></foreignObject>
> The SVG 1.1 spec requires you to create anonymous cloned iframe objects  
> for
> each glyph, which have to be associated with the text in some way.  
> Because
> these objects are stateful, the spec would need to define exactly when  
> this
> binding happens. For example, if I append a character to the text node,  
> are
> all the anonymous nodes recreated or is one just appended? The problem is
> especially acute if you want to support this for non-SVG text.

This is from SVG 1.1 DTD [1]:

<!ENTITY % SVG.glyph.content
     "( %SVG.Description.class; | %SVG.Animation.class;  
        %SVG.Conditional.class; %SVG.Image.class; %SVG.Style.class;
        %SVG.Shape.class; %SVG.Text.class; %SVG.Marker.class;
        %SVG.ColorProfile.class; %SVG.Gradient.class; %SVG.Pattern.class;
        %SVG.Clip.class; %SVG.Mask.class; %SVG.Filter.class;  
        %SVG.Hyperlink.class; %SVG.View.class; %SVG.Script.class;
        %SVG.Font.class; %SVG.glyph.extra.content; )*"

Or in other words, SVG 1.1 doesn't allow foreignObject child content in  
glyph elements, except possibly through one of the classes here (which is  
something the DTD doesn't

However, there's an SVG 1.1 errata item [2] (ISSUE-2253) that changes  
this. In light of this it seems we may need to reconsider the inclusion of  
foreignObject in the glyph and missingGlyph elements.

> The requirement that CSS inherit from the text, to the <font> element, to
> the <glyph>, may also be hard to implement. As noted in the spec it can  
> also
> produce very unintuitive results because SVG styles like stroke-width  
> will
> be interpreted in the glyph's coordinate space, which the text author may
> know nothing about.

Possibly, although it's not that hard for an author to look up the  
units-per-em in the font to get the desired result.

> Chris Lilley pointed out in a Mozilla newsgroup that one-off decorative
> glyphs for a particular page are a good use case for this: it's just like
> producing artwork except your text is searchable, accessible, etc. Is  
> that
> the only use-case?

It also makes the font available in the DOM so that it can be easily  

> Could we satisfy that use-case in some other way?

I'm sure it would be possible to offer API:s for extracting glyph shapes  
 from systemfonts. That would take you half-way compared to SVG Fonts,  
since I don't think you'd want to allow your systemfonts to be modified,  
while an SVG Font is just a document and thus it's expected that it's  

> One
> possibility that seems attractive to me is to redefine the way glyph  
> content
> is rendered so that it's treated like a pattern instead of a <use>.

That sounds interesting, please elaborate.

> Not
> having to manage anonymous content for text would make this far easier to
> implement, for Gecko anyway, and it would also perform much better. It  
> would
> mean losing the ability to inherit style from the text itself. However,  
> as
> far as I can tell, the main need is to be able to use the text color in  
> the
> glyph content. We could support that in fill and stroke by defining a new
> paint server "textColor" which magically extracts the color from the text
> the glyph belongs to.
> Rob

I agree that not having to manage separate (conceptually cloned) copies  
would be good. Does the current wording forbid that though?


[1] http://www.w3.org/TR/SVG11/svgdtd.html

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Friday, 11 September 2009 08:07:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:18 UTC