index.html 44.1 KB

Raw Blame History Permalink

<?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>
<meta name="generator" content=
"HTML Tidy for Cygwin (vers 1st September 2004), see www.w3.org" />
<title>SVG Print 1.2, Part 1: Primer</title>
<link rel="stylesheet" type="text/css" href=
"style/svg-style.css" />
<link rel="stylesheet" type="text/css" href=
"http://www.w3.org/StyleSheets/TR/W3C-WD" />
</head>
<body>
<div class="head">
<p><a href="http://www.w3.org/"><img width="72" alt="W3C" src=
"http://www.w3.org/Icons/w3c_home" height="48" /></a> </p>
<h1>SVG Print 1.2, Part 1: Primer</h1>
<h2 id="pagesubtitle">W3C Working Draft 21 December 2007</h2>
<dl>
<dt>This version:</dt>
<dd><a href=
"http://www.w3.org/TR/2007/WD-SVGPrintPrimer12-20071221/">http://www.w3.org/TR/2007/WD-SVGPrintPrimer12-20071221/</a></dd>
<dt>Latest version:</dt>
<dd><a href=
"http://www.w3.org/TR/SVGPrintPrimer12/">http://www.w3.org/TR/SVGPrintPrimer12/</a></dd>
  <dt>Previous version:</dt>
  <dd><a href=
    "http://www.w3.org/TR/2007/WD-SVGPrintPrimer12-20070501/">http://www.w3.org/TR/2007/WD-SVGPrintPrimer12-20070501/</a></dd>
