You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
909 lines
31 KiB
909 lines
31 KiB
<?xml version="1.0" encoding="utf-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
|
<head>
|
|
<title>SVG Printing Requirements</title>
|
|
|
|
<style type="text/css">
|
|
|
|
.designgoals {
|
|
list-style-type: decimal;
|
|
}
|
|
|
|
.req-level1 {
|
|
list-style-type: decimal;
|
|
font-weight: bold;
|
|
}
|
|
|
|
.req-level2 {
|
|
list-style-type: decimal;
|
|
font-weight: normal;
|
|
}
|
|
|
|
.req-level1 li {
|
|
margin-top: 1em;
|
|
}
|
|
|
|
.req-level2 li {
|
|
margin-top: 0em;
|
|
}
|
|
|
|
.label {
|
|
margin-top: 1em;
|
|
}
|
|
|
|
.comment {
|
|
background: #ffffaa;
|
|
}
|
|
|
|
.svgversion {
|
|
color: #336633;
|
|
font-weight: bold;
|
|
}
|
|
|
|
.term {
|
|
font-weight: bold;
|
|
color: #aa3333;
|
|
}
|
|
|
|
.issue {
|
|
color: #ff0000;
|
|
}
|
|
|
|
</style>
|
|
|
|
<link type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD"/>
|
|
|
|
|
|
</head>
|
|
|
|
|
|
<body>
|
|
<div class="head">
|
|
<p>
|
|
<a href="http://www.w3.org/" title="Go to W3C Home Page">
|
|
<img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home"/>
|
|
</a>
|
|
</p>
|
|
<h1>SVG Printing Requirements </h1>
|
|
|
|
<h2>W3C Working Draft 18 February 2003</h2>
|
|
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
<dd>
|
|
<a href="http://www.w3.org/TR/2003/WD-SVGPrintReqs-20030218/">
|
|
http://www.w3.org/TR/2003/WD-SVGPrintReqs-20030218/</a>
|
|
</dd>
|
|
<dt>Latest version:</dt>
|
|
<dd>
|
|
<a href="http://www.w3.org/TR/SVGPrintReqs">http://www.w3.org/TR/SVGPrintReqs</a>
|
|
</dd>
|
|
<dt>
|
|
Editors
|
|
</dt>
|
|
<dd>
|
|
Jun Fujisawa (Canon)
|
|
<a href="mailto:">
|
|
<fujisawa.jun@canon.co.jp>
|
|
</a>
|
|
<br />
|
|
Lee Klosterman (HP)
|
|
<a href="mailto:">
|
|
<lee_klosterman@hp.com>
|
|
</a>
|
|
<br />
|
|
Craig Brown (Canon)
|
|
<a href="mailto:cmb@research.canon.com.au">
|
|
<cmb@research.canon.com.au>
|
|
</a>
|
|
<br />
|
|
Alex Danilo (Canon)
|
|
<a href="mailto:alex@research.canon.com.au">
|
|
<alex@research.canon.com.au>
|
|
</a>
|
|
</dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">
|
|
Copyright</a> © 2003 <a href="http://www.w3.org/"><acronym
|
|
title="World Wide Web
|
|
Consortium">W3C</acronym></a><sup>®</sup> (<a
|
|
href="http://www.lcs.mit.edu/"><acronym title="Massachusetts
|
|
Institute of Technology">MIT</acronym></a>, <a
|
|
href="http://www.ercim.org/"><acronym title="European Research
|
|
Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
|
|
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights
|
|
Reserved. W3C <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
|
|
<a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>,
|
|
<a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-documents">document
|
|
use</a> and <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-software">software
|
|
licensing</a> rules apply.</p>
|
|
|
|
</div>
|
|
<hr />
|
|
|
|
<h2><a name="abstract"></a>Abstract</h2>
|
|
<p>
|
|
This document lists the design principles and requirements for
|
|
the creation of a SVG specification related to printing.
|
|
</p>
|
|
|
|
<h2><a name="status"></a>Status of this Document</h2>
|
|
<p>
|
|
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 <a
|
|
href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>
|
|
</p>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<p>
|
|
This document was developed by the
|
|
<a href="http://www.w3.org/Graphics/SVG/">Scalable Vector
|
|
Graphics</a> (SVG) working group as part of the W3C
|
|
<a href="http://www.w3.org/Graphics/Activity">Graphics Activity</a>.
|
|
The authors of this document are the SVG Working Group
|
|
members.
|
|
</p>
|
|
|
|
<p>
|
|
Feedback on this document should be sent to the email list <a
|
|
href="mailto:public-svg-print@w3.org">public-svg-print@w3.org</a>. 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 <a href="mailto:www-svg@w3.org"> the public
|
|
mailing list of the SVG Working Group</a> (<a
|
|
href="http://lists.w3.org/Archives/Public/www-svg/">list
|
|
archives</a>). To subscribe send an email to
|
|
<code>www-svg-request@w3.org</code> with the word
|
|
<code>subscribe</code> in the subject line.
|
|
</p>
|
|
|
|
<p>
|
|
The latest information regarding <a rel="disclosures"
|
|
href="http://www.w3.org/Graphics/SVG/Disclosures">patent
|
|
disclosures</a> 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.
|
|
</p>
|
|
|
|
<p>
|
|
<em>
|
|
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.
|
|
</em>
|
|
</p>
|
|
|
|
|
|
<h2><a name="contents"></a>Table of Contents</h2>
|
|
|
|
<ul>
|
|
<li>
|
|
1. <a href="#sec-introduction">Introduction</a>
|
|
</li>
|
|
<li>
|
|
2. <a href="#sec-terminology">Terminology</a>
|
|
</li>
|
|
<li>
|
|
3. <a href="#sec-usage">Usage Scenarios </a>
|
|
</li>
|
|
<li>
|
|
4. <a href="#sec-features">Feature Sets </a>
|
|
</li>
|
|
<li>
|
|
5. <a href="#sec-design">Design Principles </a>
|
|
</li>
|
|
<li>
|
|
6. <a href="#sec-requirements">Requirements</a>
|
|
</li>
|
|
<li>
|
|
7. <a href="#sec-references">References</a>
|
|
</li>
|
|
<li>
|
|
<a href="#sec-authorlist">Author List</a>
|
|
</li>
|
|
</ul>
|
|
|
|
<div class="div1">
|
|
<h2 id="sec-introduction">
|
|
1. Introduction
|
|
</h2>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2 id="sec-terminology">
|
|
2. Terminology
|
|
</h2>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
<ol>
|
|
<li>
|
|
<b>'Must'</b>
|
|
means that the item is an absolute requirement.
|
|
</li>
|
|
<li>
|
|
<b>'Should'</b> 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.
|
|
</li>
|
|
<li>
|
|
<b>'May' </b> means that
|
|
item will be considered, but further examination is
|
|
needed to determine if the item should be treated as a requirement.
|
|
</li>
|
|
<li>
|
|
<b>'Constrained Memory Printer' </b>
|
|
is a printing device that contains limited RAM and no shared memory.
|
|
</li>
|
|
<li>
|
|
<b>'SVG' </b>
|
|
refers to SVG in general without reference to any version or profile.
|
|
</li>
|
|
<li>
|
|
<b>'SVG 1.0' </b>
|
|
refers to the original SVG specification.
|
|
</li>
|
|
<li>
|
|
<b>'SVG 1.1' </b>
|
|
refers to the modularized version of SVG 1.0.
|
|
</li>
|
|
<li>
|
|
<b>'SVG 1.2' </b>
|
|
refers to the next release of SVG and is planned to include features for
|
|
SVGP.
|
|
</li>
|
|
<li>
|
|
<b>'SVGP' </b>
|
|
refers to SVG Print, an SVG specification for printing.
|
|
</li>
|
|
<li>
|
|
<b>'Rendering model' </b>
|
|
refers to the compositing model of SVG defined in the SVG 1.2 specification.
|
|
</li>
|
|
</ol>
|
|
</div>
|
|
|
|
|
|
<div class="div1">
|
|
<h2 id="sec-usage">
|
|
3. Usage Scenarios
|
|
</h2>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Closed Printing Solution. </b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Constrained Resource Printing. </b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Slide Presentation. </b>
|
|
Existing proprietary slide presentation formats
|
|
could be converted into SVGP and then printed anywhere.
|
|
</p>
|
|
<p>
|
|
<b>PC-free Photo Printing. </b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>PC-free Photo Album Generation. </b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Variable Data Printing. </b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Printing With Job Control.</b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Printer Device Specific Output. </b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>SVG Pass-through to SVG Printer</b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Printing SVG to a non-SVG Printer. </b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Proxy View Printing. </b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>User Edited Print Content. </b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>GDI Transcoding. </b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Preview Capture. </b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Interchange Format. </b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Web Distributed Paginated Documents. </b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Source Document for Transcoding to Other Formats. </b>
|
|
|
|
Same as above, only the SVGP is transcoded to another format,
|
|
such as PDF, for distribution.
|
|
</p>
|
|
<p>
|
|
<b>Generic Content Transformation for Imaging Device. </b>
|
|
|
|
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.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2 id="sec-features">4. Special Printing Considerations</h2>
|
|
|
|
<p>
|
|
<b>Animation and interactive hyperlinking.</b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Color Spaces.</b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Spot Color Support.</b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Multiple Page Support.</b>
|
|
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Multiple Part Support.</b>
|
|
|
|
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.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2 id="sec-design">5. Design Principles</h2>
|
|
|
|
<ol>
|
|
<li> It is recognized that some of the goals might conflict or be unachievable and
|
|
that tradeoffs will have to be made.</li>
|
|
<li> 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. </li>
|
|
<li> Features missing from SVG 1.1 to support hard copy device functionality will be
|
|
proposed for incorporation into SVG 1.2.</li>
|
|
<li> There will be resistance to changes that make it difficult for vendors to alter
|
|
their existing SVG applications. </li>
|
|
<li>
|
|
There will be consideration for the items listed in the
|
|
SVG 1.1/1.2/2.0 Requirements Document <a href="#ref-svgreqs">[SVG 1.1/1.2/2.0 Requirements]</a>.
|
|
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)
|
|
</li>
|
|
<li> A true subset of the SVG 1.2 imaging model must be maintained.</li>
|
|
<li>
|
|
The imaging model of SVG 1.1 must be maintained and it
|
|
may take advantage of additional imaging functionality
|
|
introduced in SVG 1.2.
|
|
</li>
|
|
<li> SVGP should be designed to facilitate authoring tools.</li>
|
|
<li>
|
|
SVGP should be designed so that SVG content can be transcoded into
|
|
SVGP preserving as much visual fidelity as possible.
|
|
</li>
|
|
|
|
</ol>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2 id="sec-requirements">6. Requirements</h2>
|
|
<ol class="req-level1">
|
|
<li>General Requirements
|
|
<ol class="req-level2">
|
|
<li>
|
|
SVGP <span class="term">must</span> be international.
|
|
</li>
|
|
<li>
|
|
SVGP <span class="term">must</span> consider the constraints of limited memory
|
|
printing solutions.
|
|
</li>
|
|
<li>
|
|
SVGP <span class="term">must</span> be a true subset of SVG 1.2.
|
|
</li>
|
|
<li>
|
|
Conformance criteria for SVGP <span class="term">must</span> be produced. The
|
|
criteria <span class="term">should</span> be separated into sections relevant to particular application
|
|
types (eg. SVG files/document fragments, SVG generators, SVG viewers, SVG printers, etc.)
|
|
</li>
|
|
<li>
|
|
Software or documents <span class="term">must</span> pass the relevant criteria
|
|
to be able to
|
|
claim conformance to the particular application type.
|
|
</li>
|
|
<li>
|
|
A conformance test suite <span class="term">must</span> be developed for SVGP.
|
|
The test suite must be made publicly available. Conformance test suites for
|
|
other uses of SVGP (e.g. prepress guidelines) <span class="term">may</span> be developed.
|
|
</li>
|
|
<li>
|
|
The SVGP conformance test suite <span class="term">must</span> be a subset of
|
|
the SVG conformance test suite.
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>Rendering Model
|
|
<ol class="req-level2">
|
|
<li>
|
|
SVGP has the same rendering model as SVG 1.1 but <span class="term">may</span>
|
|
support added functionality of the SVG 1.2 rendering model.
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>Document Structure
|
|
<ol class="req-level2">
|
|
<li>
|
|
SVGP <span class="term">should</span> support multiple pages in a single SVG file.
|
|
</li>
|
|
<li>
|
|
SVGP <span class="term">may</span> define the use of page break markers / regions.
|
|
</li>
|
|
<li>
|
|
SVGP <span class="term">should</span> include the ability to define the desired
|
|
media characteristics on a per-page basis.
|
|
</li>
|
|
<li>
|
|
SVGP <span class="term">should</span> provide a mechanism to support page templates and
|
|
shared/re-usable objects.
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>Streaming
|
|
<ol class="req-level2">
|
|
<li>
|
|
SVGP <span class="term">must</span> support streaming the content to the printer
|
|
to facilitate progressive rendering and discarding of resources between pages.
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>Color
|
|
<ol class="req-level2">
|
|
<li>
|
|
SVGP <span class="term">must</span> support all color values as defined
|
|
in the SVG 1.1 specification.
|
|
</li>
|
|
<li>
|
|
SVGP <span class="term">must </span>define the syntax for use of named
|
|
colors such as Pantone®.
|
|
</li>
|
|
<li>
|
|
SVGP <span class="term">must</span> support color keywords as defined by
|
|
the CSS3 color keywords.
|
|
</li>
|
|
<li>
|
|
SVGP <span class="term">may</span> support advanced color features such as
|
|
extended color spaces and overprint.
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>Clipping, Masking and Compositing
|
|
<ol class="req-level2">
|
|
<li>
|
|
SVGP <span class="term">must</span> support clipping, masking,
|
|
and compositing.
|
|
</li>
|
|
<li>
|
|
SVGP <span class="term">may</span> restrict compositing complexity
|
|
depending on memory requirements.
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>Filter Effects
|
|
<ol class="req-level2">
|
|
<li>
|
|
SVGP <span class="term">may</span> support a subset of filter effects.
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>Interactivity
|
|
<ol class="req-level2">
|
|
<li>
|
|
SVGP <span class="term">must</span> ignore interactive content in SVG documents.
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>Scripting
|
|
<ol class="req-level2">
|
|
<li>
|
|
SVGP <span class="term">must not</span> support the SVG 1.2 scripting feature set.
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>Animation
|
|
<ol class="req-level2">
|
|
<li>
|
|
SVGP <span class="term">must not</span> support display of
|
|
animated content.
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>Fonts
|
|
<ol class="req-level2">
|
|
<li>
|
|
SVGP <span class="term">may</span> support a defined set of fonts.
|
|
For example, a sans-serif font supporting Unicode plane 1.
|
|
</li>
|
|
<li>
|
|
SVGP <span class="term">must</span> support SVG fonts with glyph outlines
|
|
expressed using the "d" attribute on the <glyph> element.
|
|
</li>
|
|
<li>
|
|
SVGP <span class="term">may</span> support SVG fonts with arbitrary SVG
|
|
glyph content restricted to the SVG font definition as defined for SVG.
|
|
</li>
|
|
<li>
|
|
SVGP files <span class="term">may</span> include all font information required
|
|
for printing the fonts included in the document. Such
|
|
fonts could be in a variety of formats.
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>Metadata and Extensibility
|
|
<ol class="req-level2">
|
|
<li>
|
|
SVGP <span class="term">must</span> support embedded metadata.
|
|
</li>
|
|
<li>
|
|
SVGP <span class="term">must</span> allow inclusion of elements and attributes
|
|
from foreign namespaces within the SVG content.
|
|
</li>
|
|
<li>
|
|
SVGP <span class="term">may</span> provide a mechanism for viewing the overall
|
|
structure or thumbnail of a page in the multiple paged documents.
|
|
</li>
|
|
<li>
|
|
SVGP <span class="term">may</span> support association of page thumbnails with
|
|
the XML defining the page.
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>Job Control
|
|
<ol class="req-level2">
|
|
<li>
|
|
SVGP <span class="term">should</span> be compatible with standard print job
|
|
control via the use of external job control techniques, such as
|
|
<a href="http://www.pwg.org/ipp">'Internet Printing Protocol' (IPP)</a>,
|
|
<a href="http://www.cip4.org/documents/jdf_specifications/index.html">
|
|
'Job Description Format' (JDF)</a> or 'Printer Job Language' (PJL).
|
|
</li>
|
|
<li>
|
|
SVGP <span class="term">may</span> reference an encapsulation file format to
|
|
allow transmission of multiple part SVG documents in one file to the print device.
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>Version conversion
|
|
<ol class="req-level2">
|
|
<li>
|
|
SVGP <span class="term">may</span> define a method of converting any SVG file to a
|
|
SVG file conforming to SVGP.
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>SVG 1.1/1.2/2.0 Extensions Under Consideration
|
|
<ol class="req-level2">
|
|
<li>
|
|
SVGP <span class="term">may</span> include items proposed in the
|
|
SVG 1.1/1.2/2.0 Requirements Document
|
|
<a href="#ref-svgreqs">[SVG 1.1/1.2/2.0 Requirements]</a>.
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
|
|
</ol>
|
|
</div>
|
|
<div class="div1">
|
|
<h2 id="sec-references">7. References</h2>
|
|
<dl class="references">
|
|
<dt class="label"><a name="ref-svg"></a>SVG 1.1</dt>
|
|
<dd>
|
|
<em>Scalable Vector Graphics (SVG) 1.1 Specification</em>,
|
|
Jon Ferraiolo, Jun Fujisawa, Dean Jackson, editors, W3C, 14 January 2003 (Recommendation). See
|
|
<a href="http://www.w3.org/TR/SVG11/">http://www.w3.org/TR/SVG11/</a>
|
|
</dd>
|
|
|
|
<dt class="label"><a name="ref-svgreqs"></a>SVG 1.1/1.2/2.0 Requirements</dt>
|
|
<dd>
|
|
<em>SVG 1.1/1.2/2.0 Requirements Document</em>,
|
|
Dean Jackson, editor, W3C, 22 April 2002. See
|
|
<a href="http://www.w3.org/TR/SVG2Reqs/">http://www.w3.org/TR/SVG2Reqs/</a>
|
|
</dd>
|
|
|
|
<dt class="label"><a name="ref-svgmobilereqs"></a>Mobile SVG Profiles</dt>
|
|
<dd>
|
|
<em>Mobile SVG Profiles: SVG Tiny and SVG Basic</em>,
|
|
Tolga Capin, editor, W3C, 14 January 2003 (Recommendation). See
|
|
<a href="http://www.w3.org/TR/SVGMobile">http://www.w3.org/TR/SVGMobile</a>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<hr class="xhtml" />
|
|
<h2>
|
|
<a id="sec-authorlist" name="sec-authorlist">Author List</a>
|
|
</h2>
|
|
<p>The authors of this specification are the participants of the W3C SVG
|
|
Working Group.</p>
|
|
<dl>
|
|
<dt>Authors:</dt>
|
|
<dd>
|
|
<ul>
|
|
<li>Ola Andersson, ZOOMON AB</li>
|
|
<li>Henric Axelsson, Ericsson AB</li>
|
|
<li>Phil Armstrong, Corel Corporation</li>
|
|
<li>Robin Berjon, Expway</li>
|
|
<li>Benoît Bézaire, Corel Corporation</li>
|
|
<li>Craig Brown, Canon Information Systems Research Australia</li>
|
|
<li>Mike Bultrowicz, Savage Software</li>
|
|
<li>Tolga Capin, Nokia Inc.</li>
|
|
<li>Mathias Larsson Carlander, Ericsson AB</li>
|
|
<li>Jakob Cederquist, ZOOMON AB</li>
|
|
<li>Charilaos Christopoulos, Ericsson AB</li>
|
|
<li>Lee Cole, Quark</li>
|
|
<li>Don Cone, America Online Inc.</li>
|
|
<li>Alex Danilo, Canon Information Systems Research Australia</li>
|
|
<li>Thomas DeWeese, Eastman Kodak</li>
|
|
<li>Jon Ferraiolo, Adobe Systems Inc.</li>
|
|
<li>Darryl Fuller, Schema Software</li>
|
|
<li>藤沢 淳 (FUJISAWA Jun), Canon</li>
|
|
<li>Rick Graham, BitFlash</li>
|
|
<li>Vincent Hardy, Sun Microsystems Inc.</li>
|
|
<li>端山 貴也 (HAYAMA Takanari), KDDI Research Labs</li>
|
|
<li>Lofton Henderson, OASIS</li>
|
|
<li>石川雅康 (ISHIKAWA Masayasu), W3C</li>
|
|
<li>Dean Jackson, W3C/CSIRO (<i>W3C Team Contact</i>)</li>
|
|
<li>Christophe Jolif, ILOG S.A.</li>
|
|
<li>Lee Klosterman, Hewlett-Packard</li>
|
|
<li>小林 亜令 (KOBAYASHI Arei), KDDI Research Labs</li>
|
|
<li>Thierry Kormann, ILOG S.A.</li>
|
|
<li>Yuri Khramov, Schema Software</li>
|
|
<li>Chris Lilley, W3C (<i>Working Group Chair</i>)</li>
|
|
<li>Philip Mansfield, Schema Software</li>
|
|
<li>Peter Mierau, Adobe Systems Inc.</li>
|
|
<li>水口 充 (MINAKUCHI Mitsuru), Sharp Corporation</li>
|
|
<li>Luc Minnebo, Agfa-Gevaert N.V.</li>
|
|
<li>小野 修一郎 (ONO Shuichiro), Sharp Corporation</li>
|
|
<li>Antoine Quint, Fuchsia Design (formerly of ILOG)</li>
|
|
<li>相良 毅 (SAGARA Takeshi), KDDI Research Labs</li>
|
|
<li>Brad Sipes, ZOOMON AB</li>
|
|
<li>Peter Sorotokin, Adobe Systems Inc.</li>
|
|
<li>上田 宏高 (UEDA Hirotaka), Sharp Corporation</li>
|
|
<li>Rick Yardumian, Canon Development Americas</li>
|
|
<li>Charles Ying, Openwave Systems, Inc.</li>
|
|
</ul>
|
|
</dd>
|
|
</dl>
|
|
|
|
</body>
|
|
<!-- SVG Printing Requirements Document -->
|
|
<!-- $Id: index.html,v 1.4 2003/02/17 12:46:58 dean Exp $ -->
|
|
</html>
|
|
|
|
|