Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This Working Draft specifies use of the Scalable Vector Graphics (SVG) Language for printing environments.
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 the first public working draft of this specification. It lists the use of SVG for printing. In most cases, the descriptions in this document are incomplete and simply show the current thoughts of the SVG Working Group on the use of SVG for printing. This document should in no way be considered stable.
This document has been produced by the W3C SVG Working Group as part of the W3C Graphics Activity within the Interaction Domain.
We explicitly invite comments on this specification. 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.
The latest information regarding patent disclosures related to this document is available on the Web. As of this publication, the SVG Working Group are not aware of any royalty-bearing patents they believe to be essential to SVG.
Publication of this document does not imply endorsement by the W3C membership. A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/. W3C publications may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite a W3C Working Draft as anything other than a work in progress."
This draft of SVG Print is a snapshot of a work-in-progress. The SVG Working Group believe the most of the features here are complete and stable enough for implementors to begin work and provide feedback. Some features already have multiple implementations.
This is not a specification of a separate profile of SVG called SVG Print. Instead, SVG Print is a guideline on how to use SVG 1.2 features for printing. In many cases the reader will have to be familiar with the SVG 1.2 language.
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 include some kind of keyword that identifies the area of the specification the comment is referring to in the subject line of your message (e.g "Print compositing" or "Print render formats"). If you have comments on multiple areas of this document, then it is probably best to split those comments into multiple messages.
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. There is also a specific area related to the specification that is listed here:
SVG was originally developed as a graphics standard targeting web pages. As such, it has evolved a number of rich graphics features which have applicability in a number of target areas. During development of SVG versions 1.0 and 1.1, the primary focus of the standards development process revolved around screen based devices such as PCs, PDA's and cell-phones.
During development of SVG 1.1 and 1.2, the needs of the print community were addressed to promote features and usage of SVG for print environments.
The purpose of this document is to enumerate the ways in which SVG files can be used for printing. All SVG files should be printable on a suitable SVG Print device. Specific functionality to help printing has been introduced into SVG 1.2. This additional functionality is general purpose, being suitable for uses other than printing, such as for example, slide shows.
SVG Print formalises what an SVG Print device should do in regard to printing an SVG 1.0 file. An SVG Print device implementing SVG 1.0 should print a single page representing the image file. The scaling of the file to the print page should follow the guidelines in the SVG 1.0 specification with regard to scaling and/or clipping the resultant image.
In all cases, one SVG 1.0 file will produce one page. Vendors are free to implement job control extensions which would allow tiling of a large SVG 1.0 image across multiple pages, however this is to be considered a vendor extension and does not form a part of SVG Print itself.
When printing an SVG 1.0 file, units such as 'px' from CSS should be appropriately scaled to provide consistent results between screen and printer. Similarly, SVG Print devices are expected to scale images in such a manner as to provide a direct size mapping between screen and printer resolution.
SVG 1.1 introduced a modularisation of SVG into three profile levels. Those levels are Tiny, Basic and Full.
An SVG Print device may implement any profile level of SVG. Thus, an SVG Print device targeting small devices such as cell-phones may implement SVG Tiny and be a conformant SVG Print device. In order to be considered an SVG Print device, the behaviours described in this document must be implemented.
A printer implementing SVG Tiny is considered to be an SVG Tiny Print device. Similarly, implementation of SVG Basic would be considered to be an SVG Basic Print device, and so forth.
Note, that an SVG Tiny Print device would be incapable of rendering all SVG 1.0 content. This limitation is identical to that inherent in other SVG Tiny devices.
SVG 1.2 introduced a number of additions which have applicability to SVG Print. These include the pageSet and page elements and the streamable attribute on the outermost SVG element.
All SVG Print devices must support the functionality developed for SVG 1.2 at their respective profile levels. For example, an SVG Tiny Print device would be required to support the page element.
SVG Print documents may be structured to facilitate printing. In particular, it is possible to construct content that is shared across multiple pages. SVG Print uses a scoping mechanism introduced in SVG 1.2 (via the page element) in order to manage resources in a resource-limited device. Similarly, the streamable attribute may be used to manage resources.
The page element is used to delimit 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 if, and only if the SVG file contains content which marks the image canvas.
The page element introduces a scoping mechanism not present in versions of SVG prior to 1.2. This scoping mechanism effectively isolates the content between page elements.
For example, 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. This also provides a simple mechanism to print page ranges by skipping content between page elements until the desired page range is reached.
Note, it is possible that an SVG Print document references an external document containing page elements itself. If this document is referenced at the outermost scope level, then each referenced page will be printed on a separate page. If such a document is referenced from within a page element of the parent document, it is an error and the printed result of such a referenced document is implementation dependent.
The working group has discussed the possibility of adding x, y, width and height attributes to the page element. Those attributes would serve to establish a new viewport for the enclosed page. The behaviour of the new viewport would be analogous to introducing a nested svg element in existing SVG content.
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.
The working group has discussed the possibility of scoping CSS usage in combination with page scoping. Two scenarios have been identified - firstly; multiple existing SVG image files are concatenated into a single multi-page file for printing and secondly; a user wishes to print a subset of all the pages in a multi-page SVG document. Both these use cases would be helped by some form of scoping mechanism for CSS. In the first case, there could be a clash of style rules between the original SVG images that were concatenated. In the second case it would be more efficient to skip all content between enclosing page elements until the desired page range for printing is reached.
One possible solution would be to say that as the page element controls scoping, any CSS styles introduced within a page element apply only to the content within that page element.
Another possible solution would be to imply that some form of XSLT type transformation is performed on the SVG file, once per page, where the defined content for each printed page consists of the global data and the page data for the page currently being printed. The CSS cascade would then be applied to the result of the transformation, once per page.
No solution has been proposed yet, this is an item under active discussion.
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.
In an SVG Print document, all content which is within the outermost svg element and outside of any enclosing page element has global scope. Thus it is displayed on all pages following the content.
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. Similarly, if that rectangle appeared in the document after the first page element, it would be present on all subsequent pages.
This scoping of global and page-specific content allows for the provision of a so-called 'master-page' facility.
SVG 1.2 introduced a streamable attribute on the outermost svg element. This may be set to 'true' or 'false'.
A setting of 'true' indicates that the SVG file has been authored to facilitate progressive rendering. This implies that there are no forward references (via the use element) inside the file. Thus, the appearance of a use element indicates that the resource must be available for rendering. If the resource is undefined at a given point in the document, it is treated as a non-existent resource, i.e. no buffering of SVG document content is required.
If the streamable attribute is set to 'false', the document may need to be buffered in its entirety in order to resolve any forward use references.
Note, that legacy content which lacks any streamable attribute, must be treated as if streamable is set to 'false'. Documents lacking a streamable attribute may reference any other part of the document, and therefore may need to be buffered.
Documents authored for SVG Print application should generate and set the outermost svg element attribute streamable to 'true'.
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 ignored.
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 width="2000" height="2000" viewBox="0 0 2000 2000"
xmlns="http://www.w3.org/2000/svg" version="1.2" streamable="true">
<pageSet>
<page>
<circle cx="300" cy="150" r="90" fill="red" stroke="black"
stroke-width="4" fill-opacity="0.7" />
</page>
<page>
<circle cx="240" cy="250" r="90" fill="green" stroke="black"
stroke-width="4" fill-opacity="0.7" />
</page>
<page>
<circle cx="360" cy="250" r="90" fill="blue" stroke="black"
stroke-width="4" fill-opacity="0.7" />
</page>
</pageSet>
</svg>
<svg width="1000" height="1000" viewBox="0 0 1000 1000"
xmlns="http://www.w3.org/2000/svg" version="1.2" streamable="true">
<text x="50" y="50"
font-family="Verdana" font-size="36" fill="blue" >
Should appear on all pages
</text>
<circle cx="200" cy="150" r="90" fill="blue" stroke="black"
stroke-width="4" fill-opacity="0.7" />
<pageSet>
<page>
<circle cx="300" cy="150" r="90" fill="red" stroke="black"
stroke-width="4" fill-opacity="0.7" />
<text x="50" y="850"
font-family="Verdana" font-size="36" fill="blue" >
Should appear on first page
</text>
</page>
<page>
<circle cx="240" cy="250" r="90" fill="green" stroke="black"
stroke-width="4" fill-opacity="0.7" />
<text x="50" y="850"
font-family="Verdana" font-size="36" fill="blue" >
Should appear on second page. Another Circle.
</text>
</page>
<page>
<circle cx="360" cy="250" r="90" fill="blue" stroke="black"
stroke-width="4" fill-opacity="0.7" />
<text x="50" y="850"
font-family="Verdana" font-size="36" fill="blue" >
Should appear on third page. Last Circle
</text>
</page>
</pageSet>
</svg>
SVG Print does not mandate any job control standard. In the absence of job control information, an SVG Print device will choose paper sizes according to the next section.
It is expected vendors will implement SVG Print devices using some form of job control. The exact configuration of such devices is implementation specific. This document enumerates a number of possibilities and suggested behaviour only.
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.
It is recommended that an SVG Print document sent to an SVG Print device in the absence of any device specific job control information be printed according to the behaviour described in this document. This is analogous to plain text data being sent directly to a line printer terminated by a form-feed character.
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 scenarios. This section is informative and does not imply any requirement to use such standards.
Job Definition Format (JDF) is managed by CIP4 (*put in reference). 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 (reference).
Detailed information about JDF may be found at http://www.cip4.org.
This section description was unavailable at time of publication.
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==
When sending an SVG Print document to a printer device, it is desirable to select an appropriate sized paper source for printing. In the absence of any device specific job control information, an SVG Print device will choose a paper size according to a defined set of criteria.
The outermost svg element can contain width and height attributes. These attributes can specify sizes in a number of different units. These units can be absolute sizes, or percentages of the document viewport.
The size specified on the outermost svg element applies to all pages in the SVG Print document. If different sized pages are required for a given print job, then job control in combination with multiple SVG Print files must be used.
The decision to restrict an SVG Print file to a single size of paper was decided after a large amount of discussion. It has recently been noted that workflow scenarios such as XSL:FO to SVG translation may benefit from mixed paper sizes in an SVG Print document. The group still feels that restriction to a single paper size per SVG Print file simplifies implementations and minimises device dependence, however there is ongoing discussion about this decision.
The display of SVG image data on a printed page parallels the behaviour of a screen based renderer whose image sizes are specified as absolute dimensions or percentages of the current viewport.
In the absence of any width or height attributes, the SVG Print device will choose the default paper size for the printer device.
If the width and/or height attributes are specified, the SVG Print device will choose a paper size in accordance with the following sections.
If the SVG document contains an absolute size, the SVG Print device will choose the smallest paper size that can contain the specified size. The size on the outermost svg element represents the paper size only, not the printable region on that paper size. For example, if the outermost svg element specifies an area of 4 inches by 6 inches and the printer contains paper whose dimension is 4 inches by 6 inches with a printable area of 2 inches by 3 inches, the paper chosen will be 4 inches by 6 inches. Any image data that falls outside the 2 inch by 3 inch printable area will be clipped.
In the absence of paper large enough to accomodate the specified image size, the SVG Print device will choose the largest available paper size and clip the image to fit within the available area.
If the SVG image size is specified as a percentage value, it is considered to be a percentage of the available viewport. In such cases, the SVG Print device chooses the default paper size.
When the default paper size is selected and the SVG image size is specified as a percentage, the SVG image is scaled to fit within the printable area on the page.
In the example above, where the printable area consisted of a 2 inch by 3 inch area, an SVG image specified with a width and height of 100% will scale the SVG image to be contained within a 2 inch by 3 inch area.
<svg width="210mm" height="297mm"
xmlns="http://www.w3.org/2000/svg" version="1.2" streamable="true">
<pageSet>
<page>
<text x="50mm" y="85mm"
font-family="Arial" font-size="12">
I am an A4 page.
</text>
</page>
</pageSet>
</svg>
<svg width="90%" height="100%"
xmlns="http://www.w3.org/2000/svg" version="1.2" streamable="true">
<pageSet>
<page>
<text x="5%" y="10%"
font-family="Arial" font-size="12">
I scale to the page, but leave an empty 10% margin for comments.
</text>
</page>
</pageSet>
</svg>
SVG 1.2 includes a number of features aimed at device specific color management. The description was unavailable at time of publication.
SVG 1.0 contains functionality for use of ICC color profiles for the purpose of defining colors in alternate color spaces to sRGB. This section will explain how that is done.
SVG 1.2 includes a new attribute called deviceColor. This section will explain how it is used. The description was unavailable at time of publication.
This section will contain an example of device color and ICC color use.
It is anticipated that SVG 1.2 will include the ability to use so-called 'named' or 'spot' colors. This section will explain the use of such 'named' colors. The description was unavailable at time of publication.
This section will explain how to use 'named' color syntax. It will also explain the precedence of 'named' color in the presence and context of other declared color values for a given object.
This section will explain how ICC profiles are used by an SVG renderer.
This example will show the use and syntax of 'named' color.
The working group has indicated that a so-called 'overprint' capability will be added to SVG 1.2. This capability is of relevance to hard-copy devices only. The description was unavailable at time of publication.
This section will describe the use of the 'overprint' capability.
This example will show the use of overprint, and include some pictures showing the difference caused by use of 'overprint' on a printed page.
This section will explain in detail the behaviour when sending legacy SVG content to an SVG Print device. The description was unavailable at time of publication.
The authors of this specification are the participants of the W3C SVG Working Group.