<dt>Editors:</dt>
<dd>Anthony Grasso, Canon Information Systems Research Australia,
&lt;<a href=
"mailto:anthony.grasso@research.canon.com.au">anthony.grasso@research.canon.com.au</a>&gt;</dd>
<dd>Andrew Shellshear, Canon Information Systems Research
Australia, &lt;<a href=
"mailto:andrews@research.canon.com.au">andrews@research.canon.com.au</a>&gt;</dd>
<dd>Chris Lilley, W3C &lt;<a href=
"mailto:chris@w3.org">chris@w3.org</a>&gt;</dd>
<dt>Authors:</dt>
<dd>The authors of this specification are the participants of the
W3C SVG Working Group.</dd>
<dd>
  <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> &copy; 2007 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>&reg;</sup> (<a href="http://www.csail.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> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>
</dd>
</dl>
</div>
<hr title="Separator from Header" />
<h2 id="abstract">Abstract</h2>
<p>This Working Draft is a primer for use of the Scalable Vector
Graphics (SVG) Language for printing environments. It explains the
technical background and gives guidelines on how to use the SVG
Print specification with SVG 1.2 Tiny and SVG 1.2 Full modules for
printing. It is purely informative and has no conformance
statements.</p>
<h2 id="status">Status of This Document</h2>
  <p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a>  at http://www.w3.org/TR/.</em></p>
  <p>This document is a Last Call Working Draft. The W3C Membership and other interested parties are invited to review the document and send comments to
    to <a href=
      "mailto:public-svg-print@w3.org">public-svg-print@w3.org</a>
    (<a href=
      "http://lists.w3.org/Archives/Public/public-svg-print/">archives</a>)
    until 8 February 2008.
  There is an accompanying
<a href="#SVG12Print">SVG Print 1.2, Part 2: Language</a> that
defines conformance criteria, new and reintroduced language
features for SVG Printing.</p>
<p>This document has been produced by the <a href=
"http://www.w3.org/Graphics/SVG/Group">W3C SVG Working Group</a> as part
of the W3C <a href="http://www.w3.org/Graphics/Activity">Graphics
Activity</a> within the <a href=
"http://www.w3.org/Interaction/">Interaction Domain</a>. The
Working Group expects to advance this Working Draft to
Recommendation Status.</p>
<p>We explicitly invite comments on this specification, which has
already benefited from comments at the <a href=
"http://www.w3c.de/Events/2006/PrintSymposium_en.html">W3C Print
Symposium</a>. Please send them to <a href=
"mailto:public-svg-print@w3.org">public-svg-print@w3.org</a>
(<a href=
"http://lists.w3.org/Archives/Public/public-svg-print/">archives</a>).
For comments on the core SVG language, use <a href=
"mailto:www-svg@w3.org">www-svg@w3.org</a>: the public email list
for issues related to vector graphics on the Web (<a href=
"http://lists.w3.org/Archives/Public/www-svg/">archives</a>).
Acceptance of the archiving policy is requested automatically upon
first post to either list. To subscribe to these lists send an
email to <a href=
"mailto:public-svg-print-request@w3.org">public-svg-print-request@w3.org</a>
or <a href=
"mailto:www-svg-request@w3.org">www-svg-request@w3.org</a> with the
word subscribe in the subject line.</p>
<p>Publication as a Working Draft does not imply endorsement by the
<acronym title="World Wide Web Consortium">W3C</acronym>
Membership. This is a draft document and may be updated, replaced
or obsoleted by other documents at any time. It is inappropriate to
cite this document as other than work in progress.</p>

  <p> This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. This document is informative only. W3C maintains a
  <a href="http://www.w3.org/2004/01/pp-impl/19480/status" rel=
    "disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>. </p>


<hr />
<h2 id="howto">How to read this document and give feedback</h2>
<p>The main purpose of this document is to encourage public
feedback. The best way to give feedback is by sending an email to
<a href=
"mailto:public-svg-print@w3.org">public-svg-print@w3.org</a>.
Please identify in the subject line of your message the part of the
specificationto which your comment refers (e.g "Print compositing"
or "Print render formats"). If you have comments on multiple areas
of this document, then it is preferable to send several separate
comments.</p>
<p>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 <span class="note">like this.</span> There is
also a more general question, listed here:</p>
<p class="note">Interaction with other print standards. The SVG
Working Group believe that some design decisions would be best made
in collaboration with other print standards bodies, and would
welcome liaison statements in this area.</p>
<h2 id="toc">Table of Contents</h2>
<ul class="toc">
<li>1 <a href="#intro">Introduction</a></li>
<li>2 <a href="#user-agents">User Agents</a></li>
<li>3 <a href="#pages">Printing using Pages</a>
<ul class="toc">
<li>3.1 <a href="#page">The pageSet and page elements</a></li>
<li>3.2 <a href="#scope">The scope of a page</a></li>
<li>3.3 <a href="#master">Master Page</a></li>
<li>3.4 <a href="#referencing_pages">Referencing other
pages</a></li>
<li>3.5 <a href="#referencingMasterPages">Selecting a Master Page
when referencing a page</a></li>
<li>3.6 <a href="#page_orientation">Page Orientation</a></li>
<li>3.7 <a href="#noPrint">noPrint</a></li>
<li>3.8 <a href="#pagecss">Interaction of CSS and page
scoping</a></li>
<li>3.9 <a href="#pagexslfo">Relationship between XSF FO pages and
SVG Print pages</a></li>
<li>3.10 <a href="#animate">Animation and Scripting</a></li>
</ul>
</li>
<li>4 <a href="#jobcontrol">Job control</a>
<ul class="toc">
<li>4.1 <a href="#device">Printer device control</a></li>
<li>4.2 <a href="#bundling">Bundling SVG files with referenced
content</a></li>
<li>4.3 <a href="#existingstds">Relationship to existing job
control standards</a>
<ul class="toc">
<li>4.3.1 <a href="#jdf">JDF</a></li>
<li>4.3.2 <a href="#ipp">IPP</a></li>
<li>4.3.3 <a href="#ppml">PPML</a></li>
<li>4.3.4 <a href="#multimime">Multiplex MIME</a></li>
</ul>
</li>
<li>4.4 <a href="#bundlexample">Examples of SVG bundled jobs</a>
<ul class="toc">
<li>4.4.1 <a href="#exmultiplex">Multiplex MIME encoded SVG Print
job</a></li>
</ul>
</li>
</ul>
</li>
<li>5 <a href="#color">Color specification</a>
<ul class="toc">
<li>5.1 <a href="#sRGBcolor">sRGB colors</a></li>
<li>5.2 <a href="#iccoutput">ICC colors</a></li>
<li>5.3 <a href="#named">Named color</a>
<ul class="toc">
<li>5.3.1 <a href="#iccnamed">Use of the ICC named color
syntax</a></li>
<li>5.3.2 <a href="#iccnamedmanage">ICC named color profile
management</a></li>
<li>5.3.3 <a href="#namedexample">Example of named color
usage</a></li>
</ul>
</li>
<li>5.4 <a href="#devcolor">Device color specification</a>
<ul class="toc">
<li>5.4.1 <a href="#deviceelement">Use of the deviceColor
element</a></li>
<li>5.4.2 <a href="#devicexample">Example of device specific color
usage</a></li>
</ul>
</li>
</ul>
</li>
<li>6 <a href="#references">References</a></li>
</ul>

<h2 id="intro">1 Introduction</h2>
<p>Because of its scalable, geometric nature, SVG is inherently
better suited to print than raster image formats. The same geometry
can be displayed on screen and on a printer, with identical layout
in both but taking advantage of the higher resolution of print
media. The same colors can be output, using an ICC-based color
managed workflow on the printer and an sRGB fallback approximation
on screen. This has been true since SVG 1.0, and so SVG has been
used in print workflows (for example, in combination with XSL FO)
as well as on screen.</p>
<p>However, SVG also has dynamic, interactive features such as
declarative animation, scripting, timed elements like audio and
video, and user interaction such as event flow and link activation.
None of these are applicable to a print context. SVG 1.1 gives
static and dynamic conformance classes, but further guidance on
what exactly SVG Printers should do with such general content is
helpful. The SVG Print specification defines processing rules for
handling such general purpose content which was not designed to be
printed, but which may be encountered anyhow.</p>
<p>It is common in cross-media publishing to design content which
will be used both online and in print media. This specification
gives guidance on how to create such content and how to indicate
that it has been adapted to improve its print capability.</p>
<p>Lastly, it is possible to generate SVG which is exclusively
intended for print (for example, a printer which natively
understands SVG). This content might be created in an illustration
program, or it might be an output from a layout program, such as an
XSL-FO renderer; or it might be generated by an SVG Print driver.
This specification defines conformance classes for software which
reads this type of SVG,and also a conformance class for SVG Print
content.</p>
<h2 id="user-agents">2 User Agents</h2>
<p>There are two kinds of User Agents for SVG Printing - ones that
are responsible for printing an SVG document, and ones that are
responsible for showing print previews to the user on a screen.</p>
<p>An SVG Print Preview Device displays a preview on a screen of
what the printed pages should look like. It allows a user to view
each page, and choose the page orientations, which pages should be
printed, and other options for printing.</p>
<p>An SVG Printing Device, in general, doesn't interact directly
with a user. It's responsible for receiving the SVG content and the
instructions for what to do with it (in general, this is called
"Device Control") and then printing it.</p>
<div class="note">
<p>TODO: The above terms will probably be replaced as follows:</p>
<dl>
<dd>SVG Print Preview Device ---&gt; Print Preview Agent (PPA)</dd>
<dd>SVG Printing Device ---&gt; Print Reproduction Agent (PRA)</dd>
<dd>SVG Printing or Print Preview Device ---&gt; Print User Agent
(PUA)</dd>
</dl>
</div>
<h2 id="pages">3 Printing using Pages</h2>
<p>SVG Print documents may be structured to facilitate printing. In
particular, it is possible to construct content that is designed to
be printed on multiple pages.</p>
<div class="example">
<div class="exampleheader"><strong>Example:</strong> <a href=
"examples/page02.svg">An example with a bit of everything</a></div>
<div class="examplesource">
<pre>
&lt;svg xmlns="http://www.w3.org/2000/svg"&gt;

   &lt;!-- Default Background Master Page definitions go after the svg element and before the pageSet --&gt;

   &lt;defs&gt;
     &lt;!-- definitions here are available on each page --&gt;
   &lt;/defs&gt;

   &lt;!-- graphics here are visible on each page --&gt;

   &lt;pageSet&gt;

      &lt;masterPage rendering-order="over"&gt;
        &lt;!-- graphics here are visible in the foreground on each page --&gt;
      &lt;/masterPage&gt;

      &lt;page&gt;
        &lt;defs&gt;
          &lt;!-- These definitions are local to this page. --&gt;
        &lt;/defs&gt;
        &lt;!-- graphics for page 1 go here --&gt;
      &lt;/page&gt;

      &lt;page orientation="90"&gt;
        &lt;!-- graphics for page 2 go here --&gt;
      &lt;/page&gt;

      &lt;page noPrint="true"&gt;
        &lt;!-- This page is not printed --&gt;
      &lt;/page&gt;

   &lt;/pageSet&gt;

   &lt;!-- No SVG content is allowed here --&gt;

&lt;/svg&gt;
</pre></div>
</div>
<h3 id="page">3.1 The <span class="element">pageSet</span> and
<span class="element">page</span> elements</h3>
<p>SVG Print introduces a scoping mechanism (the <span class=
"element"><a href=
"/TR/2007/WD-SVGPrint12-20071221/#pageSet-element">pageSet</a></span> and <span class=
  "element"><a href="/TR/2007/WD-SVGPrint12-20071221#page-element">page</a></span>
elements) in order to delimit the physical pages for output on an
SVG Print device.</p>
<div class="example">
<div class="exampleheader"><strong>Example:</strong> <a href=
"examples/page01.svg">page01.svg</a></div>
<div class="examplesource">
<pre>
&lt;svg xmlns="http://www.w3.org/2000/svg"&gt;

  &lt;text x="20" y="20"&gt;This text is on the top of every page.&lt;/text&gt;

  &lt;pageSet id="pageSet1"&gt;

    &lt;page id="circle_page"&gt;
      &lt;circle cx="100" cy="100" r="20" fill="blue"/&gt;
    &lt;/page&gt;

    &lt;page id="rectangle_page"&gt;
      &lt;rect x="100" y="100" width="20" height="20" fill="red"/&gt;
    &lt;/page&gt;

  &lt;/pageSet&gt;

&lt;/svg&gt;
</pre></div>
</div>
<p>One physical page of output is generated for each <span class=
"element">page</span> element present in the SVG file. In the
absence of any <span class="element">page</span> element, one page
of output will be generated only if the SVG file contains content
which marks the image canvas.</p>
<h3 id="scope">3.2 The scope of a page</h3>
Another function of the page element is to manage the resources
required for a page in a resource-limited device. The contents of
each page element are isolated from each other.
<p>If a <span class="element">page</span> contains a <span class=
"element">defs</span> section in it, those defined objects are only
available for reference within the content of the enclosing
<span class="element">page</span> element. If some other
<span class="element">page</span> element in the document contains
a <span class="element">use</span> which references the
<span class="attribute">id</span> of some object in a different
<span class="element">page</span> element, that reference is not
resolved. This means that the rendered result will appear as if the
definition did not exist.</p>
<p>The scoping mechanism allows an implementation to free any
resources required to print a single page, after having finished
with that page. This also provides a simple mechanism to print page
ranges by skipping content between <span class=
"element">page</span> elements until the desired page range is
reached.</p>
<h3 id="master">3.3 Master Page</h3>
<p>SVG Print document allow the use of Master Pages. A Master Page
isn't printed separately, but appears in the background (or
foreground) of every document Page. There are two ways of doing
this.</p>
<p>In the first (and simple) way, all content which is within the
outermost <span class="element">svg</span> element and before the
<span class="element">pageSet</span> element are considered to be
the Background Master Page. It is then displayed on all pages
behind all the content of the pages (as though it immediately
preceded each page).</p>
<p>In the second, more complete way, master pages can be defined
for groups of pages. In addition, separate master pages can be
defined for the background and the foreground. In this case, the
user specifies a <span class="element">masterPage</span> element
immediately before the pages on which that master page is desired.
<span class="element">masterPage</span> elements can appear
wherever a <span class="element">page</span> element could appear,
though they aren't rendered.</p>
<p>The <span class="attribute">rendering-order</span> attribute
allows the user to specify whether the master page is a Background
Master Page (rendering-order="under") or Foreground Master Page
(rendering-order="over"). Note that there can only be a single
Background Master Page and a single Foreground Master Page in
operation on any page. The User Agent deletes the old Background
Master Page or Foreground Master Page whenever it encounters a new
one of the same kind.</p>
<p>It is possible to mix the default Background Master Page with
explicit masterPage elements, but this is not recommended. If
another Background Master Page is encountered, the default
Background Master Page is no longer used as a default master page,
including any definitions. This might be confusing to some users.
For most use cases, the author would either have a default
Background Master Page, or declare a Background and/or Foreground
Master Page before any <span class="element">page</span> elements
in a <span class="element">pageSet</span>.</p>
<p>For example, if a rectangle was drawn prior to the appearance of
any <span class="element">page</span> elements in the SVG document,
that rectangle would appear on every page printed by the SVG Print
device. If a masterPage was specified after the rectangle was
drawn, the rectangle would no longer be used as the background for
every page. Instead the content specified in the masterPage would
be used as the background for every page.</p>
<p>Note if a masterPage is specified and the author wishes for
certain objects to be reused it is good practice to have the
objectsto be reused specified in a <span class=
"element">defs</span> element before the pageSet.</p>
<div class="example">
<div class="exampleheader"><strong>Example:</strong> <a href=
"examples/masterPage01.svg">Background and Foreground Master
Pages</a></div>
<div class="examplesource">
<pre>
&lt;svg xmlns="http://www.w3.org/2000/svg"&gt;

   &lt;defs&gt;
     &lt;!-- definitions here are available to page 1 --&gt;
   &lt;/defs&gt;

   &lt;!-- graphics here are visible in the background on page 1 --&gt;

   &lt;pageSet&gt;

      &lt;page&gt;
        &lt;defs&gt;
          &lt;!-- These definitions are local to this page. --&gt;
        &lt;/defs&gt;
        &lt;!-- graphics for page 1 go here. --&gt;
        &lt;!-- This page uses the default background master page, and an empty foreground master page. --&gt;
      &lt;/page&gt;

      &lt;masterPage id="masterpage1"&gt;
        &lt;defs&gt;
          &lt;!-- These definitions are available to pages 2-3. --&gt;
        &lt;/defs&gt;
        &lt;!-- graphics here are visible in the background on pages 2-3. --&gt;
      &lt;/masterPage&gt;

      &lt;page&gt;
        &lt;!-- graphics for page 2 go here --&gt;
        &lt;!-- This page uses background masterpage1, and an empty foreground master page. --&gt;
      &lt;/page&gt;

      &lt;masterPage rendering-order="over" id="masterpage2"&gt;
        &lt;defs&gt;
          &lt;!-- These definitions are available to pages 3 onwards. --&gt;
        &lt;/defs&gt;
        &lt;!-- graphics here are visible in the foreground on pages 3 onwards. --&gt;
      &lt;/masterPage&gt;

      &lt;page&gt;
        &lt;!-- graphics for page 3 go here --&gt;
        &lt;!-- This page uses background masterpage1, and foreground masterpage2. --&gt;
      &lt;/page&gt;

      &lt;masterPage rendering-order="under" id="masterpage3"&gt;
        &lt;defs&gt;
          &lt;!-- These definitions are available to pages 4 onwards. --&gt;
        &lt;/defs&gt;
        &lt;!-- graphics here are visible in the background on pages 4 onwards. --&gt;
      &lt;/masterPage&gt;

      &lt;page&gt;
        &lt;!-- graphics for page 4 go here --&gt;
        &lt;!-- This page uses background masterpage3, and foreground masterpage2. --&gt;
      &lt;/page&gt;

   &lt;/pageSet&gt;

   &lt;!-- No SVG content is allowed here --&gt;
