Re: Glyph bbox concerns

Then I think we are going to simply agree to disagree, as you are trying to put graphic concepts into a simple glyph description – and that simply isn't viable in most environments.

> Any limitations we impose as part of the spec will stifle creativity and in the end will hamper the adoption of the new technology – this is my biggest concern.
>
On the other hand, I think it's REQUIRED OF US (as spec/standards designers) to "do the right thing" - and that's to prevent misuse…

Leonard

From: <Levantovsky>, Vladimir Levantovsky <Vladimir.Levantovsky@MonotypeImaging.com<mailto:Vladimir.Levantovsky@MonotypeImaging.com>>
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, Sairus Patel <sppatel@adobe.com<mailto:sppatel@adobe.com>>, Edwin Flores <eflores@mozilla.com<mailto:eflores@mozilla.com>>, "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Subject: RE: Glyph bbox concerns

I can see the point your making but I don’t believe the distinction of animation types based on the timeline (finite or continuous) or its placement within a glyph (on entrance/exit, or for the entire duration of a glyph display) should play a role when we make a decision on how spec features are defined to enable this. Any limitations we impose as part of the spec will stifle creativity and in the end will hamper the adoption of the new technology – this is my biggest concern. Yes, badly designed fonts exist and (with almost 100% assurance) will appear in the future – putting unreasonable constraints in the spec will not prevent this from happening.

And, speaking of the distinction between animated glyphs vs. glyph animation – I don’t really see this as a an argument against allowing larger bounding box sizes. Consider a hypothetical font (e.g. a futuristic version of the “Slipstream”) where animation is designed so that:

-          when I type a character - a glyph will fly in to its place;

-          upon “static” display the glyph is animated to simulate the “blown in the wind” motion effect:

-          when I delete a character the glyph explodes (i.e. briefly shows an expansion, breaks in pieces that fly way beyond its normal BBOX size and disappears).
I consider these animation effects be glyph animations, I don’t want the spec to limit what can be done if/when it’s done right.

Thank you,
Vlad


From: Leonard Rosenthol [mailto:lrosenth@adobe.com]
Sent: Sunday, June 10, 2012 8:45 AM
To: Levantovsky, Vladimir; 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

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<mailto:eflores@mozilla.com>); public-svgopentype@w3.org<mailto: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