Re: SVG in OpenType proposal

On 2/4/13 4:38 AM, "Cameron McCormack" <cam@mcc.id.au> wrote:
>>That all assumes that you control the SVG renderer, but in most cases,
>> that's not the case.
>
>You need some amount of control over the SVG renderer.  You definitely
>need to prevent script from running, which otherwise could be a security
>problem.

And that's going to be a problem for getting this implemented in pretty
much every other browser and in the OS contexts.



>>Is it reasonable to have the design of SVG glyphs in OpenType be
>>constrained by what WebKit on iOS can do?

Just WebKit on iOS - maybe.  But that was a single example of a larger
problem.

Unlike Mozilla, most/all of the other browsers use the OS-provided text
drawing services. Same for many authoring tools and other types of UAs
(ebooks, etc.) They don't have their own font engines.  That means that
they are going to have to wait for the respective OS vendors to support
this feature before they can support it.  For an OS vendor to support it,
means that they are going to now have to bridge their HTML/SVG engine with
their font engine. And start figuring out all the new APIs that are
required (as I tried to demonstrate in my original email).  I would really
like to see representatives from Apple, Google and MSFT review and comment
on their willingness (or lack thereof) to implement this.   Because w/o
their support - the whole concept of "SVG in OT" is dead in the water.



>All SVG glyphs should be renderable either as static or animated glyphs.
>  You shouldn't need to have to annotate this.  If your implementation
>or situation does not support animation, then you still use the SVG glyph.

Now you are putting a burden on the font author, that they have to create
SVG that works in both cases.  What if they donšt want that?  What if they
only want the SVG for animation and are OK with the classic glyph for
static rendering?  Since they have to provide classic glyphs anyway, why
also force them to provide SVG versions of those glyphs?



>>>I don't understand why this is possible if there is a predefined bbox
>for the glyph and not if there is not.  Being a "pre-defined" area for
>the glyph doesn't mean that it has exclusive rendering rights to that
>rectangle; there is probably some other pixel data in that spot that it
>would be rendering on top of.  Why does this change if the glyph just
>paints to the extents determined by its actual graphics content?  I feel
>like I am missing something.

Because the SVG engine may not have any idea how to paint to the actual
graphics context.  You are assuming that the SVG engine and the
application drawing text are using the same graphics libraries, etc.
That's not always the case.


>>1 - Require the caller to provide SVG-compatible "paints" for the current
>> graphic state to the font renderer.

But if a caller can't tell in advance that a given glyph requires this
feature, then it is going to have potentially a HUGE amount of overhead to
create these values and then pass them - even if they don't get used.
That's going to kill performance for something that may never be used.

The caller needs to be able to specify that it wants to allow this or not.
 It also needs to be able to easily determine if it's going to be used
(w/o having to parse the SVG).


Leonard

Received on Monday, 4 February 2013 13:46:38 UTC