&lt;/svg&gt;
</pre></div>
</div>
<h3 id="referencing_pages">3.4 Referencing other pages</h3>
<p>It is possible for a SVG Print document to reference pages in an
external document. A <span class="element">use</span> element can
be used in place of a <span class="element">page</span> element,
provided it references a page element. Note that by default it will
use the master page of the referencing document, rather than the
master page of the referenced document.</p>
<div class="example">
<div class="exampleheader"><strong>Example:</strong> <a href=
"examples/pageref01.svg">Referencing an external page</a></div>
<div class="examplesource">
<pre>
&lt;svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"&gt;

  &lt;text x="20" y="120"&gt;Confidential&lt;/text&gt;

  &lt;pageSet&gt;

    &lt;!-- Reference a page from another document.  This will be treated as though it
         were a page of this document (ie. it will include the master page of this
         document, but not its own master page). --&gt;
    &lt;use xlink:href="page01.svg#circle_page"/&gt;

    &lt;page&gt;
      &lt;rect x="100" y="100" width="20" height="20" fill="green"/&gt;
    &lt;/page&gt;

  &lt;/pageSet&gt;

&lt;/svg&gt;
</pre></div>
</div>
<p>It is not currently possible to reference an entire SVG Print
document from another SVG Print document.</p>
<h3 id="referencingMasterPages">3.5 Selecting a Master Page when
referencing a page</h3>
<p>The <span class="attribute">use-master-page</span> attribute
gives control over which Master Pages will be applied to an
externally referenced page. The current Master Pages from the
externally referenced document may be applied to the externally
referenced page. In which case <span class=
"attribute">use-master-page</span>= <span class=
"attr-value">"external"</span>. Alternatively, the current Master
Pages from the referencing document may be applied to the
externally referenced page. In which case <span class=
"attribute">use-master-page</span>=<span class=
"attr-value">"current"</span>.</p>
<p class="note">TODO: Need feedback on this feature. Are there
compelling uses cases for having this extra complexity? What
benefit does it provide?</p>
<p class="note">TODO: Add an example of how to use this
feature.</p>
<h3 id="page_orientation">3.6 Page Orientation</h3>
<p>The <span class="element">page</span> element has a <span class=
"attribute">page-orientation</span> property which may be used to
rotate <span class="element">page</span> content for screen
display. In an SVG Print device, the <span class=
"attribute">page-orientation</span> property is treated as a
transform that is applied directly to the top-level element - both
the master page and the elements inside the page are
transformed.</p>
<div class="example">
<div class="exampleheader"><strong>Example:</strong> <a href=
"examples/page03.svg">Page Orientation</a></div>
<div class="examplesource">
<pre>
&lt;svg width="8.5in" height="11in" viewBox="0 0 612 792"&gt;
  &lt;rect x="36" y="36" width="540" height="720"
        fill="yellow" stroke-width="15" stroke="black"/&gt;
  &lt;pageSet&gt;
     &lt;page&gt;
        &lt;text font-size="30" x="72" y="108"&gt;This is portrait&lt;/text&gt;
     &lt;/page&gt;
     &lt;page page-orientation="90"&gt;
        &lt;text font-size="30" x="72" y="108"&gt;This is landscape&lt;/text&gt;
     &lt;/page&gt;
   &lt;/pageSet&gt;
