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.)