Publishing and printing with SVG

For the SVG Open 2007 conference

Keywords: Printing , Publishing , SVG

Mr. Anthony Grasso
Software Engineer
Canon Information Systems Research Australia Pty. Ltd. and Canon Inc.
1 Thomas Holt Drive
North Ryde
NSW
Australia
anthony.grasso@cisra.canon.com.au

Biography

Anthony Grasso undertook a bachelor degree in Computer Systems Engineering at James Cook University in 1999 and graduated at the end of 2002 with honors. Over the past 4 years at Canon Information Systems Research Australia he has been involved in SVG and printing related projects. He is currently a Canon representative on the W3C SVG working group and is editing the SVG Print and Compositing specifications.


Abstract


SVG 1.2 Print contains features to support medium to high end quality page layouts for printing. These features will be of particular interest and importance to graphic artists, in the pre-press and transactional printing industry. Such users require ways to create template layouts that can accommodate variable data sizes, whilst producing sophisticated graphics.

The printing functionality of SVG has been under development for some time and now has a new Working Draft published. Adding printing functionality to SVG has made the specification more compatible with other Page Description Languages. As a result the SVG Print module can be used by authors and print vendors of various levels. This paper will provide use cases of SVG Print for the various users of the specification.

SVG Print currently supports pagination, allowing for multiple master pages to be specified for a set of pages. Pages can be styled using CSS or have their layout defined with XSL. The formatted pages can then be saved to an SVG Print document.

SVG Print expands the colors available to authors through its support for various color spaces such as linearRGB, LAB, and LCHAB. The color features allow printer specific colors to be used in a document and printed in the final output. A more linear transition between colors can be produced by performing the color interpolation in one of the extended color spaces.SVG Print extends SVG 1.2 Full, and as a result inherits the advanced features that exist in SVG 1.2 Full. These include text flow, vector effects, advanced compositing operations and filter effects.


Table of Contents


1. Introduction
2. Glossary
3. Printing Devices
     3.1 SVG Print Preview Device
     3.2 SVG Printing Device
     3.3 SVG Print Device
4. Dependent Specifications
5. Feature Support
     5.1 noPrint and requiredFeatures Attributes
     5.2 Prefetch Element
6. Pagination
     6.1 pageSet Element
     6.2 N-Up Printing
     6.3 Page Orientation Property
     6.4 masterPage Element
     6.5 Defaults
     6.6 Reusing Content and Scoping
7. Interoperabilitiy with XSL
     7.1 XSL and XSLT
     7.2 SVG and XSL Workflows
8. Color
     8.1 Color Definitions
     8.2 Input and Output Colors
     8.3 Intput Color Features
          8.3.1 ICC Color and Named Color Features
          8.3.2 Rending Intents
               8.3.2.1 Saturation Rendering Intent
               8.3.2.2 Perceptual Rendering Intent
               8.3.2.3 Relative and Absolute Colorimetric Rendering Intent
          8.3.3 Device Color Feature
          8.3.4 Fallback Color
     8.4 Color Interpolation Feature
9. Conclusion
Acknowledgements
Bibliography

1. Introduction

The SVG Full specification is very feature rich, providing the ability for artists to generate sophisticated content for web publishing. Features include basic shapes, customised SVG fonts and complex filter and compositing effects.

SVG Print further extends the graphical features of SVG Full 1.2 and Tiny 1.2 by providing alternative render color spaces, pagination, and XSL interoperability.

This paper will discuss the various features present in the SVG Print specification. An explanation of the features and examples of their use will be given.

2. Glossary

CMS - Color Management System

CMYK - Cyan Magenta Yellow Black

PDL - Page Description Language

PMS - PantoneTM Matching System

RGB - Red Green Blue

sRGB - Standard RGB

SVG - Scalable Vector Graphics

W3C - World Wide Web Consortium

XML - Extensible Markup Language

XSL - Extensible Stylesheet Language

XSLT - Extensible Stylesheet Language Transform

3. Printing Devices

The Print specification defines two Devices: An SVG Print Preview Device and an SVG Printing Device.

3.1 SVG Print Preview Device

An SVG Print Preview Device is a device for viewing the SVG Print content. This type of device will display to the author what the final output would look like. In some cases it may not be able to accurately reproduce the color that will be printed on a page. Reasons for this are discussed later in the Color features section of this paper. For conformance purposes the SVG Print specification refers to an SVG Print Preview Device as a User Agent for Print Preview.

3.2 SVG Printing Device

An SVG Printing Device is responsible for reproducing the SVG Print content onto a static physical medium such as paper. Typically there will be no direct interaction between the author and an SVG Printing Device. For conformance purposes the SVG Print specification refers to an SVG Printing Device as a User Agent for Printing.

3.3 SVG Print Device

An SVG Print Device is a term that can be used to describe either type of device or a device that performs both Printing and Display.

In typical printer architectures a Print Device will be called by the printer driver to render the document. The printer driver provides page size information, orientation and other information to the Print Device. The information is typically set either externally via a programmatic interface or a job control file. After the Print Device has rendered the job it is either printed or saved to a file. In some cases processing of the document may occur, either before the document is sent to the printer driver or later by the printer driver itself.