&lt;/svg&gt;
</pre></div>
</div>
<h3 id="noPrint">3.7 noPrint</h3>
<p>The <span class="attribute">noPrint</span> attribute allows
users to specify things that shouldn't be printed. If its value is
true on an element, that element and all its children won't be
printed, as though it had been specified with display="false".</p>
<p>For example, in an online SVG graphics editor, a user may want
to print the graphics that are produced, but they usually won't
want to see the drawing tools. In this case, the drawing tools
could have <span class="attribute">noPrint</span>="true".
<span class="attribute">noPrint</span> could also be used for
elementary job control, to specify which pages should not be
printed, though it is recommended in this case to instead remove
the non-printing pages.</p>
<div class="example">
<div class="exampleheader"><strong>Example:</strong> <a href=
"examples/page04.svg">noPrint</a></div>
<div class="examplesource">
<pre>
&lt;svg xmlns="http://www.w3.org/2000/svg"&gt;

  &lt;text x="20" y="20" noPrint="true"&gt;This text will not be printed.&lt;/text&gt;
  &lt;text x="20" y="220" noPrint="false"&gt;Confidential.&lt;/text&gt;

  &lt;pageSet&gt;

    &lt;!-- This page will not be printed --&gt;
    &lt;page noPrint="true"&gt;
      &lt;rect x="100" y="100" width="20" height="20" fill="red"/&gt;
    &lt;/page&gt;

    &lt;!-- Only the rectangle will be printed on this page. --&gt;
    &lt;page&gt;
      &lt;circle cx="100" cy="100" r="20" fill="blue" noPrint="true"/&gt;
      &lt;rect x="100" y="100" width="20" height="20" fill="green"/&gt;
    &lt;/page&gt;

  &lt;/pageSet&gt;

