RE: Glyph bbox concerns

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

Received on Monday, 27 August 2012 20:00:30 UTC