- From: Cameron McCormack <cam@mozilla.com>
- Date: Sun, 26 Feb 2012 11:31:36 +1100
- 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 UTC