&lt;/svg&gt;
</pre></div>
</div>
<h3 id="pagecss">3.8 Interaction of CSS and <span class=
"element">page</span> scoping</h3>
<p>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.</p>
<p>In a print environment, an implementation will most likely build
a representation of an individual page and then discard it after
printing. The implication of this is that any CSS usage within a
<span class="element">page</span> that could affect other
<span class="element">page</span> elements may be lost. More
importantly, if a selector is introduced at the end of a document
and it could have affected previously parsed <span class=
"element">page</span> elements then the printed result may appear
to be incorrect.</p>
<p>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 <span class="element">page</span> elements.
This is in accordance with recommended practice for use of CSS in
other XML namespaces, such as XHTML.</p>
<p>It is also strongly suggested that SVG documents intended for
print application be authored using presentation attributes
exclusively. This implies absence of any CSS usage in documents
authored for SVG Print applications.</p>
<h3 id="pagexslfo">3.9 Relationship between XSF FO pages and SVG
Print pages</h3>
<p>The XSL style language has a concept of pages. SVG Print also
has pages. Many XSL formatters are also capable of handling SVG
graphics. How do the concepts interact, and do they overlap?</p>
<p>SVG graphics which are used as diagrams in an XML document
should not use the SVG Print page element. Although it is possible
to imagine interactive page flipping in a diagram presented online,
this would not be visible when the document was printed.</p>
<p>A typical workflow would start with an XML document (such as
DocBook or DITA) and some SVG illustrations. An XSLT stylesheet
acts on the XML to produce an XSL-FO result. The XSL-FO is then
formatted, which may produce multiple pages of laid-out text and
graphics using the XSL page mechanism. The formatted results then
need to be rendered. SVG Print is one possible output format for
the rendered pages. PDF is another alternative. Thus, the SVG used
as at the start of the workflow, as illustrations, and the SVG used
at the end of the workflow, to express the formatted result, have
different roles.</p>
<img src="images/svg-xslfo-workflow.png" alt=
"SVG Print and XSL-FO Workflow" />
<h3 id="animate">3.10 Animation and Scripting</h3>
<p>SVG Print devices do not support animation or scripting.</p>
<p>As SVG Print devices are static devices, animation cannot be
meaningfully represented. Any animations present in the SVG
document are not played. The unanimated values from before the
timeline starts will be used.</p>
<p>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 <span class="element">page</span>
element, a DOM representation of the document is unavailable. Thus
scripting is not possible.</p>
<p>The lack of animation and scripting in SVG Print is consistent
with the SVG 1.0 recommendation description of print devices.</p>
<h2 id="jobcontrol">4 Job control</h2>
<p>SVG Print allows external job control standards to be applied to
an SVG Print document. It does not mandate any job control
standard. It provides some elementary job control with the
page-orientation property and the noPrint attribute, which may be
used in the absence of more complete job control information, or
supplemental to it.</p>
<h3 id="device">4.1 Printer device control</h3>
<p>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.</p>
<h3 id="bundling">4.2 Bundling SVG files with referenced
content</h3>
<p>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.</p>
<p>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.</p>
<p>The final choice for SVG Print devices is left to vendors, the
following sections describe some available bundling options for
consideration.</p>
<h3 id="existingstds">4.3 Relationship to existing job control
standards</h3>
<p>This section describes existing standards for printing and
possible scenarios for use of SVG Print within such standards. This
section is informative and does not imply any requirement to use
such standards.</p>
<h4 id="jdf">4.3.1 JDF</h4>
<p>Job Definition Format <a href=
"http://www.cip4.org/documents/jdf_specifications/index.html">(JDF)</a>
is managed by CIP4. This is a widely used XML based standard used
in the pre-press and publishing industries.</p>
<p>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.</p>
<p>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 <a href=
"http://www.ietf.org/rfc/rfc3030.txt">RFC 3030</a>.</p>
<p>Detailed information about JDF may be found at <a href=
"http://www.cip4.org">http://www.cip4.org</a>.</p>
<h4 id="ipp">4.3.2 IPP</h4>
<p>The <a href="http://www.pwg.org/ipp/">Internet Printing
Protocol</a> (IPP) is a standard under development by the Printer
Working Group (PWG) inside the <a href=
"http://www.ieee.org">Institute of Electrical and Electronics
Engineers</a> (IEEE).</p>
<p>This standard is used to manage network connected printers over
existing Internet protocols. An SVG Print device could make use of
this standard for fetching external resources such as images
referenced inside an SVG Print document.</p>
<p>IPP also manages job related functions for print devices, and so
could be used in conjunction with or in place of JDF for network
connected printers supporting SVG Print.</p>
<h4 id="ppml">4.3.3 PPML</h4>
<p>PPML, Personalised Print Markup Language is a data format
specified by <a href="http://www.podi.org">PODi</a> (Print On
Demand Initiative). This language is designed to allow object-level
addressability and reusability for varaible data printing. PPML can
be used with existing job ticketing languages such as <a href=
"http://www.cip4.org/documents/jdf_specifications/index.html">(JDF)</a>.</p>
<p>SVG can be contained within PPML files as Content Data, either
external or internal. This data can be reused throughout the
document or can be disposalable. Using SVG within PPML is
advantageous over other graphics formats as generic XML tools can
be used to validate all of the data.</p>
<h4 id="multimime">4.3.4 Multiplex MIME</h4>
<p>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.</p>
<p>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.</p>
<h3 id="bundlexample">4.4 Examples of SVG bundled jobs</h3>
<h4 id="exmultiplex">4.4.1 Multiplex MIME encoded SVG Print
job</h4>
<pre class="example">
--MultiplexBoundary==
Content-Type: image/svg+xml

