Re: Glyph bbox concerns

I have no problem with the concept of "declaring requirements" - I think that's a valid approach.  The work then is to define ALL POSSIBLE REQUIREMENTS (at least that we know of today) and to also define the fallback model for when various requirements cannot be met.   Potentially a lot of work, but well worth it…

I am all for developing for the future.  However, if something doesn't/can't work today – then it will have no future.

Let me give you a real world scenario that you need to consider for the usage of such fonts.

Overview: Use of PowerPoint (or OpenOffice, take your pick) to author an HTML page.

Details: A user authors a document in PowerPoint and chooses to include an animated emoji character as part of the document.  The user would expect that the emoji animate in PowerPoint while they are authoring the document, so they can see what it's going to look like when distributed.   That means that the emoji has to be able to animate in the rendering system of PowerPoint – including full Z-order interaction with the other content placed on that same page.   Since the rest of the page content isn't SVG-based,  how does this happen!??!   Also, can the user change the color of the emoji to match their color scheme?


So taking this back to the requirements…
Does the font (or each glyph of the font??) need to stipulate that it can animate?
Does the font (or each glyph) need to stipulate whether attributes/properties can be changed?
Etc….


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 don’t see the basis for “assuming anything about the environment” claim. I for one am not suggesting to assume anything – all I am saying is that the new font format should contain enough info to properly *declare* the needed resources for a font to be safely rendered by an environment, whatever that environment may be. There is no implied guarantee that the resources will be made available, and a particular environment can always deny certain resources or ignore animations altogether.

However, the environments and applications will evolve, and eliminating the features from consideration based on what a typical environment can or cannot do _today_ would only harm the development of a new standard. Looking back, had we followed the same logic we would have never seen support for advanced features and stylistic sets – they were introduced in the spec at the time when most application environments were not capable of rendering them and even today, after more than a decade – there are still many environments that do not render stylistic sets. Not being able to render animations in some environments should not be an argument to deny animations a chance to be included as a design feature of a font.

Regards,
Vladimir


From: Leonard Rosenthol [mailto:lrosenth@adobe.com]
Sent: Tuesday, June 12, 2012 12:59 PM
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

>allowing animation bounding box be defined separate from a static glyph bounding box
>
I don't see how that is possible in a format/rendering environment neutral manner.    If the entire rendering environment for the font were a "web page" (or some other HTML-based environment), then it might certainly be possible.  However, fonts are used in numerous other systems, not just for final render but also for original authoring.   As such, our design CAN NOT assume ANYTHING about the environment.   And that's why the "large bbox" and extended animation scenarios are problematic.

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

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

I absolutely agree, and I believe that this is exactly what we are going to accomplish by allowing animation bounding box be defined separate from a static glyph bounding box. It gives us a safe way to ensure that bad fonts can’t cause the implementations to crash, that all necessary resources (memory, etc.) can be allocated ahead of time, that larger bounding box will not violate the page / viewport boundaries and can be clipped accordingly if needed, etc. Allowing animations to use larger bbox _without_ declaring it would be reckless.

However, I have no doubt that we *will* see garbage fonts designed with animations that  may mess everything up – and this is okay IMO if the implementations can safely deal with it (thus preventing a misuse!). The end user will simply try a font once, see how bad it is and send it to a “Recycle Bin” where it belongs.

Thank you,
Vlad


From: Leonard Rosenthol [mailto:lrosenth@adobe.com]
Sent: Tuesday, June 12, 2012 11:05 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

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