- From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
- Date: Tue, 16 Sep 2003 17:28:00 -0400
- To: www-svg@w3.org
Hi all, I would like to submit my detailed feedback on the SVG Print Working Draft of July 15, 2003. Section 3.1.1 My vote would be to define a 'virtual' transformation that was then used for styling. Natively implementing either approach 'natively' would require a very SVG Print specific CSS engine but at least the transformation approach leaves open a simple way to implement correct behavior in existing implementations. This would also avoid any issues with CSS sibling selectors across pages. Section 3.2 The specification suggests using the fact that elements outside page elements are rendered for every following page to implement a form of 'master pages'. It occurs to me that often the master page changes through the course of the document, title page, TOC, forward, body, index, etc. Is the intent that you 'hide' the previous master page by say drawing a 'white' rectangle? This seems problematic to me as there may be cases where it is desirable to leave the background transparent. Section 3.3 The last sentence says "should generate and set the outermost svg element attribute streamable to 'true'", don't you want that be a 'must' for 1.2 content? After all the page scoping for refs is a hacked down version of this anyway. It would seem that if pageSet is supported content within a pageSet but outside individual pages could be scoped for the pageSet. This might provide a good way to handle the need for changing master pages. Section 3.5 The example for a multi-page file uses the pageSet element which is not referenced from SVG Print. Is this intentional? Section 4.2 I think it would be a critical mistake for SVG Print to omit a standard for bundling content for print. This is a truly essential piece for many printing scenarios. I would strongly encourage the working group to pick at least one bundling format that would be mandatory and allow vendors to implement others that may be more capable for certain use cases (as is done for images, and fonts). I also think that bundling is at least potentially separable from job control (at least in low to mid end use cases where generally everything is printed one way). Given your move to every page being the same size this seems appropriate. It is also concerning that none of the proposals outlined allow for the direct embedding of binary data (much of the bundled data is likely to be binary data like raster images) or allow for seeking (very important for desktop viewers), it is possible the Multiplex MIME option could be made seekable by (mandating?) the inclusion of 'Content-Length:' attributes. Finally my vote for the bundling format would be a simple tar file (perhaps containing gziped SVG content) as tar files are seekable and streamable (otherwise zip would be my suggestion), can embed binary data, represent a virtual file system (which greatly reduces 'transcoding' needs: "eye.jpg" -> "cid:foo") and the tools/libraries are widely available. The only major feature tar doesn't provide is the ability to interleave data streams which is useful in some higher end cases but some instances still must buffer the data (a JPEG printed 'upside down' or rotated 90deg). It is really critical that at least one bundling format be manditory - otherwise the standard simply does not promote interoperability.
Received on Tuesday, 16 September 2003 17:28:09 UTC