&lt;svg width="100%" height="100%"&gt;
    &lt;text x="0%" y="10%"&gt;
    Nice image below:
    &lt;/text&gt;

--MultiplexBoundary==
Content-Type: image/jpeg; name="eye.jpg"
Content-Transfer-Encoding: base64
Content-Id: &lt;foo&gt;

/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

    &lt;image x="0%" y="15%" width="5%" height="5%" xlink:href="cid:foo" /&gt;
&lt;/svg&gt;

--MultiplexBoundary==
</pre>
<h2 id="color">5 Color specification</h2>
<p>SVG Print allows color to be specified in a number of ways. All
of the sRGB color syntaxes from SVG Print 1.2 are supported. The
ICC-based color syntax from SVG 1.1 Full is also supported. New to
the SVG Print specification, <a href="#named">ICC named colors</a>
and <a href="#devcolor">device colors</a> are supported as well:
their syntax is defined below.</p>
<h3 id="sRGBcolor">5.1 sRGB colors</h3>
<p>As with SVG Tiny 1.2, colors may be specified in the sRGB
colorspace without providing a color profile. This color space,
which uuses the chromaticities of a standard TV broadcast monitor
and viewing conditions typical of an office environment, has a
reduced gamut suitable for minimising banding on 'real world'
colors at the expense of being unable to directly represent highly
saturated colors. A number of equivalent syntactic forms are
supported, as <a href=
"http://www.w3.org/TR/SVGMobile12/painting.html#colorSyntax">defined
in SVG Tiny 1.2</a>:</p>
<pre class="example">
  &lt;circle cx="200" cy="135" r="20" fill="#3b3"/&gt;
  &lt;circle cx="240" cy="135" r="20" fill="#33bb33"/&gt;
  &lt;circle cx="200" cy="175" r="20" fill="rgb(51,187,51)"/&gt;
  &lt;circle cx="240" cy="175" r="20" fill="rgb(20%,73.333%,20%)"/&gt;
