RE: Glyph bbox concerns

Adam, your example works because color was added onto Mac OS in a backwards compatible way - it didn't actually change the rendering model.   The two things being considered here - animation and "color by numbers" - require a COMPLETELY NEW MODEL for rendering (outline-based) fonts than what has been used by graphical system since their inception.   The fact that it's SVG isn't actually important from that standpoint - the same problems/concerns would exist if it were any of the various other technologies you mentioned (PDF, WMF, etc.)

In order to understand why these are problems, you really need to understand how a font renderer works.  Unlike the days of "bitmapped fonts", an outline-based font rendered doesn't return a completed bitmap (that is then blitted onto the surface) nor does it draw directly on the surface.  Instead, it returns either 1 -bit mask OR a series of paths/outlines.  The reason for this is so that the glyph shape can then be composited into the surface based on the graphic state of the calling environment.   The reasons for OTF/SVG are that you don't just get these simplistic descriptions, but that you get a fully composed glyph - but that won't work when the glyph is being used in a graphical state that is richer than SVG.  For example, what if the author of the document wants to draw that glyph using a Spot color (for example,  in PDF).  How would you take that SVG information and have it render in a spot?   And animation...

 Hope that helps clarify the problems.

Leonard

-----Original Message-----
From: Adam Twardoch (List) [mailto:list.adam@twardoch.com] 
Sent: Sunday, August 26, 2012 10:35 PM
To: public-svgopentype@w3.org
Cc: Leonard Rosenthol
Subject: Re: Glyph bbox concerns

Hello everyone on the list. I'm somewhat late to join in, but for some reason I was not aware that this working group existed. Well, now it's actually about time as I'm doing some related work, so I'm finally here.
I'll start with revisiting some older threads, which seem to develop into a bit of a philosophical debate.

On 12-02-27 00:28, Leonard Rosenthol wrote:
> It's not just about color, Cam - it's about the entire model, rendering system, etc.
>
> Forget about color - how would you expect your SVG renderer (that is part of an OpenType engine) to know how to put "ink on paper"?  I wouldn't - I would expect it only to know how to put "bits in a bit buffer".  However, that's USELESS to a printer.

On 12-06-12 22:17, Leonard Rosenthol wrote:
> 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?

Leonard,

I'm note sure if I can follow.

Attached are two images. They show the new Microsoft logo opened in Aldus Freehand 3.1 running on Mac OS 6.0.8. I can open the EPS file in that version of Freehand, correctly read and change the color information, and retain it, and the printer will do whatever it needs to do with it later. If it's a color printer, it will print it in full CMYK, or if the color was specified as RGB, convert it to CMYK accordingly. And if it's a black-and-white printer, it will apply halftoning of some sorts.

Oh, hang on. I cannot actually see these colors while I'm authoring because I'm running it on an (emulated) Macintosh Plus with Mac OS 6.0.8. And this doesn't support color at all! So what?

If PowerPoint is to support SVG OpenType fonts at some point, it can choose which aspects of the SVG imaging model to implement and how.
After all, Microsoft Office 2013 seems to now have some support for PDF, and Apple Pages has support for PDF that comes with Apple's Quartz, but
-- while Quartz's imaging model may may be closely resembling PDF's, Microsoft's certainly isn't. But it's up to the implementors of the standard to decide how to deal with this. Mac OS X doesn't largely support TrueType hinting in their current font renderer, so the font developer can do all kinds of things with regard to instructing TrueType fonts, yet those will be ignored by Mac OS X. Various aspects of OpenType Layout are ignored by some application vendors, or they need to sort out how to deal with them in their own typographic models (for example, Apple seems to be internally converting OpenType Layout tables into state-based AAT representations). Do we need to care? Not necessarily.

When it comes to SVG OpenType fonts, I don't see how imaging is fundamentally different from other complex outline-based graphics, be it WMF, EMF, CGM, EPS, PDF or, indeed, SVG. Even today, SVG doesn't just exist in the web context, but is also used for print. How do the printing workflows deal with it? It's their cup of tea, really. Adobe PDF can include animations, movies, interactive Flash SWF elements. What will happen if such a PDF is sent to a printer? Well, something *has* to happen, but the printed images won't magically start moving only because they were moving on the original screen.

IMO, things need to be taken into account here at this working group which have to do with some aspects that were previously NOT widely examined when it came to either fonts or SVG, but limiting ourselves mostly to aspects which affect the INTERACTION of the font and the SVG, such as: 
* the notion of "flexible" bounding boxes if we consider animation, and how those influence layout
* the notion of how the same styling (fill, stroke) can be easily applied to all glyphs in a font, and in particular, whether certain parameters of a the SVG glyphs could be in some way controlled from the outside, i.e. from the application that is using such a font

In other words -- I don't think we should dive too much here into the discussion of how SVG by itself or OpenType fonts by themselves need to interact or are not adequately interacting with "the outside world" by themselves.

If a piece of SVG viewport (an SVG document) can be rendered onto some canvas, so can an SVG glyph. If an app vendor cannot render SVG documents on their canvas at all, that app vendor won't likely implement SVG OpenType fonts, just like if an app vendor cannot render monochrome Bezier or quadratic curves onto their canvas, that app vendor won't likely implement regular OpenType fonts. If an app isn't able to deal with opacity at all, then it's not the problem of opacity in SVG, or of opacity in SVG OpenType fonts -- it's a general problem of that app's imaging model, and we won't solve that here.

Certain prerequisites need to be fulfilled for an app vendor to implement support for SVG OpenType fonts, and, as the name of this group and project already reveals, I believe the most important of these prerequisites are, without a doubt:
1. The ability to work with OpenType fonts.
2. The ability to work with SVG documents.

So, I'd say -- let's take "for granted" that the implementors of SVG OpenType fonts already implemented both SVG and OpenType as they stand.
And let's focus on just the interaction of these two components.

Best,
Adam

-- 

May success attend your efforts,
-- Adam Twardoch
(Remove "list." from e-mail address to contact me directly.)

Received on Monday, 27 August 2012 12:06:45 UTC