document-process.png

Figure 1: Document Processing Steps

4. Dependent Specifications

SVG Print is a simple specification based on SVG Tiny 1.2. SVG Print provides additional features to the base specification allowing content to be reproduced to a static medium. SVG Print cannot be used in isolation.

To print SVG 1.2 Tiny content SVG Print and SVG 1.2 Tiny are the only specifications required by an SVG Print Device. If a more extensive feature support is desired, vendors may opt to add other SVG 1.2 modules. This is illustrated in the following figure.

print-spec-dependencies-tiny.png

Figure 2: SVG Print dependencies when using SVG 1.2 Tiny

In the above figure the solid line indicates the minimum dependant specification required. The dashed lines indicate optional specifications.

To print SVG 1.2 Full an SVG Print Device must support SVG 1.2 Full and SVG Print. This is illustrated in the following figure.

print-spec-dependencies-full.png

Figure 3: SVG Print dependencies when using SVG 1.2 Full

In the above figure the solid line indicates the minimum dependant specification required.

5. Feature Support

The concept of reproducing animation and multimedia content to a static medium is problematic. SVG Print mandates an SVG Print Device not support scripting or animation. More specifically an SVG Print Device will only support the Static Profile of SVG Tiny 1.2. The list of static features is as follows:

5.1 noPrint and requiredFeatures Attributes

When a Print Device encounters animation or scripting it must use the unanimated values before the animation timeline start. Authors should take this into careful consideration when producing animation content that is to be printed. The animation may not convey its intended message or purpose when printed. Authors can make use of the requiredFeatures and switch attributes present in SVG Tiny 1.2 to specify different content to appear in place of an animation. This is shown in the following example:

        <?xml version="1.0" encoding="utf-8"?>
        <svg width="100%" height="100%" viewBox="0 0 800 600"
          xlmns="http://www.w3.org/2000/SVG"
          xmlns:xlink="http://www.w3.org/1999/xlink">

          <switch>
            <g requiredFeatures="http://www.w3.org/Graphics/SVG/feature/1.2/#SVG-animated">
              <circle cx="100" cy="100" r="10" fill="red">
                <animate attributeName="cx" to="200" begin="0s" dur="5s" />
                <animate attributeName="cy" to="200" begin="0s" dur="5s" />
              </circle>
            </g>
            <g>
              <circle cx="100" cy="100" r="10" fill="red" />
              <line x1="120" y1="120" x2="160" y2="160" stroke="blue" stroke-width="2" />
            </g>
          </switch>
        </svg>
      

As an alternative option authors can also specify the noPrint attribute on elements to remove any animation content being reproduced in an SVG Print document. The noPrint attribute affects the element it is placed on and all child elements. An SVG Print Device will treat the element as though display="none" was specified on the element. An example of its usage is shown below:

        <?xml version="1.0" encoding="utf-8"?>
        <svg width="100%" height="100%" viewBox="0 0 800 600"
          xlmns="http://www.w3.org/2000/SVG"
          xmlns:xlink="http://www.w3.org/1999/xlink">

          <rect x="10" y="10" width="40" height="40"  fill="blue" />

          <circle cx="100" cy="100" r="20" fill="red" noPrint="true">
            <animate attributeName="cx" to="200" begin="0s" dur="5s" />
            <animate attributeName="cy" to="200" begin="0s" dur="5s" />
          </circle>

        </svg>
      

5.2 Prefetch Element

Likely large raster images may be used in an SVG Print document. Authors should make use of the prefetch element where there are large raster images included for print. Although traditionally used in animation and multimedia, SVG Print Devices can employ this element as an indication to begin fetching the image for later use. Use of the prefetch element can help reduce time taken for printing SVG Print content.

        <?xml version="1.0" encoding="utf-8"?>
        <svg width="100%" height="100%" viewBox="0 0 800 600"
          xlmns="http://www.w3.org/2000/SVG"
          xmlns:xlink="http://www.w3.org/1999/xlink">

          <defs>
            <prefetch xlink:href="http://www.example.com/images/largeImage1.png" />
            <prefetch xlink:href="http://www.example.com/images/largeImage2.png" />
          </defs>

          <g>
            <!-- Process Other SVG content... -->
          </g>

          <switch>
            <g requiredFeatures="http://www.w3.org/Graphics/SVG/feature/1.2/#SVG-animated">
              <image x="0" y="0" width="400" height="300"
                xlink:href="http://www.example.com/images/largeImage1.png"
                display="none">

              <set attributeName="display" to="inline" begin="10s" />
              </image>

              <circle cx="100" cy="100" r="10">
                <animate attributeName="cx" to="200" begin="0s" dur="5s" />
                <animate attributeName="cy" to="200" begin="0s" dur="5s" />
              </circle>
            </g>
            <g>
              <image x="0" y="0" width="400" height="300"
                xlink:href="http://www.example.com/images/largeImage2.png" />

              <circle cx="100" cy="100" r="10" />
              <line x1="120" y1="120" x2="160" y2="160" stroke="blue"
                stroke-width="2" marker-end="url(#arrowhead)" />
            </g>
          </switch>
        </svg>
      

