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 SVG Print Requirements document lists some requirements and use cases for SVG 1.2 Print, along with a tentative schedule for the versions in which these requirements and use cases will be addressed. As such, the SVG Print Requirements document may be regularly updated as more use cases are discovered, though we expect that any further additions from this point would not be addressed by SVG Print 1.2, but a future version.
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 Print, and more general purpose functionality will come from SVG Tiny 1.2, modules of SVG Full 1.2, and SVG Full 1.1.
SVG Print formalizes 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/SVG Print device. Similarly, implementation of SVG Basic would be considered to be an SVG Basic/SVG Print device, and so forth.
Note, that an SVG Tiny/SVG 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, device-color and the referenceDirection 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/SVG Print device would be required to support the page element.
SVG 1.2 may introduce a referenceDirection attribute on the outermost svg element. In a system where content is controlled, implementors may optimise for the "backwards" value of this attribute.
This value implies that there are no forward references (via the use element or otherwise) 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.
Any other value for the referenceDirection attribute means 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 referenceDirection attribute, must be treated as if referenceDirection is set to 'either'. Documents lacking a referenceDirection attribute may reference any other part of the document as the default value for referenceDirection is either. Therefore they may need to be buffered.
Documents authored for SVG Print application should generate and set the outermost svg element attribute referenceDirection to 'backwards'.
The first page contains a blue circle. The second page contains a red rectangle.
<svg width="1000" height="1000" viewBox="0 0 1000 1000"
xmlns="http://www.w3.org/2000/svg" version="1.2" referenceDirection="backwards">
<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.
An SVG Print User Agent SHOULD print according to the behaviour described in this document, in the absence of any device specific job control information.
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.
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 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.
This section now specifies that width and height represent the required printable area.
If the SVG document contains an absolute size, the SVG Print device will choose the smallest paper size that can contain the specified size within the printable area. The width and height represent the required printable area for the graphics. In the absence of paper large enough to accomodate the specified printable area, the SVG Print device will choose the largest available paper size and clip the image to fit within the available area.
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, this paper would not be chosen unless there is no larger size available.
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" referenceDirection="backwards">
<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" referenceDirection="backwards">
<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>
The working group had indicated that a so-called 'overprint' capability would be added to SVG 1.2. This feature does not currently appear in the SVG 1.2 specification. This capability would be of relevance to hard-copy devices only. A 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.
The SVG 1.0 specification lists limitations in printing SVG image files. These include the inability to support animation or scripting.
SVG 1.2 Print devices must be able to gracefully handle legacy content. Most legacy SVG content assumes an in-memory DOM model and so an SVG Print device must treat all such files as if the outermost svg element has a referenceDirection attribute whose attribute value is set to 'either'.
In general, legacy content will need to be buffered in its entirety prior to the start of rendering in order to ensure any CSS styling properties appearing late in document order are applied correctly. In all cases, legacy content may be assumed to generate a single page of output.