SVG Print 1.2, Part 1: Primer

W3C Working Draft 21 December 2007

This version:: http://www.w3.org/TR/2007/WD-SVGPrintPrimer12-20071221/
Latest version:: http://www.w3.org/TR/SVGPrintPrimer12/
Previous version:: http://www.w3.org/TR/2007/WD-SVGPrintPrimer12-20070501/
Editors:: Anthony Grasso, Canon Information Systems Research Australia, <anthony.grasso@research.canon.com.au>; Andrew Shellshear, Canon Information Systems Research Australia, <andrews@research.canon.com.au>; Chris Lilley, W3C <chris@w3.org>
Authors:: The authors of this specification are the participants of the W3C SVG Working Group.; Copyright © 2007 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

This Working Draft is a primer for use of the Scalable Vector Graphics (SVG) Language for printing environments. It explains the technical background and gives guidelines on how to use the SVG Print specification with SVG 1.2 Tiny and SVG 1.2 Full modules for printing. It is purely informative and has no conformance statements.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is a Last Call Working Draft. The W3C Membership and other interested parties are invited to review the document and send comments to to public-svg-print@w3.org (archives) until 8 February 2008. There is an accompanying SVG Print 1.2, Part 2: Language that defines conformance criteria, new and reintroduced language features for SVG Printing.

We explicitly invite comments on this specification, which has already benefited from comments at the W3C Print Symposium. Please send them to public-svg-print@w3.org (archives). For comments on the core SVG language, use www-svg@w3.org: the public email list for issues related to vector graphics on the Web (archives). Acceptance of the archiving policy is requested automatically upon first post to either list. To subscribe to these lists send an email to public-svg-print-request@w3.org or www-svg-request@w3.org with the word subscribe in the subject line.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. This document is informative only. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

How to read this document and give feedback

The main purpose of this document is to encourage public feedback. The best way to give feedback is by sending an email to public-svg-print@w3.org. Please identify in the subject line of your message the part of the specificationto which your comment refers (e.g "Print compositing" or "Print render formats"). If you have comments on multiple areas of this document, then it is preferable to send several separate comments.

The public are welcome to comment on any aspect in this document, but there are a few areas in which the SVG Working Group are explicitly requesting feedback. These areas are noted in place within this document like this. There is also a more general question, listed here:

Interaction with other print standards. The SVG Working Group believe that some design decisions would be best made in collaboration with other print standards bodies, and would welcome liaison statements in this area.

1 Introduction

Because of its scalable, geometric nature, SVG is inherently better suited to print than raster image formats. The same geometry can be displayed on screen and on a printer, with identical layout in both but taking advantage of the higher resolution of print media. The same colors can be output, using an ICC-based color managed workflow on the printer and an sRGB fallback approximation on screen. This has been true since SVG 1.0, and so SVG has been used in print workflows (for example, in combination with XSL FO) as well as on screen.

However, SVG also has dynamic, interactive features such as declarative animation, scripting, timed elements like audio and video, and user interaction such as event flow and link activation. None of these are applicable to a print context. SVG 1.1 gives static and dynamic conformance classes, but further guidance on what exactly SVG Printers should do with such general content is helpful. The SVG Print specification defines processing rules for handling such general purpose content which was not designed to be printed, but which may be encountered anyhow.

It is common in cross-media publishing to design content which will be used both online and in print media. This specification gives guidance on how to create such content and how to indicate that it has been adapted to improve its print capability.

Lastly, it is possible to generate SVG which is exclusively intended for print (for example, a printer which natively understands SVG). This content might be created in an illustration program, or it might be an output from a layout program, such as an XSL-FO renderer; or it might be generated by an SVG Print driver. This specification defines conformance classes for software which reads this type of SVG,and also a conformance class for SVG Print content.

2 User Agents

There are two kinds of User Agents for SVG Printing - ones that are responsible for printing an SVG document, and ones that are responsible for showing print previews to the user on a screen.

An SVG Print Preview Device displays a preview on a screen of what the printed pages should look like. It allows a user to view each page, and choose the page orientations, which pages should be printed, and other options for printing.

An SVG Printing Device, in general, doesn't interact directly with a user. It's responsible for receiving the SVG content and the instructions for what to do with it (in general, this is called "Device Control") and then printing it.

3 Printing using Pages

