RE: Glyph bbox concerns

Your example is one of animation of glyphs, NOT glyph animation.

I am differentiating the concepts for good reason.

In your example, each glyph is animated in a way that is general purpose – meaning that it could be applied to ANY graphic object.  Additionally, that animation isn’t to appear on that particular glyph for ALL USAGES of that glyph.

Glyph animation, as we are discussing it, is a case where ANY TIME that glyph appears, it will animate itself in a special and distinct way.   The standard example here is a emoticon or emoji with the face doing something like smiling, winking, etc.   And that makes perfect sense AND doesn’t require “large BBOX” in any way since the glyph fits into the BBOX.   The only possible case that I can think of would be where a glyph would bounce around – but in that case, IMO, it should only be allowed to bounce inside of its BBOX.

Leonard

From: Levantovsky, Vladimir [mailto:Vladimir.Levantovsky@MonotypeImaging.com]
Sent: Friday, June 08, 2012 4:09 PM
To: Leonard Rosenthol; Sairus Patel; Edwin Flores (eflores@mozilla.com); public-svgopentype@w3.org
Subject: RE: Glyph bbox concerns

I believe the concept of the “large BBOX” makes sense when you consider an animation effect and how a glyph would be rendered on a timeline. See attached for an example of what I consider a plausible behavior. It wouldn’t be too much of a stretch to imagine that someone may want to design fonts that have this kind of a behavior or something conceptually similar – e.g. when animation is an intrinsic feature of a font design that complements its graphic representation.

Thank you,
Vlad


From: Leonard Rosenthol [mailto:lrosenth@adobe.com]<mailto:[mailto:lrosenth@adobe.com]>
Sent: Wednesday, June 06, 2012 6:11 PM
To: Sairus Patel; Edwin Flores (eflores@mozilla.com<mailto:eflores@mozilla.com>); public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>
Subject: RE: Glyph bbox concerns

I think you are forgetting here that when rendering the glyph, the glyph’s BBOX is relative to the current pen position and NOT the “viewport/canvas” onto which it is being rendered AND since it can’t query outside of itself, it has no way to constrain itself.

As such, I am still at a loss to understand how any sort of “large BBOX” glyphs could be constructed that make logical sense.    Does anyone have a good example?

Thanks,
Leonard

From: Sairus Patel [mailto:sppatel@adobe.com]
Sent: Wednesday, June 06, 2012 5:45 PM
To: Edwin Flores (eflores@mozilla.com<mailto:eflores@mozilla.com>); public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>
Subject: Glyph bbox concerns


We've talked about having a new BBOX table that recorded the static and animated bounding boxes of the glyphs.



The idea was that an application that is concerned about a huge SVG glyph "taking over the window" and confusing a user can first examine the glyph's bbox and determine whether it is too large to be suitable.



Here are two concerns I have with this:



1.

This would work only for a well-formed font; i.e. one in which the BBOX table was accurately set.



Imagine a malicious (or simply a badly made) font that recorded a small bbox for an SVG glyph that was in fact huge. To prevent against this huge glyph confusing the user, the SVG renderer would have to enforce or clip the rendering to the glyph bbox, right?



This would mean that the OT engine passes in the glyph's bbox (from the BBOX table) to the SVG renderer at the time of making the request.



*Alternatively*, the SVG renderer could go ahead and render the huge glyph, and the application could examine the bounds of that bit buffer (or whatever the returned structure is) to determine whether it's too big or not to be suitable for display. In this way of doing things, no BBOX table is needed.



Edwin or others, could you comment on these two approaches? Are there other parallels in the SVG world? Is it possible to examine the “bit buffer” bounds for an animation?



2.

Since SVG glyphs can be parameterized in various ways e.g. stroke thickness, the glyph bboxes would have to take into account the maximum size the glyph (at em size) would be with the maximum stroke value. Is there such a thing as maximum stroke value?



Thanks,

Sairus