6. Pagination

SVG 1.2 Tiny does not explicitly provide pagination support. SVG Print provides authors with the ability to specify pages for SVG content. Unlike other PDLs (Page Description Language) SVG Print does not provide specific page dimensions and only limited page layout rules. This allows SVG to be interoperable with existing printing and layout languages. Page layout rules should be defined in separate job control files (for example JDF) or separate PDLs (for example XSL). Typically job control information extracted from a PDL or a job control file is forwarded on to the printer driver. A printer driver would be responsible for calling the SVG Device to interpret the SVG content. At this point the SVG Print Device will know the dimensions of the page and will thus know how to scale the content.

6.1 pageSet Element

The pageSet element signifies the start of the page separations in SVG Print. A single physical page in SVG Print is defined using the page element nested within a pageSet element. The page element defines the page separations in the final output. For example if an SVG Print document with pages were to be printed on paper without any page adjustment settings the page element would signify one page to one sheet of paper:

        <?xml version="1.0" encoding="utf-8"?>
        <svg width="100%" height="100%" viewBox="0 0 800 600"
          xlmns="http://www.w3.org/2000/SVG"
          xmlns:xlink="http://www.w3.org/1999/xlink">

          <!-- No page adjustment settings applied to document -->
          <pageSet>
            <!-- First sheet of paper -->
            <page>
              <circle cx="100" cy="100" r="20" fill="blue" />
            </page>

            <!-- Second sheet of paper -->
            <page>
              <rect x="100" y="100" width="20" height="20" fill="red" />
            </page>
          </pageSet>

        </svg>
      

6.2 N-Up Printing

The term N-Up printing is used when multiple defined pages are output onto a single physical page. The 'N' signifies the number of document pages to appear on a single physical page. It may be used when producing booklets and advertisement pamphlets. N-Up processing can occur in two different stages in a print system, at the document processing stage or in the printer drive at the time of printing.

n-up-processing-points.png

Figure 4: Stages where N-Up Processing can be performed

When N-Up printing is performed at the processing stage the settings are typically specified in a PDL (for example XSL). In this case a page element in SVG Print may contain content that represents 2 or more pages on a single physical page. When printed on paper a page element would signify one sheet of paper. The following is an example of SVG Print explicitly being used to layout pages for multiplex printing, specifically 2-Up.

        <?xml version="1.0" encoding="utf-8"?>
        <svg width="100%" height="100%" viewBox="0 0 1000 1000"
          xlmns="http://www.w3.org/2000/SVG"
          xmlns:xlink="http://www.w3.org/1999/xlink">

          <pageSet>
            <!-- First sheet of paper -->
            <page page-orientation="90">
              <!-- First page on left hand side of sheet -->
              <g transform="translate(0 0) scale(0.707)" >
                <circle cx="300" cy="300" r="200" fill="blue"/>
              </g>

              <!-- Second page on right hand side of sheet -->
              <g transform="translate(700 0) scale(0.707)" >
                <rect x="100" y="100" width="400" height="400" fill="red"/>
              </g>
            </page>

            <!-- Second sheet of paper -->
            <page page-orientation="90">
              <!-- First page on left hand side of sheet -->
              <g transform="translate(0 0) scale(0.707)" >
                <ellipse cx="450" cy="450" xr="100" ry="200" fill="green"/>
              </g>

              <!-- Second page on right hand side of sheet -->
              <g transform="translate(700 0) scale(0.707)" >
                <rect x="0" y="0" width="600" height="300" fill="yellow"/>
              </g>
            </page>
          </pageSet>

        </svg>
      

When N-Up layout is performed at the printer driver stage the settings would be specified by a job control file or via programmatic means to the driver. In this case a page element in SVG Print would contain content for one of the pages that would appear on the physical page. When printing on paper a 2 or more page elements would appear on one sheet of paper.

        <?xml version="1.0" encoding="utf-8"?>
        <svg width="100%" height="100%" viewBox="0 0 1000 1000"
          xlmns="http://www.w3.org/2000/SVG"
          xmlns:xlink="http://www.w3.org/1999/xlink">

          <!-- External settings specifying N-Up -->
          <pageSet>
            <!-- First sheet of paper -->
            <!-- First page on left hand side of sheet -->
            <page>
              <circle cx="450" cy="450" r="200" fill="blue" />
            </page>

            <!-- Second page on right hand side of sheet -->
            <page>
              <rect x="100" y="100" width="400" height="400" fill="red" />
            </page>


            <!-- Second sheet of paper -->
            <!-- First page on left hand side of sheet -->
            <page>
              <ellipse cx="450" cy="450" xr="100" ry="200" fill="green" />
            </page>

            <!-- Second page on right hand side of sheet -->
            <page>
              <rect x="100" y="100" width="600" height="300" fill="yellow" />
            </page>
          </pageSet>

        </svg>
      

Authors should be aware of the printer driver settings before performing N-Up processing on a document. It is possible to use both N-Up document processing and N-Up driver settings when printing. The combination of the two types of N-Up may result in slightly different output than if same N-Up processing had been performed in a single stage.

6.3 Page Orientation Property