SVG Print documents may be structured to facilitate printing. In particular, it is possible to construct content that is designed to be printed on multiple pages.

Example: An example with a bit of everything

<svg xmlns="http://www.w3.org/2000/svg">

   <!-- Default Background Master Page definitions go after the svg element and before the pageSet -->
   
   <defs>
     <!-- definitions here are available on each page -->
   </defs>

   <!-- graphics here are visible on each page -->

   <pageSet>

      <masterPage rendering-order="over">
        <!-- graphics here are visible in the foreground on each page -->
      </masterPage>

      <page>
        <defs>
          <!-- These definitions are local to this page. -->
        </defs>
        <!-- graphics for page 1 go here -->
      </page>

      <page orientation="90">
        <!-- graphics for page 2 go here -->
      </page>

      <page noPrint="true">
        <!-- This page is not printed -->
      </page>

   </pageSet>

   <!-- No SVG content is allowed here -->
   
</svg>

3.1 The pageSet and page elements

SVG Print introduces a scoping mechanism (the pageSet and page elements) in order to delimit the physical pages for output on an SVG Print device.

Example: page01.svg

<svg xmlns="http://www.w3.org/2000/svg">

  <text x="20" y="20">This text is on the top of every page.</text>

  <pageSet id="pageSet1">

    <page id="circle_page">
      <circle cx="100" cy="100" r="20" fill="blue"/>
    </page>

    <page id="rectangle_page">
      <rect x="100" y="100" width="20" height="20" fill="red"/>
    </page>

  </pageSet>

</svg>

One physical page of output is generated for each page element present in the SVG file. In the absence of any page element, one page of output will be generated only if the SVG file contains content which marks the image canvas.

3.2 The scope of a page

If a page contains a defs section in it, those defined objects are only available for reference within the content of the enclosing page element. If some other page element in the document contains a use which references the id of some object in a different page element, that reference is not resolved. This means that the rendered result will appear as if the definition did not exist.

The scoping mechanism allows an implementation to free any resources required to print a single page, after having finished with that page. This also provides a simple mechanism to print page ranges by skipping content between page elements until the desired page range is reached.

3.3 Master Page

SVG Print document allow the use of Master Pages. A Master Page isn't printed separately, but appears in the background (or foreground) of every document Page. There are two ways of doing this.

In the first (and simple) way, all content which is within the outermost svg element and before the pageSet element are considered to be the Background Master Page. It is then displayed on all pages behind all the content of the pages (as though it immediately preceded each page).

In the second, more complete way, master pages can be defined for groups of pages. In addition, separate master pages can be defined for the background and the foreground. In this case, the user specifies a masterPage element immediately before the pages on which that master page is desired. masterPage elements can appear wherever a page element could appear, though they aren't rendered.

The rendering-order attribute allows the user to specify whether the master page is a Background Master Page (rendering-order="under") or Foreground Master Page (rendering-order="over"). Note that there can only be a single Background Master Page and a single Foreground Master Page in operation on any page. The User Agent deletes the old Background Master Page or Foreground Master Page whenever it encounters a new one of the same kind.

It is possible to mix the default Background Master Page with explicit masterPage elements, but this is not recommended. If another Background Master Page is encountered, the default Background Master Page is no longer used as a default master page, including any definitions. This might be confusing to some users. For most use cases, the author would either have a default Background Master Page, or declare a Background and/or Foreground Master Page before any page elements in a pageSet.

For example, if a rectangle was drawn prior to the appearance of any page elements in the SVG document, that rectangle would appear on every page printed by the SVG Print device. If a masterPage was specified after the rectangle was drawn, the rectangle would no longer be used as the background for every page. Instead the content specified in the masterPage would be used as the background for every page.

Note if a masterPage is specified and the author wishes for certain objects to be reused it is good practice to have the objectsto be reused specified in a defs element before the pageSet.

Example: Background and Foreground Master Pages

