Re: Glyph bbox concerns

On 12-08-27 20:24, Leonard Rosenthol wrote:
> You are still thinking about a screen & web only world....Let's see what happens when we also look a print.
No, I am not. Regular SVG can be printed. It can be superimposed with
other content, re-colorized, manipulated etc.

Once it goes to print, the difference between SVG glyphs and SVG
graphics practically vanish. So the discussion about the print stream
may be relevant to SVG as a whole, and is not specific to SVG glyphs.

Some PostScript or PDF authoring applications "convert all text to
outlines", as it were, so the searchability etc. disappears. If PDF does
not support SVG OpenType fonts natively (which of course it does not
currently), this can be remedied in a number of ways:

* You just "convert all SVG OpenType-based text to outlines", as it
were, i.e. replace it with a static SVG graphic, and then perform
whatever you currently perform to get the SVG graphic into PDF. You do
the same to colors in SVG glyphs as you do to colors in SVG graphics. If
"SVG Colors" comes along where you can specify CMYK or spot colors in
the SVG, then you use it natively. But if SVG is RGB-based, you do
whatever you currently do with RGB-based PDF, RGB-based EPS, RGB-based
WMF (which only is RGB AFAIK). You use color management profiles to
convert RGB into your desired color space, and go ahead.

* You are a bit smarter, render the SVG glyphs as graphics with their
static positioning (using all the steps described above), but grab the
OpenType font that surrounds the SVG, replace the outlines of the glyf
or CFF table with "outline-less glyphs" that have metrics compatible
with your SVG glyphs, include it in the stream, and typeset "invisible
text" on top of the rendered SVG graphics. So there is still a
text-selectable layer. This is what Acrobat already does today if you do
OCR on a PDF that consists of bitmap images only.

I don't know enough about animation, so I won't comment on these
concerns. I do realize there are many, and they may be serious. But
again, especially when it comes to print, there are precedents for that
(movies, interactive SWF content etc. inside of PDFs).

I still don't see how SVG OpenType fonts bring any problems that are
entirely new and only specific to SVG OpenType. They may be specific to
SVG as a whole, they may be specific to how you deal with animated
content on non-animated contexts -- but those questions are *old*, and
vendors have developed solutions for them. Some of these solutions may
be better, some worse, but there are already some.

Same goes for gradients, opacity/transparency etc. -- all these
questions have already existed before, and there are existing solutions
of various sorts.

95% of SVG OpenType fonts is basically a repackaging of techniques which
already exist in the industry.

The only real SVG OpenType-specific question which comes to my mind is
one that -- to some extent -- also has been thought about before, though
to the lesser extent, and that has to do with potentially mutable
layout, i.e. metrics, bounding boxes etc. This question has been raised
once, in case of Type 3 fonts, then it has been raised again, in case of
the OpenType Layout "rand" (Random) feature, and in both cases the
industry de facto rejected a full implementation which could potentially
deeply screw up their existing layout paradigms.

In most exsting text layout implementations, the "whole of" text layout,
i.e. all possible combinations of glyph sizes and locations, is finite,
immutable. And I don't think we really want to change it, so if we ask
ourselves two questions:

1. Do we want to allow for glyph metrics, i.e. the sizes and locations
of their "designated canvases" to change "as the user is typing" (or
reflowing, line-breaking etc.)? My understanding is that we don't.

2. How do we deal with the question of "designated" or "reserved"
canvases on which the glyph "can paint" -- in terms of animation. My
simplistic take would be to treat the bounding boxes for SVG OpenType
glyphs not as INHERITED from the particular static instance of the glyph
outlines, but as DECLARED, just like an SVG canvas. You declare the size
of the canvas, and anything that is on the canvas, stays on the canvas.
If it falls out of the canvas, it disappears/gets clipped. But the
contents of the ink can be smaller than the declared canvas ("bounding
box") at any time. Yet the layout engine must know the size of the
canvas in advance, and the size of that canvas may not change later. It
needs to be immutable, declared once, statically. Of course, the canvas
is independent of the position of the glyph origin, of the advance
width, of the advance height etc. The metric box needs to be separate
from the canvas box -- but that's LARGELY already the case in OpenType.
The line layout model in OpenType is confusing, and some applications of
it (notably Windows GDI) are deeply flawed, but again, this ISN'T our
concern. We need means to specify the size of the canvas box, and the
size of the metric box of a glyph, using, as far as possible, means that
are already part of OpenType (hhea, hmtx, OS/2, vmtx, possibly VORG) --
though there may be a need to add an extra table, I don't know. Yet:
once this is done, and if then an application is stupid enough to clip
anything that is outside the metric box, although it still is within the
canvas box, then it's a bad implementation.

> There are NUMEROUS other reasons in a complex rendering environment
like PDF, XPS
> or Apple's Quartz that we need these issues resolved.

I realize that I may be wrong with many of my assumptions above, so I'd
be grateful if you could name a few.

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 19:09:56 UTC