RE: Two flavors of glyphs: color-specifying and color-inheriting

> I think in our SVG-in-OpenType spec we can just define how these input paints get translated into SVG paint values
>
No, you cannot do that!

You are thinking about a "Web" or "Screen" only world - but OpenType is used EVERYWHERE!   Think about all the places that you see fonts used that aren't working in an (s)RGB world or where the final output isn't a "bit buffer".  The most obvious, and common, being a physical printer.  Printers are CMYK (or CMYK+other) inks being placed onto a physical media.  How do you expect your SVG renderer to know what to do in that case??  There is no "bit buffer" for it to render into.  Also consider other hardware devices, perhaps even in monochrome devices such as teletypes, billboards, scrolling text signs, etc..  

This is why we need two types of glyphs.   And in the case of the second type, it MUST only return a shape.

Leonard

-----Original Message-----
From: Cameron McCormack [mailto:cam@mozilla.com] 
Sent: Saturday, February 25, 2012 7:32 PM
To: Leonard Rosenthol
Cc: Edwin Flores; Sairus Patel; public-svgopentype@w3.org
Subject: Re: Two flavors of glyphs: color-specifying and color-inheriting

Leonard Rosenthol:
> It's that the current fill paint or stroke paint isn't compatible with 
> SVG - so that the SVG renderer couldn't do the drawing.
>
> Consider PDF, which supports a variety of colorspaces that SVG does 
> not.  For example, the current fill "paint" might be a spot color (e.g 
> Pantone or Toyo).  How would I pass that down to the SVG system?
> Obviously, I can't.  Which is why it the SVG has to pass back the 
> shape/mask back up to the font engine and then back up to the 
> rendering system.

I think in our SVG-in-OpenType spec we can just define how these input paints get translated into SVG paint values.  For Web content, it's clear how to do this.  We can include some more generic language too to say that if the referencing (non-Web) document has a paint that is sRGB then that easily maps into the corresponding SVG/CSS colour value.  For colours in other colour spaces that are not natively supported by the SVG implementation and which are convertable to sRGB, we could require that they be converted.  If the SVG implementation supports SVG Color[1] then that gives us a way to represent other colour spaces and even device/spot colours exactly in the SVG content.  For situations where the input paints cannot be converted into sRGB and the SVG implementation does not support SVG Color, we could define these to map to (say) black.

[1] http://dev.w3.org/SVG/modules/color/publish/SVGColor.html

Received on Sunday, 26 February 2012 13:23:56 UTC