<svg xmlns="http://www.w3.org/2000/svg">

   <defs>
     <!-- definitions here are available to page 1 -->
   </defs>

   <!-- graphics here are visible in the background on page 1 -->

   <pageSet>

      <page>
        <defs>
          <!-- These definitions are local to this page. -->
        </defs>
        <!-- graphics for page 1 go here. -->
        <!-- This page uses the default background master page, and an empty foreground master page. -->
      </page>

      <masterPage id="masterpage1">
        <defs>
          <!-- These definitions are available to pages 2-3. -->
        </defs>
        <!-- graphics here are visible in the background on pages 2-3. -->
      </masterPage>

      <page>
        <!-- graphics for page 2 go here -->
        <!-- This page uses background masterpage1, and an empty foreground master page. -->
      </page>

      <masterPage rendering-order="over" id="masterpage2">
        <defs>
          <!-- These definitions are available to pages 3 onwards. -->
        </defs>
        <!-- graphics here are visible in the foreground on pages 3 onwards. -->
      </masterPage>

      <page>
        <!-- graphics for page 3 go here -->
        <!-- This page uses background masterpage1, and foreground masterpage2. -->
      </page>

      <masterPage rendering-order="under" id="masterpage3">
        <defs>
          <!-- These definitions are available to pages 4 onwards. -->
        </defs>
        <!-- graphics here are visible in the background on pages 4 onwards. -->
      </masterPage>

      <page>
        <!-- graphics for page 4 go here -->
        <!-- This page uses background masterpage3, and foreground masterpage2. -->
      </page>

   </pageSet>

   <!-- No SVG content is allowed here -->
</svg>

3.4 Referencing other pages

It is possible for a SVG Print document to reference pages in an external document. A use element can be used in place of a page element, provided it references a page element. Note that by default it will use the master page of the referencing document, rather than the master page of the referenced document.

Example: Referencing an external page

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">

  <text x="20" y="120">Confidential</text>

  <pageSet>

    <!-- Reference a page from another document.  This will be treated as though it
         were a page of this document (ie. it will include the master page of this
         document, but not its own master page). -->
    <use xlink:href="page01.svg#circle_page"/>
     
    <page>
      <rect x="100" y="100" width="20" height="20" fill="green"/>
    </page>

  </pageSet>

</svg>

It is not currently possible to reference an entire SVG Print document from another SVG Print document.

3.5 Selecting a Master Page when referencing a page

The use-master-page attribute gives control over which Master Pages will be applied to an externally referenced page. The current Master Pages from the externally referenced document may be applied to the externally referenced page. In which case use-master-page= "external". Alternatively, the current Master Pages from the referencing document may be applied to the externally referenced page. In which case use-master-page="current".

TODO: Need feedback on this feature. Are there compelling uses cases for having this extra complexity? What benefit does it provide?

3.6 Page Orientation

The page element has a page-orientation property which may be used to rotate page content for screen display. In an SVG Print device, the page-orientation property is treated as a transform that is applied directly to the top-level element - both the master page and the elements inside the page are transformed.

Example: Page Orientation

<svg width="8.5in" height="11in" viewBox="0 0 612 792">
  <rect x="36" y="36" width="540" height="720"
        fill="yellow" stroke-width="15" stroke="black"/>
  <pageSet>
     <page>
        <text font-size="30" x="72" y="108">This is portrait</text>
     </page>
     <page page-orientation="90">
        <text font-size="30" x="72" y="108">This is landscape</text>
     </page>
   </pageSet>
</svg>

3.7 noPrint

The noPrint attribute allows users to specify things that shouldn't be printed. If its value is true on an element, that element and all its children won't be printed, as though it had been specified with display="false".

For example, in an online SVG graphics editor, a user may want to print the graphics that are produced, but they usually won't want to see the drawing tools. In this case, the drawing tools could have noPrint="true". noPrint could also be used for elementary job control, to specify which pages should not be printed, though it is recommended in this case to instead remove the non-printing pages.

Example: noPrint

<svg xmlns="http://www.w3.org/2000/svg">

  <text x="20" y="20" noPrint="true">This text will not be printed.</text>
  <text x="20" y="220" noPrint="false">Confidential.</text>

  <pageSet>

    <!-- This page will not be printed -->
    <page noPrint="true">
      <rect x="100" y="100" width="20" height="20" fill="red"/>
    </page>

    <!-- Only the rectangle will be printed on this page. -->
    <page>
      <circle cx="100" cy="100" r="20" fill="blue" noPrint="true"/>
      <rect x="100" y="100" width="20" height="20" fill="green"/>
    </page>

  </pageSet>

</svg>

3.8 Interaction of CSS and page scoping

