Fwd: XSL comments on SVG Print

------- Forwarded message -------
From: "Sharon Adler" <sca@us.ibm.com>
To: "Erik Dahlström" <ed@opera.com>
Cc: w3c-xsl-fo-sg@w3.org
Subject: XSL comments on SVG Print
Date: Thu, 28 Feb 2008 01:01:44 +0100

Erik,

I have attacted the comments from the XSL FO subgroup on SVG Print.  The
comments have been written for a while but I did not get them sent to your
WG - mea culpa.

Here is the full text of the combined comments:  The comments may also be
found at:
http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2008Feb/0021.html

I deeply apologize for the lateness and hope that you all will be able to
process them.

Part 1: Primer
==============

2. User Agent
-------------
As we're using Adobe Reader reading PDF, there are some specific
features, and/or properties can be added in the PDF to improve the
interactivity between user and the computer.  E.g. the default zoom
rate, bookmark trees, etc.  I'm wondering SVG print will incorporate
some of the good features of Adobe Reader or not.

;;;

As for a SVG print preview agent's implementation, it ought to respond
quickly for a request of displaying a svg print document, e.g. in a
internet based environment, it needs to display the content as it's
still loading from the server as soon as it's possible to do so.  PDF
has such feature to allow user to read first page of the doc as it's
still loading.  I'm wondering if SVG print can add such requirement or
spec or not.


3.1 The pageSet and page elements
---------------------------------

The pageSet is the outmost wrapper of the pages and defines the overall
content to be printed. Unfortunately only 1 pageSet is allowed which
limits a possible mapping to the fo:page-sequence.
Having a concept of pages that belong to the same "document" or "record"
is important in imposition. A smart imposition engine could
automatically generate the appropriate imposition in variable length jobs.

;;;

For clarity, I would add that the id attribute has been added solely for
the purpose of referencing the element in the text.

3.2 The scope of a page
-----------------------

The page element wraps the content belonging to a page. A page element
doesn't have any positioning or size attributes, these are expressed
only in the main SVG element. This could be a serious limitation when in
fo we have page-masters with different sizes and not only orientation.
The output will need to be on separate files potentially loosing the
correct printing sequence.

;;;

Editorial: I think it would be clearer if element names would have a
slightly different style in paragraphs.


3.3 Master Page - 3.5 Selecting a Master Page...
------------------------------------------------

The masterPage concept is used to enable re-usability within a printing
workflow. The masterPage can have a background or foreground scope,
which enables it to be either positioned below or above the content
enclosed in the page element. The masterPages scope is always global,
but it can be re-defined at any time and it will substitute any
previously existing background or foreground masterPage (independently
 from their id).

In my personal opinion the lack of correspondence between the masterPage
id and the use-master-page reference is really confusing.
It could be very interesting to place all the re-usable parts in these
constructs to reduce the ripping time.
In order to take advantage of this feature an fo rendering engine needs
to have access to the full xslt+fo template, there is no explicit fo way
of tagging re-usable or non-variable content.
MasterPage also is a misleading name, since it doesn't really have
anything to do with a page master. Maybe a more appropriate name is
reusableFrame.

;;;

I agree this is too complex. If you refer to a specific part of an
external file, the other elements of that external file should not have
any influence in my opinion.


3.9 Relationship between XSF(L)-FO pages and SVG Print pages
------------------------------------------------------------

The presented workflow doesn't have a clear representation of how
imposition is handled. From the picture the resulting SVG Print out of
the FO Formatter presents two pages that are imposed in a sheet (these
can be single or double sided, not clear). Since SVG Print can only
express pages and not sheets it means that one page will contain all the
two pages and the surrounding marking elements.
If this is the case the imposition is directly done inside the rendering
engine, something we are definitely not considering or envisaging.
The workflow should be extended adding an explicit imposition step
(probably driven by JDF) which takes SVG-Print as simple sequence of
pages and produces the SVG Print document in the picture.
In my opinion it would be really good if SVG Print had a concept of
sheet which in addition to multiple pageSets could properly express a
pre-imposed variable data/variable length format and a post-imposed rip
ready format.

;;;

Contains a typo (XSF-FO instead of XSL-FO) Editorial: I rewrote the
section a little bit to use terminology I think is more common.

-------
XSL-FO has a concept of pages. SVG Print also has pages. Many XSL
formatters are also capable of handling SVG graphics. How do the
concepts interact, and do they overlap?

SVG graphics which are used as diagrams in an XML document should not
use the SVG Print page element. Although it is possible to imagine
interactive page flipping (Q: Would this use the SVG page element for
that reason? If not, don?t mention it here) in a diagram presented
online, this would not be visible when the document was printed.
A typical conceptual workflow would start with an XML document (such as
DocBook or DITA) and some SVG illustrations. An XSLT stylesheet acts on
the XML to produce an XSL-FO result. The XSL-FO is then formatted, which
may produce multiple pages of laid-out text and graphics using the XSL
page mechanism. The formatted results then need to be rendered to an
output format such as for example PDF, PostScript or SVG Print. Thus,
the SVG used as input at the start of the workflow, as illustrations,
and the
SVG used as output at the end of the workflow, to express the formatted
result, have different roles.
------