The page-orientation property in SVG Print allows the author to specify the rotation of the page. It provides rotations in 90 degree increments in both positive and negative direction. This gives the author more options for page layout. Authors should keep in mind page-orientation in SVG Print is treated as a transform that is applied to the page.

When performing N-Up printing authors may get unexpected results if the page-orientation property is specified as well. If page settings are not specified at the printer driver stage then the page-orientation property will rotate the physical page output. If external PDL specifies a page orientation in addition to the SVG Print page-orientation , both page orientations will be applied.

6.4 masterPage Element

SVG Print allows for reusable page background and foreground content to be specified. This is done through the use of the masterPage element. Like the page element the masterPage element is a child of pageSet , but unlike the page element a masterPage element is not directly rendered. A Print Device will store the master page and apply it to every subsequent page that follows the master page. There are two types of master page in SVG Print: a Foreground Master Page and a Background Master Page. As each name suggests the Foreground Master Page will be rendered on top of each page and the Background Master Page will be rendered beneath each page. The master page type is determined by the rendering-order attribute. Set this attribute to "over" for a Foreground Master Page or to "under" for a Background Master Page. Both types of master page operate independently, however only one of each master page type can be used on a single page. If a new Background or Foreground Master Page is encountered then it will replace the current master page of that type.

6.5 Defaults

If a Background Master Page is not specified in a pageSet element then by default the Background Master Page will be any content rendered to the canvas that is specified before the pageSet element. By default there is no Foreground Master Page. If a masterPage element is specified without a rendering-order , by default it will be a value of "under" i.e. a Background Master Page.

        <?xml version="1.0" encoding="utf-8"?>
        <svg width="100%" height="100%" viewBox="0 0 800 600"
          xlmns="http://www.w3.org/2000/SVG"
          xmlns:xlink="http://www.w3.org/1999/xlink">

          <!-- Default master page content - Backgroud Master Page -->
          <text x="0" y="0" font-size="30">
            This master page will appear under the content of each Page
          </text>

          <pageSet>
            <page>
              <circle cx="450" cy="450" r="200" fill="blue" />
            </page>

            <page>
              <rect x="100" y="100" width="400" height="400" fill="red" />
            </page>
          </pageSet>

        </svg>
      

6.6 Reusing Content and Scoping

It common in a print scenario for master pages to look similar. In many cases it is expected that a single master page type will share common elements. For cases such as this it is recommended that authors use an external SVG file to share common graphics.

A defs elements inside a page element can only be reference by content in that page. Pages can not reference defs content from another page element. A page may reference defs content from either the preceding Background Master Page or the preceding Foreground Master Page. However when a master page is replaced by a new master page of the same type, preceding pages must no longer reference the old master page defs content.

If defs is declared before the pageSet it is considered to be a defs element for the first Background Master Page. When a new Background Master Page is encountered all defs declared before the pageSet are discarded.

        <?xml version="1.0" encoding="utf-8"?>
        <svg width="100%" height="100%" viewBox="0 0 800 600"
          xlmns="http://www.w3.org/2000/SVG"
          xmlns:xlink="http://www.w3.org/1999/xlink">

          <!-- DEFAULT BACKGROUND MASTER PAGE -->
          <defs>
            <!-- Default Background Master Page definitions -->
          </defs>

          <!-- Default Background Master Page graphics -->


          <pageSet>

            <!-- PAGE 1 -->
            <page>
              <defs>
                <!-- Definitions local to this page only -->
              </defs>
                <!-- Page Background: Default Background Master Page -->

                <!-- graphics for page 1 go here. -->

                <!-- Page Foreground: None -->
            </page>


            <!-- NEW BACKGROUND MASTER PAGE -->
            <masterPage xml:id="masterpage1">
              <!-- Replace Default Master Page graphics and definitions -->

              <defs>
                <!-- Definitions can be referenced by pages 2 and 3 -->
              </defs>

              <!-- Graphics here will be in the background for pages 2 and 3 -->
            </masterPage>


            <!-- PAGE 2 -->
            <page>
              <!-- Page Background: masterpage1 -->

              <!-- Graphics for page 2 -->

              <!-- Page Foreground: None -->
            </page>


            <!-- NEW FOREGROUND MASTER PAGE -->
            <masterPage xml:id="masterpage2" rendering-order="over">
              <defs>
                <!-- Definitions can be referenced by page 3 onwards -->
              </defs>

              <!-- Graphics here will be in the foreground for pages 3 onwards -->
            </masterPage>


            <!-- PAGE 3 -->
            <page>
              <!-- Page Background: masterpage1 -->

              <!-- Graphics for page 3 -->

              <!-- Page Foreground: masterpage2 -->
            </page>


            <!-- NEW BACKGROUND MASTER PAGE -->
            <masterPage xml:id="masterpage3" rendering-order="under">
              <!-- Replace masterpage1 graphics and definitions -->

              <defs>
                <!-- Definitions can be referenced by pages 4 onwards -->
              </defs>

              <!-- Graphics here will be in the background for 4 onwards -->
            </masterPage>


            <!-- PAGE 4 -->
            <page>
              <!-- Page Background: masterpage3 -->

              <!-- Graphics for page 4 -->

              <!-- Page Foreground: masterpage2 -->
            </page>

          </pageSet>

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

