Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document lists the design principles and requirements for the creation of a SVG specification related to printing.
This is a W3C Working Draft for review by W3C Members and other interested parties. It is a draft document and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C Recommendations and other technical documents, including Working Drafts and Notes, can be found at http://www.w3.org/TR/
This is the first release of the SVG Printing Requirements. It is expected that this document will progress through a number of working drafts, including "Last Call", before being published in final form as a W3C Note.
This document was developed by the Scalable Vector Graphics (SVG) working group as part of the W3C Graphics Activity. The authors of this document are the SVG Working Group members.
Feedback on this document should be sent to the email list public-svg-print@w3.org. This
is an archived public list specific to the issues of SVG Print.
Public discussion of issues
related to vector graphics on the Web and SVG in particular
takes place on the the public
mailing list of the SVG Working Group (list
archives). To subscribe send an email to
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.
This section represents the status of this document at the time this version was published. It will become outdated if and when a new version is published. The latest status is maintained at the W3C.
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.
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.
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 PDF.
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.
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.
The authors of this specification are the participants of the W3C SVG Working Group.