In traditional XML content, conceptually the document is parsed into a DOM representation, and then CSS styling is applied to the document tree as a whole.

In a print environment, an implementation will most likely build a representation of an individual page and then discard it after printing. The implication of this is that any CSS usage within a page that could affect other page elements may be lost. More importantly, if a selector is introduced at the end of a document and it could have affected previously parsed page elements then the printed result may appear to be incorrect.

It is highly recommended that SVG documents using CSS define all styles for use in the entire document at the start of the SVG document, prior to any page elements. This is in accordance with recommended practice for use of CSS in other XML namespaces, such as XHTML.

It is also strongly suggested that SVG documents intended for print application be authored using presentation attributes exclusively. This implies absence of any CSS usage in documents authored for SVG Print applications.

3.9 Relationship between XSF FO pages and SVG Print pages

The XSL style language 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 in a diagram presented online, this would not be visible when the document was printed.

A typical 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. SVG Print is one possible output format for the rendered pages. PDF is another alternative. Thus, the SVG used as at the start of the workflow, as illustrations, and the SVG used at the end of the workflow, to express the formatted result, have different roles.

3.10 Animation and Scripting

As SVG Print devices are static devices, animation cannot be meaningfully represented. Any animations present in the SVG document are not played. The unanimated values from before the timeline starts will be used.

Scripting functionality provides programmability of the scripted device. This is a useful feature in a screen based renderer. Scripting is dependent on the presence of a Document Object Model (DOM) for functionality. As SVG Print devices discard resources under control of the scoped page element, a DOM representation of the document is unavailable. Thus scripting is not possible.

The lack of animation and scripting in SVG Print is consistent with the SVG 1.0 recommendation description of print devices.

4 Job control

SVG Print allows external job control standards to be applied to an SVG Print document. It does not mandate any job control standard. It provides some elementary job control with the page-orientation property and the noPrint attribute, which may be used in the absence of more complete job control information, or supplemental to it.

4.1 Printer device control

All management of SVG Print devices is vendor specific. It is expected that SVG Print devices will be supplied with some form of device driver that is capable of managing any device specific functions.

4.2 Bundling SVG files with referenced content

SVG Print documents will in many cases reference external files. Such files will include image data such as JPEG images or external SVG files. In such cases, it may be desirable to bundle the SVG document with its referenced images for transmission to the SVG Print device. In such cases, this specification does not mandate any bundling method.

In the absence of any mandatory bundling technique, vendors are free to choose any method. In unidirectional transmission configurations, it may be desirable to combine the SVG Print job with its referenced data in a multipart MIME bundle or similar. In a bidirectional transmission configuration, it may be preferable to allow the printer device to issue fetch requests for the referenced content.

The final choice for SVG Print devices is left to vendors, the following sections describe some available bundling options for consideration.

4.3 Relationship to existing job control standards

This section describes existing standards for printing and possible scenarios for use of SVG Print within such standards. This section is informative and does not imply any requirement to use such standards.

4.3.1 JDF

Job Definition Format (JDF) is managed by CIP4. This is a widely used XML based standard used in the pre-press and publishing industries.

A JDF job contains detailed job control information where any page may be composed of any page description language. In a device utilising JDF and SVG Print, the JDF file would control all paper size and job information, whilst the SVG file would contain the image data for any number of pages within the JDF document.

A typical method for bundling job data for transmission to a JDF print device uses MIME encoding to encapsulate the required files for printing. In such a case, it is recommended that binary sections of data such as raw image data be packaged according to the recommendations in RFC 3030.

4.3.2 IPP

This standard is used to manage network connected printers over existing Internet protocols. An SVG Print device could make use of this standard for fetching external resources such as images referenced inside an SVG Print document.

IPP also manages job related functions for print devices, and so could be used in conjunction with or in place of JDF for network connected printers supporting SVG Print.

4.3.3 PPML

PPML, Personalised Print Markup Language is a data format specified by PODi (Print On Demand Initiative). This language is designed to allow object-level addressability and reusability for varaible data printing. PPML can be used with existing job ticketing languages such as (JDF).

SVG can be contained within PPML files as Content Data, either external or internal. This data can be reused throughout the document or can be disposalable. Using SVG within PPML is advantageous over other graphics formats as generic XML tools can be used to validate all of the data.

4.3.4 Multiplex MIME