</pre>
<h3 id="iccoutput">5.2 ICC colors</h3>
<p>Since SVG 1.0, SVG has contained functionality for use of ICC
color profiles which define colors in a different color space than
sRGB. This functionality has been available since SVG 1.0 but for
the most part has not been well understood. SVP Print tightens the
conformance criteria for using ICC colors.</p>
<p>For example, it is possible to specify all objects in terms of
an ICC color space such as SWOP CMYK and the SVG renderer perform
all rendering of the objects entirely in the SWOP CMYK space
followed by color correction for a printer target CMYK. This render
workflow would never require conversion into and out of sRGB. An
SVG 1.0 implementation is free to support such rendering if
possible.</p>
<p>In the case where opacity is used and objects overlap a render
device must use the supplied sRGB fallback color in order to
composite objects together.</p>
<p>The implication of this is that it is possible to build an SVG
Print device (using SVG 1.0 onwards) that supports a full CMYK
pipeline via the use of ICC profiles. Such an SVG render device
must also be capable of handling a switch into the fallback render
color space (sRGB) for the overlapping portions of objects with
transparency.</p>
<p>An implementation may determine the areas of an object to render
in object's ICC color and those areas to render in its sRGB
fallback by doing object intersection calculations as a pre-render
step. An implementation could alternatviely decide render color
choice on a pixel by pixel basis during rasterisation. Such
behaviour is implementation specific and can lead to varying
rendering results from different implementations at the borders of
overlapping areas when using ICC colors.</p>
<h3 id="named">5.3 Named color</h3>
<p>SVG Print introduces the ability to use so-called 'named' or
'spot' colors. Named colors are used in many print applications and
are supported in SVG Print through the use of ICC named color
profiles.</p>
<h4 id="iccnamed">5.3.1 Use of the ICC named color syntax</h4>
<p>The paint specifiers for fill and stroke include the
<span class="property">icc-named-color</span> keyword. This may be
used to look up colors by their name. For example in graphic arts
workflows it is common to use Pantone&Acirc;&reg; color names for
specifying paint on objects. The <span class=
"property">icc-named-color</span> keyword may be used for such
workflows.</p>
<h4 id="iccnamedmanage">5.3.2 ICC named color profile
management</h4>
<p>An SVG 1.2 file may specify ICC named color profiles via use of
the <span class="element">color-profile</span> element.</p>
<p>The ICC specification indicates that named color profiles must
contain a PCS (Profile Connection Space) representation and can
optionally contain a device representation for each named color. An
implementation may support device representations of ICC named
colors, however that support is device specific and should be
managed outside of the SVG file itself by use of some form of job
ticket information.</p>
<h4 id="namedexample">5.3.3 Example of named color usage</h4>
<pre class="example">
&lt;svg width="210mm" height="297mm"
    xmlns="http://www.w3.org/2000/svg" version="1.2" referenceDirection="backwards"&gt;
    &lt;pageSet&gt;
        &lt;page&gt;
        &lt;color-profile name="MyColors"
                           xlink:href="CompanyColors.icm"/&gt;
            &lt;text x="50mm" y="85mm"
                font-family="MyCompanyLogoFont" font-size="12"
                color="rgb(255,12,13) icc-named-color(MyColors, logo_color)"&gt;
                MyCompany logo.
            &lt;/text&gt;
        &lt;/page&gt;
    &lt;/pageSet&gt;
