RE: SVG in OpenType proposal

> 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.

Does this mean that you're supposed to clip to this box?

> 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.

In PDF, the width of the bounding box influences where the next glyph will start.
So, if you have different sized glyphs between the OpenType and SVG representations, text will come out misaligned.

________________________________________
From: rocallahan@gmail.com [rocallahan@gmail.com] On Behalf Of Robert O'Callahan [robert@ocallahan.org]
Sent: Tuesday, February 05, 2013 12:41 AM
To: public-svgopentype@w3.org; Leonard Rosenthol; Cameron McCormack
Subject: Re: SVG in OpenType proposal

On Tue, Feb 5, 2013 at 5:59 PM, Leonard Rosenthol <lrosenth@adobe.com<mailto: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 Thursday, 7 February 2013 00:44:37 UTC