Multipex MIME is described in RFC 3391. This is a MIME encoding technique developed to allow the interleaving of multiple files in one MIME message. The purpose is to allow a controlling print job in a page description language to be split into multiple MIME sections, whilst interleaving referenced image data.

For example, in an SVG Print job utilising Multiplex MIME, the SVG document itself could be split into a number of MIME sections. Any referenced image content would be present in a MIME section immediately prior to the SVG Print section containing a reference to it. An example of such a MIME bundled job is shown below.

4.4 Examples of SVG bundled jobs

4.4.1 Multiplex MIME encoded SVG Print job

5 Color specification

SVG Print allows color to be specified in a number of ways. All of the sRGB color syntaxes from SVG Print 1.2 are supported. The ICC-based color syntax from SVG 1.1 Full is also supported. New to the SVG Print specification, ICC named colors and device colors are supported as well: their syntax is defined below.

5.1 sRGB colors

As with SVG Tiny 1.2, colors may be specified in the sRGB colorspace without providing a color profile. This color space, which uuses the chromaticities of a standard TV broadcast monitor and viewing conditions typical of an office environment, has a reduced gamut suitable for minimising banding on 'real world' colors at the expense of being unable to directly represent highly saturated colors. A number of equivalent syntactic forms are supported, as defined in SVG Tiny 1.2:

5.2 ICC colors

Since SVG 1.0, SVG has contained functionality for use of ICC color profiles which define colors in a different color space than sRGB. This functionality has been available since SVG 1.0 but for the most part has not been well understood. SVP Print tightens the conformance criteria for using ICC colors.

For example, it is possible to specify all objects in terms of an ICC color space such as SWOP CMYK and the SVG renderer perform all rendering of the objects entirely in the SWOP CMYK space followed by color correction for a printer target CMYK. This render workflow would never require conversion into and out of sRGB. An SVG 1.0 implementation is free to support such rendering if possible.

In the case where opacity is used and objects overlap a render device must use the supplied sRGB fallback color in order to composite objects together.

The implication of this is that it is possible to build an SVG Print device (using SVG 1.0 onwards) that supports a full CMYK pipeline via the use of ICC profiles. Such an SVG render device must also be capable of handling a switch into the fallback render color space (sRGB) for the overlapping portions of objects with transparency.

An implementation may determine the areas of an object to render in object's ICC color and those areas to render in its sRGB fallback by doing object intersection calculations as a pre-render step. An implementation could alternatviely decide render color choice on a pixel by pixel basis during rasterisation. Such behaviour is implementation specific and can lead to varying rendering results from different implementations at the borders of overlapping areas when using ICC colors.

5.3 Named color

SVG Print introduces the ability to use so-called 'named' or 'spot' colors. Named colors are used in many print applications and are supported in SVG Print through the use of ICC named color profiles.

5.3.1 Use of the ICC named color syntax

The paint specifiers for fill and stroke include the icc-named-color keyword. This may be used to look up colors by their name. For example in graphic arts workflows it is common to use PantoneÂ® color names for specifying paint on objects. The icc-named-color keyword may be used for such workflows.

5.3.2 ICC named color profile management

An SVG 1.2 file may specify ICC named color profiles via use of the color-profile element.

The ICC specification indicates that named color profiles must contain a PCS (Profile Connection Space) representation and can optionally contain a device representation for each named color. An implementation may support device representations of ICC named colors, however that support is device specific and should be managed outside of the SVG file itself by use of some form of job ticket information.

5.3.3 Example of named color usage

5.4 Device color specification

SVG 1.2 includes a number of features aimed at device specific color management. These features are intended for closed, non colormanaged workflows where the content generation tool would have specific knowledge of the press setup. The device specific functionality available via the deviceColor attribute is intended to support such closed workflows for better control of ink deposition on specific target devices.

5.4.1 Use of the deviceColor element

SVG Print introduces the deviceColor element as a further extension to allow the generation of device specific SVG Print files whilst supporting generic SVG viewer display by mandating all objects be specified with an appropriate sRGB fallback color. The deviceColor element removes the requirement for use of ICC profiles as an alternate color specifier.

5.4.2 Example of device specific color usage

The deviceColor element is used to specify device specific color information for the target device. It is used in conjunction with the device-color keyword when specifying object paint color.