7. Interoperabilitiy with XSL

Unlike other PDLs SVG Print does not contain strict page region and layout rules. It has been deliberately designed this way because specific layout settings are handled at a higher level by other XML languages.

SVG Print contains functionality to operate as a stand alone PDL, but when combined with other XML languages in a workflow it can be become a very powerful graphics language for high end printing.

7.1 XSL and XSLT

XSL and XSLT are both W3C recommendations. XSL is an acronym for Extensible Stylesheet Language Formatting Objects. As the name suggests it describes the formatting of XML data for output to screen or other physical media. It gives authors the means to describe high end print layouts by features to specify dimensions for pages, lists, tables, margins, borders, and trim boxes. External graphics such as SVG can be referenced by XSL.

XSLT is an acronym for Extensible Stylesheet Language Transformations. An XSL Transform provides a means to convert an XML document from one type to another by specifying the transformation rules for elements in the XML document. With XSLT an author can select elements to convert, rearrange the XML structure, sort elements and much more. A typical use of XSLT is converting an XML DocBook document into a XHTML document.

Combining the two standards allows authors to construct a transform that applies XSL layout styling to XML documents.

7.2 SVG and XSL Workflows

The design of SVG and SVG Print allows interoperability with print workflows containing XSL and XSLT. With reference to the figure below, one such print workflow would start with an XML document containing SVG graphics. For example this could be a DocBook or an XHTML page. The XML document would be accompanied by an associated XSL Transform. Both the XML document and XSL Transform would be passed to an XML Editor or XSLT processor which transforms the document to produce a resultant XSL Document that references external SVG Graphics. The resultant XSL Document is then passed to the printer driver for printing.

svg-xsl-workflow-low-end.png

Figure 5: SVG and XSL for medium to low end workflows

As illustrated in the above figure the Printer Driver/Printer is required to contain an SVG Print Device and an XSL Format Engine. When a reference to an external SVG Graphic is encountered in the XSL document the SVG Print Device would be called to render the graphic. This workflow is simple and would be typical for low to medium end printing. Due to the workflow simplicity advanced page layout is limited. Advanced page layout could be performed when the XML Document is transformed to the XSL document. The disadvantage is that unwanted results with page flowing could occur. Other advanced operations such as N-Up printing could only be set using the Printer Driver. Another disadvantage is that the Printer Driver/Printer requires more overhead as it needs to support an XSL Format Engine to perform the printing. The XSL Format Engine needs to call the SVG Print Device at the time of print for rasterizing any SVG graphics. This method may be slow in comparison to other printing systems.

Given the limitations in the above approach a flexible workflow would be required for medium to high end printing. The above SVG + XSL workflow could be extended to cater for the medium to high end printing market. With reference to the figure below, the workflow would start with an XML document containing SVG graphics. As per the previous workflow example, the XML Document may contain SVG Graphics and would be accompanied by an associated XSL Transform. Both the XML document and XSL Transform would be passed to an XML Editor or XSLT processor which transforms the document to produce a resultant XSL document that references to external SVG Graphics. The resultant XSL Document could then be passed to a Page Layout Editor to perform pagination and other layout operations on the document. The Page Layout Editor would typically convert the XSL Document to an in memory tree representation of the document. Advanced operations such as N-Up printing can be performed at this point. Other options such as crop markings can be set in the editor to output on a page. The Page Layout Editor could then output an SVG Print Document as the final output to be sent to the Printer Driver/Printer.

svg-xsl-workflow-high-end.png

Figure 6: SVG and XSL for medium to high end workflows

In the above workflow system the Page Layout Editor may be required to send page information to the Printer Driver. The information could include page size, print medium, etc. Such information could also be manually specified at the Printer Driver or be contained in Job Control file. The above workflow does simplify the Printer Driver/Printer at the expense of increased complexity in the Page Layout Editor. The Page Layout Editor would require a plug-in or native support for SVG Print to output the final document to print.

8. Color

SVG Print extends the number of options available for specifying color. Only a brief introduction to color will be given in this section as color is a very extensive and complicated subject.

8.1 Color Definitions

A color space is defined by a color model and a range of colors commonly refered to a gamut. The color model of a color space is an abstract mathematical model that defines the representation of visible colors as a vector. Typically, colors in a color model will be represented as three or four values.

The gamut defines a subset of colors that are available for use in a given circumstance. A single color model can be associated with different gamuts to give a variety of color spaces. The RGB color model, which specifies each color as a combination of Red, Green and Blue, is one such an example. The figure below illustrates that many different RGB color spaces exist, these include sRGB (Standard RGB) and Adobe RGB. Each of these RGB color spaces has a distinctive gamut.

RGB-examples.png

Figure 7: RGB Color Spaces

Color spaces can either be device dependent or device independent. Device dependent color spaces, express color relative to another color space. An imaging device will have an associated gamut. Hence, a device dependent color space describes the colors that

Device dependent color spaces are generally defined by measurements of the output or input colors generated or detected by a particular device.

