Re: Rendering arbitrary SVG content in SVG font glyphs

On Fri, Sep 11, 2009 at 8:07 PM, Erik Dahlstrom <ed@opera.com> wrote:

> This is from SVG 1.1 DTD [1]:
>
> <!ENTITY % SVG.glyph.content
>    "( %SVG.Description.class; | %SVG.Animation.class; %SVG.Structure.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.Cursor.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, it does allow <use> as a child of <glyph>, which can then refer to
anything including a <foreignObject>. So you can get a cloned IFRAME in
there.

On Thu, 10 Sep 2009 23:55:37 +0200, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>
>> 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.


That creates a subtle dependency between the page using the font and what
should be an implementation detail of the font.

There is an additional problem that if some of the characters in the text
are rendered using an SVG font and other characters fall back to a system
font or downloaded Truetype font (or vice versa), then you basically can't
use stroke-width or any other text style that depends on user units! And the
author may have no idea that this is happening or could happen, especially
if the contents of the are not known in advance (e.g. the text is editable).
E.g. suppose an author has an SVG font with units-per-em set to 1024, and so
they set their stroke-width to, say, 50. But their font only covers Latin
text, and later someone adds non-Latin characters to the text --- they get a
bizarre failure.


>  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.


There's not much to say, it seems trivial. Render the glyph contents like
you render the contents of a <pattern>. The pattern coordinate system is the
font coordinate system just the way <glyph> content is specified today.
There is no conceptual cloning and no inheritance of style from the text.

To address the most important use of style inheritance, I would define a new
paint server "textColor". When applied to fill or stroke an element which is
a descendant of <glyph>, you find the nearest <glyph> ancestor and use the
color of the text that the <glyph> is being drawn for. When applied outside
a <glyph> context, you could have it either do nothing or use the CSS
'color' value for the node.


>  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?
>

Yes. The spec requires "conceptual cloning", so in certain weird cases (like
my example of a <glyph> containing a <use> referring to a <foreignObject>
containing an <iframe>) where cloning is distinguishable from sharing, the
implementor is forced to clone. There are probably other less-weird cases
where cloning is distinguishable from sharing (perhaps if a cloned fragment
has an independent SMIL timeline that starts when the cloning happens?) but
it would take a very careful study of the SVG spec (and related specs) to
identify them all.

In general, as an implementor, I have found that if the spec says you should
conceptually do X, then the implementation should actually do X if it
possibly can, because if you do Y which is quite different to X but is
observably equivalent to X as the spec stands, then the spec is likely to
change deliberately or accidentally so that X and Y become observably
different and you have to rewrite a lot of code. Therefore if you want to
make sure a non-cloning implementation is and remains viable, you'd better
remove from the spec all language about cloning.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]