Re: SVG in OpenType proposal

On Tue, Feb 5, 2013 at 5:59 PM, Leonard Rosenthol <lrosenth@adobe.com>wrote:

> >Maybe so, but that doesn't obviate what Cameron said. Any proposal for
> SVG content in glyphs has to assume the presence of an SVG renderer
> offering certain
> > controls to the embedder.
>
> Not necessarily.  An implementation of SVG-in-OT could choose to use a
>  pre-limited SVG implementation (such as not allowing scripts and/or
> animation).
>

If you have an SVG implementation that doesn't support animation at all,
then you don't need to do anything special to disable animation of an
animated glyph.

If I understand this part of the thread correctly, you are arguing that
non-animated glyph content must be provided separately to the animated
content for a glyph, because otherwise applications that don't want to
animate glyphs, only have access to an SVG renderer that supports animation
(and which doesn't support disabling of animation), and aren't able to
parse SVG, won't be able to disable animation. This seems contrived.

>I can't see the problem here. For each frame of the glyph animation the
> SVG renderer can compute a bounding-box. If necessary each frame of the SVG
> glyph
> >can be rasterized by the SVG renderer; these rasterizations may not all
> be the same size, but that's OK. Somehow these rasterizations have to be
> drawn by the
> >application but that's true for any proposal.
> >
> Why does it have to be rasterized?  If I am an physical printer  (for
> example), then the last thing I want is pre-rasterized glyph.  I want to
> get vector elements/shapes.
>

Sure. You said earlier

> 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.
>
If it's not the case, the SVG renderer and the application still have to
communicate somehow. The simplest way to do that is by exchanging pixel
buffers. I guess you should describe in more detail exactly what the
problem you're describing is.

But even if it is rasterized, how do you know where they go on my canvas?
>  How you specify their relationship to the shape bounding box?  If the SVG
> renderer can't directly draw on the output surface (which is quite common),
> then how do you propose animation works??
>

There are probably lots of ways to implement this. One obvious way is to
have the SVG renderer signal the font system and thence the application
whenever the SVG renderer detects that animation has changed the state of
one or more glyphs for a font. The application would respond by scheduling
a repaint of the affected text and eventually repainting it with freshly
re-rendered SVG glyphs. This would work regardless of how painting of SVG
glyphs works.

>Well, OK, there is one problem here: normal OpenType glyphs can't change
> their bounding-box over time, so font and text drawing infrastructure tends
> to
> >assume those bounding-boxes are constant and would have to be reworked to
> handle dynamic changes.
> >
> You have that backwards.  The animation can't change the box.  It MUST
> remain constant – for the same reason that the metrics for the classic
> glyph have to be constant with the SVG-based glyph.
>

I don't think so. AFAIK glyph bounding-boxes, unlike other text metrics,
don't affect shaping. (I hope we're talking about the same thing here: by
bounding-box I mean a rectangle that encloses everything drawn for a
glyph.) In Gecko we only use them to optimize painting by ignoring text
that doesn't intersect the area to be painted. (Except for a very special
case involving MathML layout that is not relevant here.) There is no
particular reason why glyph bounding-boxes need to be constant over time;
bounding boxes for other kinds of content are not constant over time.

>But such infrastructure assumes glyphs don't change rendering at all, so
> needs to be reworked anyway to support any kind of animation. We did
> consider an >alternate design where the glyph content would be clipped to
> the OpenType bounding box, which is constant, but that's much harder for
> authors to work with >so we went with the current approach.
> >
> Why is that harder?  It would seem to be MUCH simpler and MORE correct.
> AFAIC, that is the only viable option.
>

It's much harder for authors because they have to compute, over the
lifetime of the animation, the maximum extents of every frame of the
animation, take the union of all those, and stuff the result into the right
place in the OpenType tables. And if they get it wrong, they might not
notice until at some point in time the glyph is unexpectedly clipped. For
arbitrarily complex content and animation, I don't think this is even
feasible.

There's no need to make them do that. Having the UA compute the
bounding-box automatically from the SVG simplifies the problem dramatically
because the UA will never have to compute the maximum extents over all
time; it only has to compute the bounding box for the current frame. Also,
SVG renderers already have the machinery to calculate SVG bounding-boxes.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
— whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]

Received on Tuesday, 5 February 2013 08:41:31 UTC