Re: Fwd: XSL comments on SVG Print

Hi Sharon,

Thank you for excellent feedback you and the XSL-FO Group have provided 
on the SVG Print specification! :)

The SVG Working Group will be discussing the feedback in the upcoming 
weeks and provide responses on each of the comments.

Kind Regards,

Anthony Grasso

Software Engineer

Canon Information Systems Research Australia
Email: anthony.grasso@cisra.canon.com.au

---

The information contained in this email message and any attachments may 
be confidential and may also be subject to legal professional privilege. 
If you are not the intended recipient, any use, interference with, 
disclosure or copying of this material is unauthorised and prohibited.

If you have received this email in error, please immediately advise the 
sender by return email and delete the information from your system.

Erik Dahlström wrote:
> 
> 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
> 
> 
>

Received on Thursday, 28 February 2008 20:25:24 UTC