index.html 30.9 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>
    <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:">
	    &lt;fujisawa.jun@canon.co.jp&gt;
	  </a>
	  <br />
	  Lee Klosterman (HP)
	  <a href="mailto:">
	    &lt;lee_klosterman@hp.com&gt;
	  </a>
	  <br />
	  Craig Brown (Canon)
	  <a href="mailto:cmb@research.canon.com.au">
	    &lt;cmb@research.canon.com.au&gt;
	  </a>
	  <br />
	  Alex Danilo (Canon)
	  <a href="mailto:alex@research.canon.com.au">
	    &lt;alex@research.canon.com.au&gt;
	  </a>
	</dd>
      </dl>

      <p class="copyright"><a
      href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">
      Copyright</a> &#xa9; 2003 <a href="http://www.w3.org/"><acronym
      title="World Wide Web
      Consortium">W3C</acronym></a><sup>&#xae;</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&reg;), 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&reg;.
	    </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 &lt;glyph&gt; 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&icirc;t B&eacute;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>&#34276;&#27810; &#28147; (FUJISAWA Jun), Canon</li>
	  <li>Rick Graham, BitFlash</li>
	  <li>Vincent Hardy, Sun Microsystems Inc.</li>
	  <li>&#31471;&#23665; &#36020;&#20063; (HAYAMA Takanari), KDDI Research Labs</li>
	  <li>Lofton Henderson, OASIS</li>
	  <li>&#30707;&#24029;&#38597;&#24247; (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>&#23567;&#26519; &#20124;&#20196; (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>&#27700;&#21475; &#20805; (MINAKUCHI Mitsuru), Sharp Corporation</li>
	  <li>Luc Minnebo, Agfa-Gevaert N.V.</li>
	  <li>&#23567;&#37326; &#20462;&#19968;&#37070; (ONO Shuichiro), Sharp Corporation</li>
	  <li>Antoine Quint, Fuchsia Design (formerly of ILOG)</li>
	  <li>&#30456;&#33391; &#27589; (SAGARA Takeshi), KDDI Research Labs</li>
	  <li>Brad Sipes, ZOOMON AB</li>
	  <li>Peter Sorotokin, Adobe Systems Inc.</li>
	  <li>&#19978;&#30000; &#23439;&#39640; (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>