SVG Printing Requirements

Introduction

The SVG specification [SVG 1.1] is a W3C recommendation that describes two-dimensional graphics in XML. It was designed primarily for Web content and, as such, supports features such as animation and interactivity suited for screen display. Industry and developer feedback has suggested a desire for a form of SVG suited to printing.

In response, the SVG Working Group will develop a print-specific version of SVG called SVG Print. The current feeling within the Working Group is that SVG Print will be a set of content requirements and conformance criteria that best enable printing. It is very likely that there will be a set of new language features proposed which are required for SVG Print, but will be equally useful in other domains. It is expected then, that these new features will become part of the core SVG language and the modules that are built from SVG. It is also likely that there will new language features that are specific to printing and can be safely ignored in non-printing environments.

Terminology

The following key words and phrases used throughout this document are defined here for clarity. The terms Must, Should, and May are used to specify the extent to which an item is a requirement for the SVG working group in defining SVGP. These recommendations should not be mistaken as a guide to implementors.

1. 'Must' means that the item is an absolute requirement.
2. 'Should' means that there may exist valid reasons in particular circumstances to ignore the item, but the full implications must be understood and carefully weighed before choosing a different course.
3. 'May' means that item will be considered, but further examination is needed to determine if the item should be treated as a requirement.
4. 'Constrained Memory Printer' is a printing device that contains limited RAM and no shared memory.
5. 'SVG' refers to SVG in general without reference to any version or profile.
6. 'SVG 1.0' refers to the original SVG specification.
7. 'SVG 1.1' refers to the modularized version of SVG 1.0.
8. 'SVG 1.2' refers to the next release of SVG and is planned to include features for SVGP.
9. 'SVGP' refers to SVG Print, an SVG specification for printing.
10. 'Rendering model' refers to the compositing model of SVG defined in the SVG 1.2 specification.

Usage Scenarios

The following usage scenarios illustrate some of the ways in which SVGP might be used for various applications. They may be used as design cases during the development of the SVG printing profile, and should be useful in helping non-members of the SVG Working Group to understand the intent and goals of this task.

Regardless of the intended usage of the SVG file, the intent is that a file that complies to SVGP will produce a reliable result when sent to a resource constrained printer.

Closed Printing Solution. A printing system that can take various input formats and print these input files will usually convert the input format to an internal format for transfer between devices. SVG fits such a system well as SVG allows for scalable printing (high resolution), exact placement of graphical objects and rich compositing features.

Constrained Resource Printing. SVGP could be used as a file format for low end printers. Many printers contain a limited amount of memory and no disk for paging. Printing files on such printers is often performed by streaming the file.

Slide Presentation. Existing proprietary slide presentation formats could be converted into SVGP and then printed anywhere.

PC-free Photo Printing. The user has a digital camera with a single JPEG image. The JPEG image is wrapped in an SVG file to scale it and place it. The camera also adds text elements with the date and time the picture was taken. The result is sent directly to an SVGP capable printer.

PC-free Photo Album Generation. A person takes a number of photos with their digital camera. They choose an inbuilt template for photo album layout. They connect the camera to an SVGP enabled printer directly and send the final form SVG graphic including images, borders, framing etc. with no driver or PC required.

Variable Data Printing. Customer wishes to use SVG to provide variable data content for printing. SVG content is added to an XML data stream as content that varies from job to job (or copy to copy). The SVG is transcoded before final rendering.

Printing With Job Control. A document is saved in SVGP format as multiple pages. The SVGP content is sent to the printer along with supplemental job control instructions such as JDF.

Printer Device Specific Output. SVG content is created with a specific rendering (printing) device in mind. Proper rendering of the content on the device requires that specific spot colors or device CMYK colors be used. Author needs to be able to include such specification in the SVG content for the printer to use when rendering the SVG content. The reason spot color is being used is that the output will be transferred to a printing press.

SVG Pass-through to SVG Printer User views SVG content in a compatible viewer. User wishes to print document by sending the SVG file directly to the printer (bypass any OS related print functionality). Printer must render SVG content directly. For example, the user selects Print... from an application and chooses an SVG-capable printer. The application detects that the printer supports SVGP and then uses operating system features to send an SVGP print stream to the printer driver. The printer driver then passes the SVGP print stream to the printer.

Printing SVG to a non-SVG Printer. User has an application that provides (generates) SVG content. The user's printer does not render SVG directly. User chooses to print. The SVG content is sent by the application to the print sub-system (perhaps a printing service) available to the user. Somewhere in this system, the SVG must be transcoded to a printer language such as PCL or PS in order to be printed.

Proxy View Printing. User has a mobile SVG viewer on a device which cannot generate print ready output. The user selects the URL of where the SVG content can be found and requests that the content be printed. The content is sent to a printer which can render the original SVG content, which may contain features that were removed for his mobile viewer, directly.

