Re: SVG in OpenType proposal

Leonard Rosenthol wrote:

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

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.

Unlike Mozilla, most/all of the other browsers use the OS-provided text
> drawing services.


We also use OS-provided text drawing services, but not exclusively, and
neither do other browsers. Note that Webkit and Opera already support (a
small subset of) SVG 1.1 fonts: that support definitely doesn't come from
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).


This is all true, but it's going to be true for any proposal that embeds
SVG content into fonts.

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

This sounds quite theoretical. You're talking about a font author who wants
to use animated SVG for a glyph and is willing to do the work for that, but
for whom the first frame of the animation is not suitable as a static
version of the glyph, whereas the monochrome OpenType outline *would* be an
adequate static version of the glyph. And this author is not willing to
tweak the SVG content by the small amount necessary to display a customized
first frame. This particular case doesn't seem worth adding complexity for.

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

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.

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

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

I don't believe that it's going to be a "HUGE amount of overhead" and "kill
performance" unless the API to the SVG renderer is incredibly bad.
Especially for the overwhelmingly common case where fill is a solid color
and there's no stroking.

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]