W3C home > Mailing lists > Public > public-svgopentype@w3.org > November 2011

RE: [OpenType] Update on color/animation in OT via SVG; new W3C Community Group

From: Sairus Patel <sppatel@adobe.com>
Date: Mon, 28 Nov 2011 16:47:49 -0800
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>, "public-svgopentype@w3.org" <public-svgopentype@w3.org>
Message-ID: <4EA40BFB156EC241906E2CCC0710A8777D760C9462@NAMBX01.corp.adobe.com>
See notes inserted below:

On Monday, November 28, 2011 1:57 PM Levantovsky, Vladimir wrote:
> On Wednesday, November 23, 2011 3:05 PM Sairus Patel wrote:
> > To: public-svgopentype@w3.org
> > Subject: RE: [OpenType] Update on color/animation in OT via SVG; new 
> > W3C Community Group
> > 
> > 
> > b. Alternatively, a simple "g<glyphID>" e.g. "g0", "g1" scheme can be
> >    specified to create the id value. This will be one less lookup that
> >    needs to be done (i.e. the 'post' table lookup) which helps execution
> >    speed. The font vendor is authoring the SVG OT font as an entirety
> >    and requiring a certain pattern for the id name shouldn't be
> >    burdensome, IMO.
> > 
> 
> 
> I like this approach a lot. Avoiding an additional lookup is definitely
> an advantage and with this glyph ID naming scheme, especially if it can
> be done with no additional changes to the SVG spec.

Great. This approach certainly simplifies things a whole lot.

> > (The main point of my little interface sketch-up was that the SVG 
> > engine will only be queried by element id and not by character code, 
> > BTW, but I'm glad we're starting to discuss all the rest of the 
> > aspects of the
> > interface!)
> > 
> > In my mind there are two aspects to this, glyph bounds and compositing 
> > with the rest of the page:
> > 
> > - Glyph bounds:
> > 
> >   The OT *font* bbox ('head' table xMin, etc) will indicate a rect which
> >   no glyph, including its animation, must extend beyond. An OT engine or
> >   application can examine this bbox and if it's too big can introduce
> >   clipping or reject the font (as is the case today with CFF or TT).
> >   While this may restrict font vendor creativity, it's what comes with
> >   the OT model.
> 
> How would we know if the bbox is too big - e.g. some glyphs in existing
> calligraphic/casual script fonts have swashes that extend way beyond the
> normal glyph bounds. This would cause the overall font bounding box to
> be quite large, even though there are only few characters that have
> swashes. (I believe some of the versions of the Zapfino have the font
> name "Zapfino" defined as a single glyph ligature.) And, alternatively,
> what would stop a font creator from adding one large glyph only for the
> purpose of increasing the size of font bbox?

I think we're talking about bboxes because some applications would like
to guard against "suprises": a static SVG glyph that is one huge rectangle
that makes it seem as though your application window went blue, or an
animated SVG glyph that covered your entire window with buzzing flies, or
some other creative but disruptive and therefore possibly malicious
usage. Of course, TT and CFF have a somewhat similar situation but it's
not often that such fonts have "extreme" sizes. Animated SVG could result
in this happening more frequently.

So Leonard's question of who should be enforcing font or glyph bboxes or
who should be doing the clipping is a good one.

Currently the OT spec is silent on this for TT and CFF.

What we can do is have explicit glyph bbox information, both static and
animated glyph bboxes. This is a metric similar to advance width, for
example, which is OT is a separate table from the outlines.

Thus we could have a new OT 'BBOX' table which:

- has a font bbox that includes bounds for animation. (We could say that
  the existing 'head' table's font bbox is the font bbox for static SVG, which
  would nicely parallel the existing usage for TT and CFF which is of course
  static.)
  Thus there are separate static and animated *font* bboxes available in the
  font.

- has a set of glyph bboxes for *static* rendering of SVG glyphs (this can
  also be used for CFF glyph bboxes, since these are not recorded
  explicitly in CFF anywhere)

- has a set of glyph bboxes for *animated* rendering of SVG glyphs

With this, an app and OT engine have all the information needed to
enforce any clipping of fonts or glyphs they consider too "extreme".
Different applications will have different limits, and it's up to them.
Where exactly in the process the clipping or font/glyph rejection
happens is probably implementation-specific. So it may be OK if our
proposal mentions all this but doesn't make a specific requirement.

The OT engine is welcome to include the glyph's bbox as a parameter
when asking the SVG rasterizer to render a glyph. It would be up to
the impl to define where the clipping should occur.

And re. compositing, I like the approach I'm hearing people suggest:
leave it up to the application/impl. If an application doesn't want to
support compositing (it may be quite difficult with animation,
especially) that's its choice.

Vlad, I'm not sure if this helps address your comments above; let
me know if it doesn't.

> Thank you,
> Vlad

Thanks,
Sairus
Received on Tuesday, 29 November 2011 00:48:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 29 November 2011 00:48:18 GMT