Re: SVG in OpenType proposal

On 4/02/13 2:26 AM, Leonard Rosenthol wrote:
>> Our proposal states that when glyphs are
>> rendered in situations where animation is not possible, then the SVG
>> animation elements just do not apply.  This is the same behaviour as if
>> you took an animated SVG document and opened it in an SVG user agent
>> that does not support animation (such as Internet Explorer).  It is
>> simple enough to construct your content such that the static view is
>> what you would see if the animation elements were not present.
>
> 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.

> Consider an environment (say iOS) where an application has access to a
> WebKit-based SVG renderer, but no control over whether it should run SVG
> animations or not.  An application such as Apple's Pages that wants to
> display color glyphs but not animated glyphs, will not be able to do under
> your proposal as it won't know which glyphs to load/use.

If WebKit on iOS does not provide an embedding API that allows you to 
control all of the things required for using it as your SVG glyph 
renderer, then I think either this API should be added to WebKit or you 
should consider using something other than WebKit for your glyph 
rendering.  Is it reasonable to have the design of SVG glyphs in 
OpenType be constrained by what WebKit on iOS can do?

It makes sense for me that if a platform text rendering library supports 
static glyphs and animated glyphs -- be they SVG glyphs or whatever -- 
that this might require a different API.  Your application might need to 
be called back for each frame of the animated glyph being rendered so 
that you can recomposite it with the rest of the graphics in your 
window, for example.  Or it might just be that if you paint some text on 
your window that includes animated glyphs that the system will ask your 
window to repaint itself a frame later.  To me it doesn't seem like the 
design of the platform text drawing APIs here should affect how 
possibly-animated glyphs should be specified in the font.

> Now to continue this example out to the OS levelŠ Pages doesn't know
> anything about glyphs, nor should it.  Instead, it simply asks iOS to
> render a run of text.  iOS will now need to provide APIs that allow Pages
> (etc.) whether it should choose SVG-based glyphs at all, static only or
> allow for animation.  And the only way for iOS to be able to do that is if
> it can quickly (aka w/o parsing the SVG) pick the right glyph from the
> font.

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.

>> I will need to read that thread about bounding boxes.
>
> The issue here is related to the fact that if the SVG is being rendered by
> a process separate from the rest of the page content - then (a) it doesn't
> own the drawing area so it can't draw where it wants and (b) it has no
> information about what it is drawing on top of to be able to properly
> composite as it animates.
>
> Return to the example above.  How would the WebKit renderer in iOS be able
> to animate a glyph on top of the Pages' page??  It can't (realistically).
> However, there would be no problem with it animating inside of the glyph's
> BBOX - since that area is "pre-defined" for that glyph.  (granted, there
> are still issues, but at least they are much more constrained and
> solvable).

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.

>> We could add some wording explaining how non-SVG colours and patterns
>>from the context would be handled when rendering the glyph.  We would
>> need to have a more abstract definition of the paints that can come in
>>from the context -- let's say, a solid colour of a type that corresponds
>> to one of the kinds of colours you can specify in SVG 2 -- or a fixed
>> size pattern/bitmap, which would be handled just like an SVG pattern.
>>
>> Let me know if there are specific problems that a high level description
>> like that would not solve.
>
> I think there are three ways to handle this.
>
> 1 - Require the caller to provide SVG-compatible "paints" for the current
> graphic state to the font renderer.
> 2 - Have the font provide a non-context-aware version of the glyph (ala
> the animation/non-animation) that can be selected.
> 3 - Have the font identify context-aware glyphs so that they can be
> avoided if not supported. (again, ala animation).
>
>
> 2 and 3 are pretty easy to implement (in a variety of ways) and could be
> done in a way that is compatible with the model we choose for animated vs.
> non-animated (be it the Adobe model or some other choice).  Personally,
> this would seem like the best approach to me.

I think #2 and #3 would be fine if we are just supporting emoji-like 
glyphs where they are just pictures that don't look like regular glyphs, 
and which you don't want to take on the colour/paint appearance of the 
surrounding text.  But I do think we want to support this, so I would 
prefer #1.

> 1, while it might sound like the right approach, simply won't work
> reasonably in most non-web contexts - even if the color model matches SVG.
>   Go back to our Pages & iOS example.  You have two issues here.  First,
> iOS would need to add an API that would let the caller provide the current
> fill, stroke, etc. colors - and Pages would have to call this before every
> single "draw text" (in the most simplistic implementation).  Second, iOS
> would either need to provide a "map color to SVG" method for the client to
> call before the "set glyph colors" call or it would have to do it itself.
> Either way, it's a lot of work.

If iOS wants to have the ability to pass in different paints to be used 
by the font in its text drawing APIs, then sure, it needs to gain an API 
to expose this ability.

Received on Monday, 4 February 2013 12:39:11 UTC