Re: Glyph bbox concerns

Leonard,

Can I try to rephrase the issues you raise, so you and I get in the same
boat?

So what I believe you are saying is:

1. A font model in general works as follows:

a) on the Input side, there are some External Ingredients such as
encoded text, some font-related formatting instructions, some
font-unrelated formatting instructions, some geometric constraints into
which the output should be rendered

b) on the Input side, there is also the Font as an important component,
which itself provides important Internal Ingredients such as glyph
shapes, metrics, layout information and instructions how to process the
encoded text into glyphs and how to produce the rendering

c) on the Processing side, there are a number of procedures which take
the External and Internal Ingredients, perform some operations and
produce some kind of "plain" Rendering, i.e. an outline- or
bitmap-based, typically rectangular, rendering of glyph positions and
shapes; some of the External Ingredients are simply passed on to the
next step

d) on the Output side, the Rendering is passed onto further processing
which may involve geometric distortions, masking, compositing etc.

So it's a+b -> c -> d

2. Currently, the "OpenType font model" (or font models similar to some
extent to OpenType, such as Type 1, AAT etc.) works as follows:

a) the External Ingredients include encoded text (often in Unicode),
font-related formatting instructions (desired font size in points or
other units, linespacing, letterspacing, OpenType Layout feature
requests), font-unrelated formatting instructions (text fill with
properties such as color in a particular color model or mask, text
stroke with properties such as color in a particular color model and
thickness and stroke styling, additional text decoration attributes)

b) the Internal Ingredients include simple, immutable, monochrome glyph
shapes, glyph boxes placement of the glyphs, sometimes implicit glyph
boxes for the inking, mechanisms to assign glyphs to encoded text
codepoints, additional layout mechanisms such as OpenType Layout feature
implementations which perform substitutions and positioning)

c) in some cases, the Processing ignores certain External Ingredients
such as text fill or stroke and the associated colors, converts the
encoded text into glyph positions and their shapes, which are often
expressed as simple monochrome outlines or a 1-bit mask, and passes the
resulted Rendering to the Output; sometimes text fill and stroke is
taken into account, some pre-compositing is performed and a
pre-composited Rendering is passed onto the Output, in that case usually
as a bitmap;

d) in the Ouput, the Rendering (again, often a simple outline or 1-bit
mask) is accepted and subject to further processing: geometric
distortions, masking, compositing; the previously unprocessed External
Ingredients such as text fill or text stroke are fed into the overall
compositing process

3. The "SVG OpenType font model" changes that to the extent that:

a) the External Ingredients may need to be extended by some additional
font-related formatting instructions which would affect the internals of
the SVG glyphs (for example if we want to somehow externally change
certain colors within the SVG glyphs); if animation is supported, some
kinds of additional font-related instructions would need to be added
which allow us to control the animation events;

b) the number of Internal Ingredients rapidly increase -- the Font now
produces ingredients such as color model (SVG supports only RGB well),
per-glyph or even per-path attributes such as fill, stroke, mask etc.,
which can potentially conflict with the External Ingredients of the same
kind; the conflict may sometimes be simple to resolve (if both the
Internal and the External Ingredients use the same model, the Internal
Ingredients could simply override the External Ingredients, or could
somehow be combined), yet sometimes the Internal Ingredients may be
fundamentally incompatible with the External Ingredients (e.g. the
Externally specified text color uses a color model not supported by the
Internally specified glyph fill colors); optionally, Internal
Ingredients may involve animation;

c) the Processing part needs to be changed since it now has to honor the
various fills, strokes and other attributes, and possibly also
animation, and can no longer output a "simplistic" Rendering; the
Rendering which is being output has to be richer, so a new protocol has
to be defined; fallback scenarios for different kinds of Renderings need
to be defined (so the new Rendering also is able to output old-style
Renderings, i.e. plain outlines or 1-bit masks).

d) the nature of the Output is now changed, therefore further steps that
beforehand accepted the simplistic Renderings and were in full freedom
to apply additional processing now have to take into account that the
Rendering is now "rich" and not "simple", and that some aspects of the
new, rich Rendering may conflict with ways the old Output was treated;
for example, if in the old model, text fill and stroke were passed on
from Input and applied to the Rendering at the final stage, the new
Rendering now comes with a mixture of its own fills and strokes,
possibly using a model which may not be entirely compatible with what
the Output side now expects; decisions regarding masking and compositing
need to be made which did not have to be made previously.