&lt;/svg&gt;
</pre>
<h3 id="devcolor">5.4 Device color specification</h3>
<p>SVG 1.2 includes a number of features aimed at device specific
color management. These features are intended for closed, non
colormanaged workflows where the content generation tool would have
specific knowledge of the press setup. The device specific
functionality available via the <span class=
"element">deviceColor</span> attribute is intended to support such
closed workflows for better control of ink deposition on specific
target devices.</p>
<h4 id="deviceelement">5.4.1 Use of the <span class=
"element">deviceColor</span> element</h4>
<p>SVG Print introduces the <span class=
"element">deviceColor</span> element as a further extension to
allow the generation of device specific SVG Print files whilst
supporting generic SVG viewer display by mandating all objects be
specified with an appropriate sRGB fallback color. The <span class=
"element">deviceColor</span> element removes the requirement for
use of ICC profiles as an alternate color specifier.</p>
<h4 id="devicexample">5.4.2 Example of device specific color
usage</h4>
<p>The <span class="element">deviceColor</span> element is used to
specify device specific color information for the target device. It
is used in conjunction with the <span class=
"property">device-color</span> keyword when specifying object paint
color.</p>
<p>The following example illustrates the use of <span class=
"element">deviceColor</span>.</p>
<pre class="example">
&lt;svg xmlns="http://www.w3.org/2000/svg" version="1.2"
     xmlns:xlink="http://www.w3.org/1999/xlink" &gt;

  &lt;defs&gt;
     &lt;!-- describe a particular output device, the components happen to be
          Cyan, Magenta, Yellow, Black, Silver, Gray, Green --&gt;
     &lt;deviceColor name="device-inks"
                  xlink:href="http://www.example.com/pressInks"
                  numComponents="6" /&gt;
  &lt;/defs&gt;

  &lt;text x="100" y="150" font-family="Verdana" font-size="35"
        fill="rgb(22,33,44) device-color(device-inks, 11,55,66,77,0,0,88)" &gt;

     Hello humans, we come in peace.

  &lt;/text&gt;

&lt;/svg&gt;
</pre>
<h2 id="references">6 References</h2>
<dl>
<dt id="SVG12Full">SVG12</dt>
<dd><strong>Scalable Vector Graphics (SVG) 1.2
Specification</strong>, Dean Jackson editor, W3C, 27 October 2004
(Working Draft). See <a href=
"http://www.w3.org/TR/2004/WD-SVG12-20041027/">http://www.w3.org/TR/2004/WD-SVG12-20041027/</a></dd>
<dt id="SVG12Requirements">SVG12Reqs</dt>
<dd><strong>SVG 1.1/1.2/2.0 Requirements</strong>, Dean Jackson
editor, W3C, 22 April 2002 (Working Draft). See <a href=
"http://www.w3.org/TR/2002/WD-SVG2Reqs-20020422/">http://www.w3.org/TR/2002/WD-SVG2Reqs-20020422/</a></dd>
<dt id="SVGPrintRequirements">SVGPrintReqs</dt>
<dd><strong>SVG Printing Requirements</strong>, Jun Fujisawa, Lee
Klosterman Craig Brown, Alex Danilo editors, W3C, 18 February 2003
(Working Draft). See <a href=
"http://www.w3.org/TR/2003/WD-SVGPrintReqs-20030218/">http://www.w3.org/TR/2003/WD-SVGPrintReqs-20030218/</a></dd>
<dt id="SVG12Print">SVG12Print</dt>
<dd><strong>SVG Print 1.2</strong>, Alex Danilo, Craig Northway, Andrew
  Shellshear, Anthony Grasso, Chris Lilley editors, W3C, 21 December 2007 (Working Draft). See <a href=
"http://www.w3.org/TR/2007/WD-SVGPrint12-20071221/">http://www.w3.org/TR/2007/WD-SVGPrint12-20071221/</a></dd>
</dl>
</body>
</html>