Re: Rendering arbitrary SVG content in SVG font glyphs


Hi Jeff,

--Original Message--:
>Hi Alex,
>
>On Fri, Sep 11, 2009 at 9:23 AM, Alex Danilo <alex@abbra.com> wrote:
>>
>>>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?
>
>I don't understand this question, can you clarify?  Do you think it's

What I was trying to say is that when implementing SVG Full
fonts (properly), adding code to detect certain SVG elements
that "shouldn't" be present in a glyph is probably more
code and more memory footprint/testing etc. for the viewer
developer.

So allowing anything in the glyphs as being OK (rather than
mandating rejection of certain elements) would be easier
to implement and could open up creative use of things
that implementors can't anticipate.

I'd be surprised if authors started putting foreignObject
with links to web-sites in their glyph definitions, and
they'd learn pretty quickly how (non)interoperable things
like that are.

>correct for Opera/Webkit to claim they support the SVG Font string
>without supporting arbitrary content in <glyph> elements?  It's not

You are completely correct - and the fact that WebKit/Opera
claim that they support the SVG Full font module by testing
with requiredFeatures is a bug. Plain and simple, not likely
sinister, but it is definitely false advertising:-)

>clear to me from the spec (though it's possible I have missed it) but
>I guess it doesn't matter any more since Opera/Webkit have been out
>there for awhile so we now have a defacto meaning for the #Font
>feature string.

It's not a defacto meaning, it's a bug. The spec is pretty
clear about what the requiredFeatures string defines, two
web browsers implementations doing the same thing doesn't
make it a defacto standard - it more likely means they
intend to support the feature but haven't completed it yet.

>>>> 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.
>
>I can't speak for roc, but my statements have nothing to do with
>writing any code.

Sure, sorry for replying to you directly about the implementation
comments.

I do appreciate your keen observations on the erroneous handling
of #Font. Maybe they should be advertising #BasicFont instead;-)

Alex

>Jeff
>
>
>

Received on Saturday, 12 September 2009 03:52:50 UTC