Feeback on SVG Print

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