Device Independent color spaces express color in absolute terms. In most cases a device independent color space will have a larger gamut than device (device dependent) color spaces. This is because the gamut of device independent color spaces is not restricted by the characteristics of a physical device. Device independent color spaces tend to require more data to store the values for colors due to their greater resolution in values across a larger gamut.

Examples of colors spaces are:

Note that the color spaces marked with '*' are supported in the color-interpolation property in SVG Print.

8.2 Input and Output Colors

Colors can either be classified as input or output. Input colors are typically given by a raster image, PDL or via an input device. Output colors are typically shown by an output device such as a monitor or printer. A typical problem is printing an image captured by a scanner. It is common for colors in the image captured by the scanner to be unreproducible by the printer. For this reason the input colors (in this case the colors in the image), need to be translated to output colors that the printer can produce. The image captured by the scanner would be in an RGB color space and the output reproduced by the printer would be a CMYK color space. Note that the Input Color Space of the Scanner and the Output Color Space of the Printer are both device dependent color spaces.

color-translation.png

Figure 8: Typical color translation problem when scanning an image then reproducing it on a printer

For an Input or Output color to be meaningful the color will be associated with a color space defined by ICC profile. ICC profiles allow colors to be translated between color spaces whilst attempting to maintain color accuracy. Typically a color will not be translated directly from the input color space to the output color space. The color translation will be via a common color space known as a Profile Connection Space. A profile connection space will be device independent and in most cases be able to represent colors in both the intput and output color spaces.

An input ICC color profile will specify how to translate colors from the input color space to a Profile Connection Space. An output ICC color profile will specify how to translate colors from a Profile Connection Space to the output color space.

In order to translate colors between the different color spaces, a color management system (CMS) is typically used. The CMS performs all calculations needed to translate colors from one color space into another. When a color is translated the following process takes place: The input color is translated by the CMS from the Input Colors Space to the Profile Connection Space. The color is then translated from the Profile Connection Space by the CMS to the Output Color Space.

color-translation-general.png

Figure 9: General steps when translating a color

For an image captured by a scanner to be printed the colors in the image would have to under go the following translation steps. The CMS would translate the colors in the image from the sRGB Input Color Space to the CIE-XYZ Profile Connection Space. The CMS would then translate the colors from the CIE-XYZ Profile Connection Space to the printer’s CMYK Output Color Space.

color-translation-sepecific.png

Figure 10: General steps when translating the colors of a scanned image to be reproduced by a printer.

8.3 Intput Color Features

SVG Print allows a variety of input colors from different color spaces to be specified for painting an object. Authors can choose "icc-color" , "icc-named-color" or "device-color" values as input colors.

8.3.1 ICC Color and Named Color Features

Input colors from any color space can be specified with "icc-color" or "icc-named-color" values. An ICC profile is required to describe the color space of the input color. The color profile can be provided in SVG using the color-profile element.

When an "icc-color" or "icc-named-color" value is used for paint the author must reference the name attribute of the color-profile element that describes the input color space. Additionally the author will need to specify the color values. An example of the "icc-color" , "icc-named-color" values and color-profile element usage is shown below:

          <?xml version="1.0" encoding="utf-8"?>
          <svg width="100%" height="100%" viewBox="0 0 800 600"
            xlmns="http://www.w3.org/2000/SVG"
            xmlns:xlink="http://www.w3.org/1999/xlink">

            <defs>
              <color-profile name="labProfile" xlink:href="lab.icc" />

              <color-profile name="namedColorProfile" xlink:href="namedColor.icc" />
            </defs>

            <rect width="100" height="100" x="40" y="40"
              fill="red, icc-color(labProfile, 0.85, 0.1, 0.1)" />

            <rect width="100" height="100" x="70" y="70"
              fill="yellow, icc-named-color(namedColorProfile, company_color)" />
          </svg>
        

The "icc-color" value allows authors to specify the exact values of a color in a color space defined by the color-profile . The "icc-named-color" value allows authors to specify the name of a color in a color space defined by the color-profile . Named colors are more versatile than specifying ICC color values as the output device may be able to reproduce the named color directly. This avoids translation of the color. Specifying a named color allows other devices that are unable to reproduce the color directly to simulate the color. Pantone™ colors are one such example of named colors. The PantoneTM color inks can be directly used in a printer or the CMYK inks in the printer can be used to simulate the PantoneTM color. In either case only a single PantoneTM color name needs to be specified to produce the color, for example PMS 1795 (PantoneTM Matching System 1795).

8.3.2 Rending Intents

Typically "icc-color" and "icc-named-color" values will require translation to another color space. Authors may wish to specify the rendering intent to apply when translating colors from the input to the output color space. Rendering intent is specified using the rendering-intent attribute. The options available are "auto" , "saturation" , "perceptual" "relative-colorimetric" , and "absolute-colorimetric" . Rendering intents specify the way colors are translated between color spaces. By default if a rendering-intent is not specified it is set to "auto" . The rendering intent used when translating colors can produce noticeable color differences. It is recommended that authors take particular care when specifying the rendering intent.

To illustrate the various differences that rendering intents can produce consider the two gamuts in the following figure:

gamut-example.png

Figure 11: Example of two gamuts