User Edited Print Content. User wants to add an SVG effect (such as a lighting filter) to a document created in by non SVG desktop publishing application before final printing. User prints the document to a software print driver that transcodes from the application's native print format (such as GDI or PostScript) to SVGP. User edits the resulting SVGP by hand or with a tool to add the SVG effect before sending the SVGP to a printer.

GDI Transcoding. User selects Print... from an application and chooses an SVG-capable printer. The application generates a standard OS print stream (e.g., GDI-compatible stream on Windows). The printer driver for the SVG-capable printer converts the GDI-compatible stream into SVGP which is sent to the printer.

Preview Capture. User selects Print... from an application and chooses a special print driver that captures the print stream and saves it to disk as SVGP. (This is very similar to what SVGMaker and Acrobat Distiller do, or choosing a PostScript printer and saying "Save to disk" from the Print... dialog.) The stored SVGP is then loaded into an SVG viewer for preview purposes.

Interchange Format. User selects Print... from an application and chooses a special print driver that captures the print stream and saves it to disk as SVGP. (This is very similar to what SVGMaker and Acrobat Distiller do, or choosing a PostScript printer and saying "Save to disk" from the Print... dialog.) The user chooses to print the file from the desktop. The operating system then tries to decide how to print the file. It might: (a) recognize it as generic XML or plain text and print the source code or (b) recognize it as SVG. If (b) recognized as SVG, the operating system then either converts the SVGP to standard OS print stream (e.g., GDI-compatible stream on Windows) or notices that the printer is capable of rendering SVGP and simply passes the SVGP through to the printer.

Web Distributed Paginated Documents. User selects Print... from an application and chooses a special print driver that captures the print stream and saves it to disk as SVGP. This final form paginated document is then made available for distribution (over the web or by email) for both viewing and printing by other parties.

Source Document for Transcoding to Other Formats. Same as above, only the SVGP is transcoded to another format, such as PDF, for distribution.

Generic Content Transformation for Imaging Device. The intent is to visualize XML data on two different devices (screen and paper). XSLT is used to transform the XML data into two different SVG files (layout of the file changes based on the device). Print the SVG file that was targeted for paper.

Special Printing Considerations

Animation and interactive hyperlinking. SVG files may contain animations and hyperlinks. Printing devices can not perform animation or support interactive content. Animation and interactivity features are ignored for SVGP.

Color Spaces. It is important to the user that color is reproduced correctly, especially when printing. In general this is done by describing all the colors in the picture in terms of components (e.g. sRGB), and defining the exact mapping from these components to an output colorspace (e.g. device CMYK). Different colorspaces may be converted for output via a mapping, such as an ICC output profile.

In color systems, there are color spaces which can be either device independent or device dependent. It is important to distinguish between these types of color spaces. For example, so-called 'spot' color is a device dependent color.

Spot Color Support. For situations where an exact color value is required (this is known as a 'named color' e.g. Pantone®), the intent is to maintain the named color value until final render. A mechanism to support expression of named or device specific color could be introduced, along with an appropriate sRGB fallback color. The specification mechanism would include the ability to distinguish between device specific and device independent colors.

For implementation it is preferable to support independent color processing paths, allowing named colors to undergo no transformation prior to ink deposition, whilst simultaneously allowing other colors to be processed using color adjustment transformations such as those specified in an ICC output profile.

Multiple Page Support. Traditional SVG files can all be scaled to fit on a single page. For documents such as single graphics, or maps, this situation is fine. For large documents, the approach of scaling to a single page would mean that long documents, while being suitable for screen displays (a window with a large scroll bar), would not be suited for printing. SVGP will need to address the issue of pagination within an SVGP file.

Multiple Part Support. SVG files can reference external image data and resources such as fonts. Defining a method of encapsulating a number of files into an aggregate for transmission to a hard copy device would be desirable. Many hard copy devices lack a bidirectional data transmission path, and so in such devices, an aggregated file containing the SVG printable data and its support files is necessary.

Design Principles

1. It is recognized that some of the goals might conflict or be unachievable and that tradeoffs will have to be made.
2. SVGP should attempt to maximize compatibility with SVG 1.1 to display existing content. Changes to SVG specific to printing that reduce compatibility with SVG 1.1 will be resisted.
3. Features missing from SVG 1.1 to support hard copy device functionality will be proposed for incorporation into SVG 1.2.
4. There will be resistance to changes that make it difficult for vendors to alter their existing SVG applications.
5. There will be consideration for the items listed in the SVG 1.1/1.2/2.0 Requirements Document [SVG 1.1/1.2/2.0 Requirements]. Items listed in the SVG 1.1/1.2/2.0 Requirements Document that are relevant to printing will be considered as requirements for SVG Printing. (e.g. streaming)
6. A true subset of the SVG 1.2 imaging model must be maintained.
7. The imaging model of SVG 1.1 must be maintained and it may take advantage of additional imaging functionality introduced in SVG 1.2.
8. SVGP should be designed to facilitate authoring tools.
9. SVGP should be designed so that SVG content can be transcoded into SVGP preserving as much visual fidelity as possible.