3.10 Animation and Scripting
----------------------------

This section mentioned about not running any script or starting any
animation in any page being displayed,  but it doesn't mentioned what
the page will look like, does it show the first frame of the animation
or the last frame? In some cases, last frame is what the user wants to
show.


4.3 Relationship to existing job control standards
--------------------------------------------------

In XSL-FO 2.0 RD document (hereinafter FO2.0 RD), section 8.3 "Print
specific properties", we mentioned that some of the properties will
probably be done with a Job Control specification such as JDF, I'm
wondering if SVG Print can also incorporate some of these properties
into their spec or not, because in the SVG Print 1.2 spec's part 1
primer doc (hereinafter Print1.2 Primer) section 4.3, it mentioned about
the interleaving of SVG print doc and the job control commands, but not
getting into details about how the interaction works between each other.

4.3.1 JDF
---------

One specific remark I have is similar to one of Fabio: JDF is referred
in SVG print, but there is no example of how to handle JDF. I have tried
in the past to combine JDF and XSL, but haven't succeeded to make it
just do basic printer tasks like duplex printing and input/output tray
handling. For that reason we created our own extension attributions (not
based on JDF) to do duplex and tray handling. I would suggest to SVG to
either include some properties for duplex and tray handling, or even
better make a simple example how to achieve this with JDF. I have spoken
to Anthony Grasso from Canon about this (the editor of the SVG Print
Spec) and he said he had a colleague next door that could do this, so I
really think that would make SVG Print better.


4.4 Examples of SVG bundled jobs
--------------------------------

I would consider adding an example or reference to the data:// URI
scheme to embed images as well. This allows us to have a valid XML file
with embedded image data. This may be easier to create and modify in
some use cases.


5. Color specification
----------------------

These seems to be appropriate and I would like to see the deviceColor
being adopted by fo as well.

;;;

SVG has very advanced support in color, we ought to incorporate that
into FO spec.  Besides that SVG has already supported font embedding, in
order to generate SVG print doc from xsl-fo formatter in a high-fidelity
manner, we also need to think about how we can incorporate font
embedding in the FO specification.



Part 2: Language
================

5.1 Color interpolation
-----------------------

Even the doc clearly mentioned that animation is not supported in SVG
print (primer section 3.10), some of the attributes' specification
mentioned in the doc are still listed as "animatable", e.g. section 5.1
'color-interpolation', section 5.3.5 'color-profile', I'm wondering if
this is confusing or not.


5.3 Color profile descriptions
------------------------------

I consult with some colleagues at HP about Rendering Intent for SVG Print.
It seems that the definitions are not so accurate.
These are the definitions and comments I collected:

Media-relative colorimetric (a.k.a. relative colorimetric) This method
is required to leave source colors that fall inside the destination
medium gamut unchanged relative to the respective media white points.
Source colors that are out of the destination medium gamut are mapped to
colors on the gamut boundary using a variety of different methods.

NOTE The media-relative colorimetric rendering intent is often used with
black point compensation, where the source medium black point is mapped
to the destination medium black point as well.

ICC-absolute colorimetric (a.k.a. absolute colorimetric) This method is
required to leave source colors that fall inside the destination medium
gamut unchanged relative to the adopted white (a perfect reflecting
diffuser). Source colors that are out of the destination medium gamut
are mapped to colors on the gamut boundary using a variety of different
methods. This method produces the most accurate color matching of
in-gamut colors, but will result in highlight clipping if the
destination medium white point is lower than the source medium white
point. For this reason it is recommended for use only in applications
that need exact color matching and where highlight clipping is not a
concern.

Perceptual
This method is often the preferred choice for images, especially when
there are substantial differences between the source and destination
(such as a CRT display image reproduced on a reflection print). It takes
the colors of the source image and re-optimizes the appearance for the
destination medium using proprietary methods. This re-optimization may
result in colors within both the source and destination gamuts being
changed, although perceptual transforms are supposed to maintain the
basic artistic intent of the original in the reproduction. They will not
attempt to correct errors in the source image.

NOTE With v2 ICC profiles there is no specified perceptual reference
medium, which can cause interoperability problems. When v2 ICC profiles
are used it may be safer to use the media-relative colorimetric
rendering intent with black point compensation instead of the perceptual
rendering intent, unless the specific source and destination profiles to
be used have been checked to ensure the combination produces the desired
result.

Saturation
This option was created to preserve the relative saturation (chroma) of
the original, and to keep solid colors pure. However, it experienced
interoperability problems like the perceptual intent, and as solid color
preservation is not amenable to a reference medium solution using v4
profiles does not solve the problem. Use of this rendering intent is not
recommended unless the specific source and destination profiles to be
used have been checked to ensure the combination produces the desired
result.





Sharon C. Adler
  Senior Manager, Extensible Technologies
  IBM Research
  PO Box 704, Yorktown Heights, NY  10598
  tel:  914-784-6411 t/l 863
  fax: 914-784-6324



-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Thursday, 28 February 2008 09:05:16 UTC