Gamut 1 (input color space gamut) is bigger than Gamut 2 (output color space gamut). Gamut 1 contains three colors that are outside of Gamut 2, i.e. cannot be meaningfully represented in Gamut 2. These colors are known as out of gamut colors. Although the gamuts used in the above figure do not exist, the scenario given is typical for printing a PDL. In many cases a PDL will specify input colors that are required to go through some translation to be printed. The descriptions of each of the following rendering intents will refer back to a snap shot of the above figure.

8.3.2.1 Saturation Rendering Intent

Saturation is a less commonly used intent. As illustrated in the following figure, out of gamut colors are translated to the closest color that falls inside the gamut. In this example all three out of gamut colors happen to map to the same color. The saturation intent also moves in gamut colors towards the edge of the destination gamut. Colors tend to be saturated when this intent is applied for color translation. The saturation intent is useful for graphics, artwork, or improving weak images.

saturation-example.png

Figure 12: Saturation Rendering Intent

8.3.2.2 Perceptual Rendering Intent

Perceptual intent specifies that colors are translated in proportion to one another. When perceptual intent is used, the in gamut colors are translated such that out of gamut colors can be moved into the smaller gamut. As illustrated in the following figure the three colors that fall inside Gamut 2 are translated in proportion with each other more to the white point. The colors that fall outside of Gamut 2 are also translated in proportion with each other into Gamut 2. Since the relative distance of all colors is maintained it is difficult for a viewer to determine that the colors have been adjusted. This intent is commonly used when working with natural images and every day printing.

perceptual-example.png

Figure 13: Perceptual Rendering Intent

8.3.2.3 Relative and Absolute Colorimetric Rendering Intent

Both colorimetric intents (relative and absolute) behave in a similar way to saturation intents. Colors that fall out of the gamut are translated to the closest color that falls in gamut. As illustrated in the following figure, the three out of gamut colors are translated to the closest color that falls in gamut. Unlike the saturation intent colors that are inside the gamut are not translated to new positions inside the gamut. The disproportionate translation between colors tends to produce noticeable changes in colors. If translating between a large gamut color space to a small gamut color space, the colorimetric intent can produce undesirable color output. Colorimetric intents are more suited for translating colors between color spaces that have gamuts of similar size or preserving the color of a logo.

colorimetric-example.png

Figure 14: Colorimetric Rendering Intent

The difference between Relative and Absolute Colorimetric intent is the white point used for the gamut. Relative Colorimetric uses the white point defined in the output color profile, for example the white point of the paper for a printer. Absolute Colorimetric uses the white point defined in input color profile. Typically the white point of the input color space will be different to white point of the output color space. When printing, Relative Colorimetric intent will adjust the colors to the white point of the paper. The Absolute Colorimetric intent will not adjust the colors and hence may not produce the desired output when printing. If Colorimetric intents are used, authors should consider using Absolute Colorimetric for print preview and Relative Colorimetric for printing to paper.

8.3.3 Device Color Feature

The Device Color feature in SVG Print allows authors to specify exact data to reproduce a color on a specific device. A device color is unique to a specific device. This means the format that the device color is specified in will only be meaningful to a specific device. Unlike ICC colors and ICC Named colors Device colors contain no profile that describes color space of the color. Thus, a device color cannot be translated to another color space if unrecognized by a device.

When the "device-color" value is used to specify a fill it will need to reference a deviceColor element. The deviceColor element is device specific and hence will contain attributes and data in a namespace only recognized by the target device.

A use case for device color is a printer containing a special metallic ink color in addition to the printer's regular process inks. An author could use the "device-color" value to select the metallic ink as a fill color of an object in an SVG Print document.

          <?xml version="1.0" standalone="no"?>
          <svg width="100%" height="100%" viewBox="0 0 800 600"
            xlmns="http://www.w3.org/2000/SVG"
            xmlns:xlink="http://www.w3.org/1999/xlink"
            xmlns:special="http://www.example.com/ink/special"
            xmlns:hexachrome="http://www.example.com/ink/hexachrome"
            xmlns:spot="http://www.example.com/ink/spot" >

            <defs>
              <deviceColor name="metallicInk"
                xmlns:special="http://www.example.com/ink/special"
                special:value="Cyan, Magenta, Yellow, Black, Metallic" />

              <deviceColor name="processInks"
                xmlns:hexachrome="http://www.example.com/ink/hexachrome"
                hexachrome:valueCount="6"
                hexachrome:value="Cyan, Magenta, Yellow, Black, Orange, Green" />

              <deviceColor name="spotInk"
                xmlns:spot="http://www.example.com/ink/spot"
                spot:value="namedColor" />

              <color-profile name="cmykProfile" xlink:href="cmyk.icc" />

              <color-profile name="namedColorProfile" xlink:href="namedColor.icc" />

            </defs>

            <rect width="100" height="100" x="0" y="0"
              fill="silver, icc-color(cmykProfile, 0.8, 0.17, 0.1, 0.2),
              device-color(metallicInk, 0, 0, 0, 0, 100)" />

            <rect width="100" height="100" x="100" y="0"
              fill="steelblue, icc-color(cmykProfile, 0.8, 0.17, 0.1, 0.2),
              device-color(processInks, 70, 20, 10, 10, 0, 10)" />

            <rect width="100" height="100" x="100" y="100"
              fill="red, icc-named-color(namedColorProfile, RichRed),
              device-color(spotInk, Red1306)" />
          </svg>
        

