RE: Glyph bbox concerns

I was notified that my email with attached PPT slide didn’t make it to the CG email list.
The attachment can be downloaded from http://lists.w3.org/Archives/Public/www-archive/2012Jun/att-0011/BBOX-sample.ppt


Thank you,
Vlad



From: Levantovsky, Vladimir
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]
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