W3C home > Mailing lists > Public > public-svgopentype@w3.org > February 2012

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

From: Cameron McCormack <cam@mozilla.com>
Date: Sun, 26 Feb 2012 11:31:36 +1100
Message-ID: <4F497D68.30206@mozilla.com>
To: Leonard Rosenthol <lrosenth@adobe.com>
CC: Edwin Flores <eflores@mozilla.com>, Sairus Patel <sppatel@adobe.com>, "public-svgopentype@w3.org" <public-svgopentype@w3.org>
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 00:32:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 26 February 2012 00:32:17 GMT