Requirements

1. General Requirements
   1. SVGP must be international.
   2. SVGP must consider the constraints of limited memory printing solutions.
   3. SVGP must be a true subset of SVG 1.2.
   4. Conformance criteria for SVGP must be produced. The criteria should be separated into sections relevant to particular application types (eg. SVG files/document fragments, SVG generators, SVG viewers, SVG printers, etc.)
   5. Software or documents must pass the relevant criteria to be able to claim conformance to the particular application type.
   6. A conformance test suite must be developed for SVGP. The test suite must be made publicly available. Conformance test suites for other uses of SVGP (e.g. prepress guidelines) may be developed.
   7. The SVGP conformance test suite must be a subset of the SVG conformance test suite.
2. Rendering Model
   1. SVGP has the same rendering model as SVG 1.1 but may support added functionality of the SVG 1.2 rendering model.
3. Document Structure
   1. SVGP should support multiple pages in a single SVG file.
   2. SVGP may define the use of page break markers / regions.
   3. SVGP should include the ability to define the desired media characteristics on a per-page basis.
   4. SVGP should provide a mechanism to support page templates and shared/re-usable objects.
4. Streaming
   1. SVGP must support streaming the content to the printer to facilitate progressive rendering and discarding of resources between pages.
5. Color
   1. SVGP must support all color values as defined in the SVG 1.1 specification.
   2. SVGP must define the syntax for use of named colors such as Pantone®.
   3. SVGP must support color keywords as defined by the CSS3 color keywords.
   4. SVGP may support advanced color features such as extended color spaces and overprint.
6. Clipping, Masking and Compositing
   1. SVGP must support clipping, masking, and compositing.
   2. SVGP may restrict compositing complexity depending on memory requirements.
7. Filter Effects
   1. SVGP may support a subset of filter effects.
8. Interactivity
   1. SVGP must ignore interactive content in SVG documents.
9. Scripting
   1. SVGP must not support the SVG 1.2 scripting feature set.
10. Animation
    1. SVGP must not support display of animated content.
11. Fonts
    1. SVGP may support a defined set of fonts. For example, a sans-serif font supporting Unicode plane 1.
    2. SVGP must support SVG fonts with glyph outlines expressed using the "d" attribute on the <glyph> element.
    3. SVGP may support SVG fonts with arbitrary SVG glyph content restricted to the SVG font definition as defined for SVG.
    4. SVGP files may include all font information required for printing the fonts included in the document. Such fonts could be in a variety of formats.
12. Metadata and Extensibility
    1. SVGP must support embedded metadata.
    2. SVGP must allow inclusion of elements and attributes from foreign namespaces within the SVG content.
    3. SVGP may provide a mechanism for viewing the overall structure or thumbnail of a page in the multiple paged documents.
    4. SVGP may support association of page thumbnails with the XML defining the page.
13. Job Control
    1. SVGP should be compatible with standard print job control via the use of external job control techniques, such as 'Internet Printing Protocol' (IPP), 'Job Description Format' (JDF) or 'Printer Job Language' (PJL).
    2. SVGP may reference an encapsulation file format to allow transmission of multiple part SVG documents in one file to the print device.
14. Version conversion
    1. SVGP may define a method of converting any SVG file to a SVG file conforming to SVGP.
15. SVG 1.1/1.2/2.0 Extensions Under Consideration
    1. SVGP may include items proposed in the SVG 1.1/1.2/2.0 Requirements Document [SVG 1.1/1.2/2.0 Requirements].

References

SVG 1.1

Scalable Vector Graphics (SVG) 1.1 Specification, Jon Ferraiolo, Jun Fujisawa, Dean Jackson, editors, W3C, 14 January 2003 (Recommendation). See http://www.w3.org/TR/SVG11/

SVG 1.1/1.2/2.0 Requirements

SVG 1.1/1.2/2.0 Requirements Document, Dean Jackson, editor, W3C, 22 April 2002. See http://www.w3.org/TR/SVG2Reqs/

Mobile SVG Profiles

Mobile SVG Profiles: SVG Tiny and SVG Basic, Tolga Capin, editor, W3C, 14 January 2003 (Recommendation). See http://www.w3.org/TR/SVGMobile