Re: Rendering arbitrary SVG content in SVG font glyphs

Hi Jeff,

--Original Message--:
>On Fri, Sep 11, 2009 at 8:06 AM, Chris Lilley <chris@w3.org> wrote:
>> On Friday, September 11, 2009, 1:28:39 AM, Jeff wrote:
>>
>> JS> I'm afraid I still didn't understand the use case for allowing TRULY
>> JS> arbitrary SVG content as children of the <glyph> element.
>>
>> Same use case as allowing a <use> to point to arbitrary SVG content.
>
>If <use> satisfies the use case that you're talking about, then why do
>you need to support the solution in <glyph> as well?  Why are we
>providing more than one solution to the use case?
>
><use> is about a general cloning method.  <glyph> is about
>constructing font glyphs.

<use> doesn't clone.

<use> is a reference within the document object model
that gives it DAG semantics.

Referencing content within the source XML document via
an indirect for a glyph or via <use> is really the
same thing.

Roc's original concern about indirecting into
another namespace via foreignObject is indeed a
valid concern and I think Erik pointed out this
is already well constrained by the earlier DTD.

>So I still fail to see the need to allow truly arbitrary SVG,
>particularly when no browser yet supports it - though some claim to
>support the SVG Font feature strings:
>http://www.codedread.com/svgtest.svg cough Opera ahem :)

A nice orthogonal implementation shouldn't need to provide
excessive and/or abitrary constraints, don't you think?

>> Indeed, text in SVG can be seen as a way of generating a bunch of use elements laid out one next to another according to some rules (advance width, font size, kerning).
>
>Since SVG has no advanced layout (yet), this will result in users
>trying to 'corrupt' the intention behind SVG fonts to take advantage
>of these rules.  I've actually seen this done before by using font
>glyphs and text elements in ways that have nothing to do with text

Hmm.

SVG fonts provide capabilities that go far beyond boring OpenType
fonts - like animation as a minor example.

This thread seems to have been born from a reluctance to write
code to do what the specification described and ASV has implemented
from a number of years ago, not to mention other implementations.

Succinctly: SVG fonts are not a substitute for OpenType. OpenType
is not a substitute for SVG fonts. The capabilities of both
are different, and SVG fonts provide an author with greater
creative options than a boring outline can ever do. Period.

Alex

>Jeff
>
>

Received on Friday, 11 September 2009 14:32:36 UTC