8.3.4 Fallback Color

If paint is specified using an "icc-color" or "icc-named-color" value it is strongly recommended that authors also specify an sRGB fallback equivalent color as well. If a fallback color is not specified the value of the color will be treated as none . It is good practice to specify a fallback color as there could be cases where the ICC color profile cannot be loaded or the color cannot be translated.

If paint is specified using the "device-color" value it is strongly recommended that authors also specify an sRGB equivalent fallback color at least. Specifying an ICC equivalent fallback color in addition to the sRGB color is also recommended. There may be cases where a "device-color" is unavailable and could be better simulated with an ICC color than the sRGB color.

8.4 Color Interpolation Feature

SVG Print provides a color-interpolation property. This gives authors the ability to specify the interpolation color space when objects are composited together or when interpolating between color stops in a gradient. The values available for color-interpolation are: "auto" , "sRGB" , "linearRGB" , "CIE-Lab" and "CIE-LCHab" . By default the color-interpolation is set to sRGB. Note that linearRGB interpolation uses sRGB interpolation with a linear transfer function. The color-interpolation feature when used can produce different and more visually appealing results.

With reference to the following example the color-interpolation property is assigned to the group containing the red and blue rects. The colors within the group are composited in the linearRGB color space. The resultant is then composited with the rect containing the blue fill. This example also shows the color-interpolation property applied to a gradient. The transition between the colors for this gradient will occur in linearRGB.

        <?xml version="1.0" standalone="no"?>
        <svg xlmns="http://www.w3.org/2000/SVG"
            width="100%" height="100%" viewBox="0 0 800 600">

          <defs>
            <!-- Gradient will be inerpolated in linearRGB -->
            <linearGradient id="linearRGBGradient" color-interpolation="linearRGB"
              gradientUnits="objectBoundingBox">

              <stop offset="0.1" stop-color="red"/>
              <stop offset="0.9" stop-color="green"/>
            </linearGradient>
          </defs>

          <rect width="100" height="100" x="10" y="10" fill="blue" />

          <!-- Objects composited in linearRGB -->
          <g color-interpolation="linearRGB">
            <rect width="100" height="100" x="40" y="40"
             fill="red" fill-opacity="0.7" />

            <rect width="100" height="100" x="70" y="70"
             fill="yellow" fill-opacity="0.7" />
          </g>

          <!-- Fill is linearRGB Gradient-->
          <g enable-background="new">
            <rect fill="url(#linearRGBGradient)" width="200" height="50" x="10" y="200"/>
          </g>
        </svg>
    

Note that in the above example the rectangle containing linearRGB gradient fill is inside a group with the enable-background property set to "new" . This is instructs the SVG Print Device to perform the interpolation between the gradient stops in a separate buffer. The separate buffer will be in the linearRGB interpolation color space.

The differences that linearRGB color-interpolation can have on the final output are shown in the following figure. In the figure the objecst on the left are interpolated in linearRGB and the objects on the right are interpolated in sRGB.

paint-fill-composit.png

Figure 15: Differences in output when a Color Interpolation is applied

9. Conclusion

The design of SVG Print pagination features gives it the flexibility to integrate into a variety of levels of print workflows. Different page layout languages such as XSL can use SVG Print at different stages of a workflow. This flexibility of SVG Print makes it ideal for PDL graphics.

The advanced color features in SVG Print provide the author with control over the color reproduction of the document. This allows SVG Print documents to be accurately reproduced when sent to different output devices.

The ability of SVG Print to operate with XSL and the advanced color features of SVG Print makes it an excellent option for high end print workflows.

Acknowledgements

Thank you to my work colleges who helped with the input and review of this paper. In particular Tim Morris-Yates, Brian Davies, Colin Newell, Andrew Shellshear and Rodney Hardy. Thank you to my close friends, David Luu and Veronica Luke for their support during the writing of this paper. Lastly a big thank you to my beautiful girlfriend Mai Huong Ha for her support during the writing of this paper.

Bibliography

[W1]
SVG Print Specification, Primer, W3C Working Draft http://www.w3.org/TR/2007/WD-SVGPrintPrimer12-20070501/
[W2]
SVG Print Specification, Language, W3C Working Draft http://www.w3.org/TR/SVGPrint/
[W3]
Extensible Stylesheet Language Specification 1.1 http://www.w3.org/TR/xsl/
[W4]
Extensible Stylesheet Language Transformations Specification 1.0 http://www.w3.org/TR/xslt
[W5]
Wikipedia color space article http://en.wikipedia.org/wiki/Color_space
[P1]
Understanding Compositing and Color extensions in SVG 1.2 in 30 minutes, Craig Northway, August 2005 http://www.svgopen.org/2005/papers/abstractsvgopen/index.html
[P2]
Understanding rendering intents: Which one and why?, John Nate, March 2004 http://www.newsandtech.com/issues/2004/03-04/pt/03-04_rendering.htm

XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.