SVG Print 1.2, Part 1: Primer
W3C Working Draft
Copyright © 2004-2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
Copyright © 2004-2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
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.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This document is an editors draft. It defines features of SVG specific to printing. It is a draft in progress; some descriptions in this document may be incomplete. This document shows the current thoughts of the SVG Working Group on the use of SVG for printing and should not yet be considered stable. There is an accompanying SVG Print 1.2, Part 2: Language that defines conformance criteria , new and reintroduced language features for SVG Printing.
This document has been produced by the W3C SVG Working Group as part of the W3C Graphics Activity within the Interaction Domain. The Working Group expects to advance this Working Draft to Recommendation Status.
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. 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.
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.
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.
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.
TODO: The above terms will probably be replaced as follows:
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.
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.
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.
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.
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.
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.
It is not currently possible to reference an entire SVG Print document from another SVG Print document.
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?
TODO: Add an example of how to use this feature.
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.
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.
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.
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.
SVG Print devices do not support animation or 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.
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.
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.
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.
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.
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.
Detailed information about JDF may be found at http://www.cip4.org.
The Internet Printing Protocol (IPP) is a standard under development by the Printer Working Group (PWG) inside the Institute of Electrical and Electronics Engineers (IEEE).
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.
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.
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.
--MultiplexBoundary==
Content-Type: image/svg+xml
<svg width="100%" height="100%">
<text x="0%" y="10%">
Nice image below:
</text>
--MultiplexBoundary==
Content-Type: image/jpeg; name="eye.jpg"
Content-Transfer-Encoding: base64
Content-Id: <foo>
/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof
Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR
CAAKAAsDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDy06JGul2bJfq+qTTvHJaoMi3jX5d0jdmL
dAOwzmkur+4srl7a2keWKM4V1TIP45ra8aEt4wVCSVbbuB6Hg9a2Y9PshEn+iQfdH/LMelcd
Wavsd1Gk2rpn/9k=
--MultiplexBoundary==
Content-Type: image/svg+xml
<image x="0%" y="15%" width="5%" height="5%" xlink:href="cid:foo" />
</svg>
--MultiplexBoundary==
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.
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:
<circle cx="200" cy="135" r="20" fill="#3b3"/> <circle cx="240" cy="135" r="20" fill="#33bb33"/> <circle cx="200" cy="175" r="20" fill="rgb(51,187,51)"/> <circle cx="240" cy="175" r="20" fill="rgb(20%,73.333%,20%)"/>
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.
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.
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.
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.
<svg width="210mm" height="297mm"
xmlns="http://www.w3.org/2000/svg" version="1.2" referenceDirection="backwards">
<pageSet>
<page>
<color-profile name="MyColors"
xlink:href="CompanyColors.icm"/>
<text x="50mm" y="85mm"
font-family="MyCompanyLogoFont" font-size="12"
color="rgb(255,12,13) icc-named-color(MyColors, logo_color)">
MyCompany logo.
</text>
</page>
</pageSet>
</svg>
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.
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.
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.
The following example illustrates the use of deviceColor.
<svg xmlns="http://www.w3.org/2000/svg" version="1.2"
xmlns:xlink="http://www.w3.org/1999/xlink" >
<defs>
<!-- describe a particular output device, the components happen to be
Cyan, Magenta, Yellow, Black, Silver, Gray, Green -->
<deviceColor name="device-inks"
xlink:href="http://www.example.com/pressInks"
numComponents="6" />
</defs>
<text x="100" y="150" font-family="Verdana" font-size="35"
fill="rgb(22,33,44) device-color(device-inks, 11,55,66,77,0,0,88)" >
Hello humans, we come in peace.
</text>
</svg>