RE: Glyph bbox concerns

1 - For the most part, yes.  However, sometimes c & d are combined or d happens before c.  (but that's an implementation detail - the concepts you expound are exactly the right ones)

2 - Again, pretty much, that is correct.  And as you wrote, what falls into c & d can vary based on the context/environment.  

3 - Yes, exactly!  

And thanks for taking the time to flush that out - I think it really puts everything out on the table for discussion.

Leonard 

-----Original Message-----
From: Adam Twardoch (List) [mailto:list.adam@twardoch.com] 
Sent: Monday, August 27, 2012 6:08 PM
To: public-svgopentype@w3.org
Cc: Leonard Rosenthol
Subject: 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 23:24:54 UTC