- From: Chris Lilley <chris@w3.org>
- Date: Thu, 11 Jun 2009 23:02:59 +0200
- To: public-svg-print@w3.org
Hello w3c-xsl-fo-sg, Some time ago you gave some feedback on SVG print http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0005.html and Anthony Grasso briefly responded at the time http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0006.html since then the SVG WG was primarily occupied with spec writing and test suites for other specifications. More recently work has restared on these SVG modules. SVG Print has been split into two specifications, one for the multipage functionality and one for color management. It is in connection with the latter of these that I am contacting you now. Your comments are listed in a draft disposition of comments http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html#SVGP12-009 http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html#SVGP12-010 http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html#SVGP12-011 In regards to comment 009, the SVG WG is pleased that you find the color specifications appropriate and would like to further discuss hpw these might concretely be incorporated in XSL 2.0. Given the different constraints on syntax for each specification, we would expect alignment at the functional rather than the syntactic level,XSL continuing to use its functional notation. Perhaps we could meet up at TPAC, if XSL will be there; or I could perhaps attend the Bologna XSL FO meeting, as its relatively close to where I live in Nice. Coordination via email would also work of course. Or perhaps a contribution document as a starting point. Please advise what would work best for you. Regarding comment 010 about some properties being marked as animatable, even though SVG print does not support animation. We agree this could be confusing, it was done like that to allow reuse of the color material in other profiles besides print. This was an inadvertent consequence of the SVG Print spec attempting to address printers, other paged media such as print preview, and general SVG all in one specification. SVG Color provides a general color upgrade for SVG, and so indicates which properties are animatable. Naturally, the animatability only applies to dynamic profiles which support animation. So, while we still say which properties are animatable, we hope that this no longer causes an apparent conflict. Specifically, it would not require XSL processors to animate them. Rather, this indicates, for dynamic SVG processors which perform animation, which properties may *not* be animated. For comment 011 about language for rendering intents, your suggested language is much better, more up to date, and precise that what we had and we have completely adopted your wording. http://dev.w3.org/SVG/modules/color/master/SVGColor.html#ColorProfileElementRenderingIntentAttribute Please note: for the device-color element, we agree that the previous text was underspecified, vague, and hard to implement in an interoperable manner. At this weeks face to face meeting the SVG WG decided to change the syntax to one which is simpler and directly maps to the PDF DeviceGray, DeviceRGB and DeviceCMYK constructs (and also to a multichannel option). This part is not fully specc'ed out yet, but there is an early editors draft of SVG color at http://dev.w3.org/SVG/modules/color/master/SVGColor.html that portion of the spec is changing, but we are starting to edit in an alternative that may well be suitable for XSL FO as well. Please let us know if these responses correctly address your comments. Sorry again for the delay between your comments and our substantive response. We look forward to working with you to enable a consistent calibrated color capability across SVG and XSL. Followup is set to public-svg-print@w3.org, which is a public list. -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Thursday, 11 June 2009 21:03:10 UTC