Is that, more-less, what you're aiming at?

BTW, as to my background: I'm not a computer scientist nor a software
developer, though I had two years of computer science at university. I
work with software developers every day. When it comes to software,
especially typography-related software, I define the "whats" and
sometimes I prototype the "hows", and I often am responsible for
explaining the "whys", but I rarely actually implement the "hows" to the
full extent.

I work as product and marketing manager for Fontlab Ltd., where I'm
responsible for the large part of the functional aspects of font editing
applications such as FontLab Studio and Fontographer, and to a minor
extent for the software aspects (I prototype code but don't write the
final versions). I also work as font technology consultant for MyFonts,
now division of Monotype Imaging.

I've provided font technology or type-related consulting to companies
such as Adobe, Bitstream, Corel, Linotype and others; I've been an
active user of and a contributor to typographic open-source software
such as XeTeX, FreeType and HarfBuzz. I'm member of the board of
Association Typographique Internationale (ATypI), an international
association of type designers, and I'm member of the board of the Polish
TeX Users' Group (GUST).

I've been involved as a tester or consultant in the Unicode-, OpenType-
and type-related aspects of high-level publishing software of some
companies including Adobe's; I've been on the W3C WebFonts WG from its
very beginning; I've been credited as the "kick off" contributor of the
font-feature-settings section of the CSS3 Fonts spec, and of this very
group.

I develop software models, I write Python code, I read C code but I
don't write it.

Hopefully this helps a bit in sorting out of where I come from, what I
can and what I don't necessarily understand :)

Many thanks for the discussion so far!

Best,
Adam



On 12-08-27 21:59, Leonard Rosenthol wrote:
>> 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.
>>
> ONLY if you are dealing with an RGB-based workflow.  But most professional print workflows are NOT based on RGB - they are based on other color models such as CMYK, Spot or DeviceN.  None of which are supported by SVG at this time.   And that's fine, in general...BUT when a user wants to use an SVG-based OT font in their document to be printed and assign one of those color models to the text - it fails :(.   And that's why it's a problem.   
>
>> 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:
>>
> But what if a future version of PDF WANTS TO support them?   That can only happen _IF_ we design for it up front.  And what I am trying to explain (but for some reason you refuse to hear) is that the proposed model DOES NOT ALLOW THAT.    
>
>
>> I still don't see how SVG OpenType fonts bring any problems that are entirely new and only specific to SVG OpenType.
>>
> I don't know your background, so forgive me if this is not true.  But perhaps because you've never written a font renderer nor programmatically used one to layout text on a page...
>
> Again, it's NOT SVG that is the issue.  It's that we are proposing a COMPLETELY NEW MODEL for how OpenType rendering is going to work.  And the model isn't compatible with all existing uses of OpenType.   That fact that it's SVG is not relevant to my concerns - they would exist for ANY technology/format used in this manner.  
>
> So no, these issues are NOT NEW - because no one to date (other than Apple's 'sbix' hack) has tried to change the OT rendering model.
>
>
>> 95% of SVG OpenType fonts is basically a repackaging of techniques which already exist in the industry.
>>
> BUT in a completely new way...and that's the problem.  It's the combination of pieces - not the pieces themselves.
>
> Don't get me wrong - I FULLY SUPPORT SVG/OT.  I think it has a lot of potential.  HOWEVER, there are still MANY MANY questions to be answered about specific (low level) implementation considerations.
>
>
>> 2. How do we deal with the question of "designated" or "reserved" canvases on which the glyph "can paint" -- in terms of animation. 
>>
> The other (IMO, bigger) question is, again, how this works for non-web-based "canvases".   How would this work in MSWord or TextEdit, for example?  Or InDesign, Pages or Quark, with richer imaging models? 
>
>
>>> 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.
>>
> Consider that the user wants to use some SVG/OT-based text as a mask for an image.  How would that work?
>
> How do you fill (or worse, stroke!) an SVG/OT glyph with a type of "paint" that SVG doesn't support, for example a coons-mesh shading?
>
> How do you composite an SVG/OT glyph with a transparency mode not (currently) supported by SVG?
>
> (etc.)
>
>


-- 

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

Received on Monday, 27 August 2012 22:08:56 UTC