WD-SVGReq-19981029 51.1 KB

Raw Blame History Permalink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
            "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
  <META NAME="GENERATOR" CONTENT="Adobe PageMill 3.0 Win">
  <META NAME="POST-GENERATOR" CONTENT="hand working and validator tool">
  <TITLE>Scalable Vector Graphics (SVG) Requirements</TITLE>
  <meta name="RCS-Id"
  content="$Id: WD-SVGReq-19981029.html,v 1.3 1998/11/03 23:41:19 renaudb Exp $">
  <LINK rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/WD.css" type="text/css">

  <STYLE type="text/css">
    <!--
	  .DESIGNGOALS { list-style-type: upper-alpha }
	  .REQT-LEVEL0 { list-style-type: decimal; font-weight: bold }
	  .REQT-LEVEL1 { list-style-type: lower-alpha; font-weight: normal }
	  .REQT-LEVEL2 { list-style-type: lower-roman; font-weight: normal }
	  .COMMENTS { font-weight: bold; color: red } /* visual check to ensure no comments left */
	-->
  </STYLE>
</HEAD>
<BODY>
<h4 align="right"><a href="http://www.w3.org/"><img align="left"
alt="W3C" border="0" height="48" src="http://www.w3.org/Icons/WWW/w3c_home"
width="72"></a>WD-SVGReq-19981029</h4><br clear="all">

<H1 style="text-align: center; margin-top: 1em">Scalable Vector Graphics (SVG) Requirements</H1>

<H3  style="text-align: center">W3C Working Draft, 29 Oct 1998</H3>


<DL>
  <DT>This version:
  <DD><a href="http://www.w3.org/TR/1998/WD-SVGReq-19981029">http://www.w3.org/TR/1998/WD-SVGReq-19981029</a>
  <DT>Latest version:
  <DD><a href="http://www.w3.org/TR/WD-SVGReq">http://www.w3.org/TR/WD-SVGReq</a>
  <DT>Previous (member only) version:
  <DD><a href="http://www.w3.org/Graphics/SVG/Group/1998/10/SVGReq-981027"
  class="member">http://www.w3.org/Graphics/SVG/Group/1998/10/SVGReq-981019</a>
  <DT>Editor:
  <DD><A HREF="mailto:jferraio@adobe.com">Jon Ferraiolo</A>, Adobe
  Systems Incorporated
</DL>

<H2>Status of this document</H2>

<P>This document is a work in progress representing the current consensus of the W3C Scalable
Vector Graphics Working Group. This draft of the SVG Requirements document
has been approved by the SVG working group to be posted for review by W3C members and
other interested parties. It is the first public review draft of this document.
Publication as a working draft does not imply
endorsement by the W3C membership.</p>

<P>Review comments from the public should be sent to <A HREF="mailto:www-svg@w3.org">www-svg@w3.org</A>,
which is an automatically <a href="http://lists.w3.org/Archives/Public/www-svg/">archived</a>
 email list. Information on how to subscribe
to public W3C email lists can be found at <A HREF="http://www.w3.org/Mail/Lists">http://www.w3.org/Mail/Request</A>.</P>

<H2>Introduction</H2>

<P>The W3C has chartered a Scalable Vector Graphics working group
to produce a specification for an SVG format,
written as a modular XML tagset and usable as an XML namespace,
which can be widely implemented in browsers and authoring tools
and which is suitable for widespread adoption
by the content authoring community
as a replacement for many current uses of raster graphics.</P>

<P>This will mean that the graphics in Web documents will be
smaller, faster, more interactive, and
be displayable on a wider range of device resolutions
from small mobile devices through office computer monitors
to high resolution printers. This will be a significant advance
in Web functionality. Interoperability, both in multiple browsers
across multiple platforms and in multiple authoring tools (both read and write),
is a prime focus.</P>

<P>The SVG working group decided to solicit public review and
feedback at the earliest possible point to best ensure that SVG
meets the Web community's needs for a vector graphics language
specification. This document reflects early SVG working group
discussions on what SVG should and should
not be. The working group has not reached consensus on all topics,
so the document below sometimes describes particular features
as open issues that are still under discussion.</P>

<P>This document lists both SVG Design Goals and SVG Detailed Requirements.
The SVG Design Goals describe the high-level objectives which
SVG should attempt to achieve. These design goals should also
act as the criteria by which proposed features are judged. The
SVG Detailed Requirements contains the actual list of proposed
features.</P>

<P>A first draft of the detailed specification for SVG will be made available a couple
of months after the posting of this requirements document for public review. The
specification will be developed largely by looking at:</P>

<UL>
  <LI>the design goals and detailed requirements that are contained
  in this document
  <LI>review comments on this document from public feedback, invited experts
  and working group members
</UL>


<P>The home page for the  W3C graphics activity is
<A HREF="http://www.w3.org/Graphics/Activity">http://www.w3.org/Graphics/Activity</A>.</P>


<hr>

<H2>Table of Contents</H2>

<H3><A HREF="#SVGDesignGoals">SVG Design Goals</A></H3>

<DIV class="DESIGNGOALS">
<H4><A href="#DGOpenSpecification">Open specification</A></H4>
<H4><A href="#DGWidelyImplemented">Widely implemented and supported</A></H4>
<H4><A href="#DGRelationshipOther">Relationship to other Web standards efforts</A></H4>
<H4><A href="#DGGraphicFeatures">Graphics features</A></H4>
<H4><A href="#DGInteractivityDynamism">Interactivity and Dynamic Behaviors</A></H4>
<H4><A href="#DGInterchangeFeatures">Interchange features</A></H4>
</DIV>

<H3><A HREF="#SVGDetailedRequirements">SVG Detailed Requirements</A></H3>


<H4><A href="#DRGeneralRequirements">General requirements</A></H4>

<OL class="REQT-LEVEL0">
  <LI><A href="#DRConsistent">Consistent visual results and behaviors across implementations</A>
  <LI><A href="#DRElegant">Elegant, uniform, complete and consistent</A>
  <LI><A href="#DRPackaging">Packaging</A>
  <LI><A href="#DRPerformance">Performance</A>
  <LI><A href="#DRAlternateRepresentations">Alternate representations</A>
  <LI><A href="#DRBackwardCompatibility">Backward compatibility</A>
  <LI><A href="#DRInternational">Well internationalized</A>
  <LI><A href="#DRAccessibility">Accessibility features</A>
</ol>

<H4><A href="#DRGraphicalFacilities">Graphical facilities</A></H4>

<OL class="REQT-LEVEL0">
  <LI value="9"><A href="#DRShapes">Vector graphics shapes</A>
  <LI><A href="#DRText">Text data</A>
  <LI><A href="#DRImages">Image data</A>
  <LI><A href="#DRColor">Color support</A>
  <LI><A href="#DRTransparency">Transparency support</A>
  <LI><A href="#DRLayeringGrouping">Grouping and layering</A>
  <LI><A href="#DRTemplateObjects">Template objects/symbols</A>
  <LI><A href="#DRFillOptions">Fill options</A>
  <LI><A href="#DRStrokeOptions">Stroke options</A>
  <LI><A href="#DRTransformations">Transformations</A>
  <LI><A href="#DRCoordinateSystems">Coordinate systems, relationship to CSS positioning</A>
  <LI><A href="#DRAntialiasing">Antialiasing</A>
  <LI><A href="#DRStencilingAndMasking">Stenciling and masking</A>
  <LI><A href="#DRFilterEffects">Client-side filter effects such as shadowing</A>
  <LI><A href="#DRCompositing">Compositing</A>
  <LI><A href="#DRCSSSupport">CSS support</A>
  <LI><A href="#DRReferencePoints">Connectable reference points</A>
  <LI><A href="#DRParameterization">Parameter substitution and formulas</A>
  <LI><A href="#DRPrintControl">Print control</A>
</ol>

<H4><A href="#DRInteraction">Interaction</A></H4>

<OL class="REQT-LEVEL0">
  <LI value="28"><A href="#DRZoomAndPan">Zoom and pan</A>
  <LI><A href="#DRLinks">Links</A>
  <LI><A href="#DREventHandling">Event handling</A>
  <LI><A href="#DRSelection">Object selection, clipboard</A>
  <LI><A href="#DRDOMAccess">DOM access</A>
  <LI><A href="#DRAnimation">Animation</A>
  </ol>

<H4><A href="#DRMiscellaneous">Miscellaneous</A></H4>

<OL class="REQT-LEVEL0">
  <LI value="34"><A href="#DRPrivateData">Inclusion of private data (metadata)</A>
  <LI><A href="#DRExtensibility">Extensibility</A>
  <LI><A href="#DREmbedded">Embedded fonts and images</A>
</OL>

<hr>

<h1><A NAME="SVGDesignGoals"></A>SVG Design Goals</h1>

<P>The following are the Design Goals for SVG. Besides providing
a set of high-level objectives for SVG, these goals act as the
criteria by which proposed features are judged. Thus, the features
list shown below under SVG Detailed Requirements should reflect
the higher-level goals listed here.</P>

<P>These SVG Design Goals are not listed in any particular order.
It is recognized that some of the goals might conflict or be unachievable
and that tradeoffs will need to be made.</P>


<A NAME="DGOpenSpecification"> </A>
<H2>Open specification</H2>
<OL class="DESIGNGOALS">
  <LI>The specification should be controlled by the members in the
  W3C, not by a single vendor. Thus, the specification should not
  subject to sudden change by a single vendor.
  <LI>The specification
  should be vendor neutral and thus should not contain features
  biased towards a particular vendor.
</ol>

<A NAME="DGWidelyImplemented"> </A>
<H2>Widely implemented and supported</H2>

<OL class="DESIGNGOALS">
  <LI value="3">SVG should be a standard feature in Web browsers
  <LI>Implementations of SVG should be consistent so that the same
  visual results and behaviors exist in all conforming SVG processors.
  <LI>There should not be subset problems and incompatible generator/reader
  sets. Thus, there should be a single language specification,
  not a set of layered language specifications.
  <LI>There should be widespread support in authoring applications and related tools
  <LI>To promote widespread adoption and support, SVG should be specified to be
  as basic and simple as possible while still providing necessary features
  to satisfy the needs of graphics on the Web.
  While the chief goal is to aim at the middle ground,
  a basic and simple feature set will allow it to be used on devices
  with a wide range of resolutions and capabilities,
  from small mobile devices through office computer monitors to high resolution printers.
  <LI>Straightforward generation via hand-authoring with a text editor
  or server-side scripts (e.g., CGI)
  <LI>SVG should be as self-contained as possible.
  While SVG should leverage and be compatible with other W3C work,
  it should attempt to do so without introducing
  excessive dependencies on other specifications.
  <LI>Ready availability to the casual implementor is desirable
  <LI>Reference source code is desirable
</ol>

<A NAME="DGRelationshipOther"></A>
<H2>Relationship to other Web standards efforts</H2>

<OL class="DESIGNGOALS">
  <LI value="12">Defined as an application of XML
  <LI>Compatible with and/or leverages other relevant standards
  efforts, including XML namespaces, XML links (XLink), DOM, CSS, XSL and
  metadata.For example:
    <UL>
	  <LI>the elements and attributes of an SVG
          drawing should be scriptable via the DOM
	  <LI>text should be expressed
          as XML character data so that it can be found by search engines
      <LI>attributes which make
          sense to be part of a style should be expressed in CSS
    </UL>
   The SVG working group will need to coordinate proactively
   with other working groups when it is more appropriate to meet the SVG
   requirements through modifications to other Recommendations.
</ol>

<A NAME="DGGraphicFeatures"></A>
<H2>Graphics features</H2>

<OL class="DESIGNGOALS">
  <LI value="14">Complete, general-purpose Web vector graphics format that
  satisfactorily meets the graphics delivery needs for all creators
  and consumers of Web vector graphics
  <LI>Sufficiently powerful and precise to meet the needs of professional
  Web graphic designers such that they will utilize SVG instead
  of raster formats in those cases where vector graphics is a more
  natural or appropriate format
  <LI>Sufficiently powerful to meet the needs of
  business presentation and diagramming applications such that
  these drawings will be published on the Web using SVG instead of raster formats
  <LI>Feature set is rich enough such that a reasonable conversion of
  most existing standard static graphics files into SVG is possible
  <LI>Sufficiently compatible with the graphics design and
  publishing industries' feature sets and file formats
  such that there is (as lossless as possible) a straightforward mapping
  from these applications and file formats
  into SVG. The goals are to facilitate
  conversion of existing artwork into SVG, promote the creation of lots
  of compelling new SVG artwork, make it as easy as possible for the graphics design
  and publishing industries to adapt existing authoring tools, and provide for
  new SVG authoring tools.
  <LI>Compatible with the needs of non-technical persons who want
  a straightforward way to generate relatively simple graphics
  either by hand-editing or via server-based graphics generation
  (e.g., CGI scripts).
  <LI>Compatible with high-quality, efficient printing at full
  printer resolution and with reliable color
  <LI>Focused on basic foundation, presentation-level graphics
  facilities, with a critical eye toward higher-level (model-level) constructs which
  might be better suited to a higher-level standard which would sit
  on top of SVG
  <LI>The working group is investigating whether other Web standards
  (e.g., CSS, XSL, MathML, Web Schematics) could use SVG as its
  low-level rendering specification.
  (This goal has significant dependencies on other W3C initiatives such as the
  W3C Formatting Model and might change accordingly.)
  <LI>The specification for SVG should take into account the possibility of
  building a future 3D graphics specification which either sits on top of SVG
  or which is entirely independent but with a similar syntax; however, the
  SVG working group should not let itself be slowed down or constrained by 3D
  upgrade path issues.
</ol>

<A NAME="DGInteractivityDynamism"></A>
<H2>Interactivity and Dynamic Behaviors</H2>

<OL class="DESIGNGOALS">
  <LI value="24">Allows for interactive and dynamic Web pages
</ol>

<A NAME="DGInterchangeFeatures"></A>
<H2>Interchange features</H2>
<OL class="DESIGNGOALS">
  <LI value="25">Suitable as a platform-independent graphics exchange format
  <LI>Mechanisms for inclusion of application-specific (or industry
  specific) private data which would facilitate use of SVG as a
  application-specific (or industry-specific) native file format
  for authoring applications
  <LI>Capable of use as a print metafile: sufficiently expressive
  such that a higher-level print metafile XML grammar could use
  SVG for its page imaging operators
</OL>

<HR ALIGN=LEFT>

<h1><A NAME="SVGDetailedRequirements"></A>SVG Detailed
Requirements</h1>

<P>The following is the detailed list of required features and
capabilities in SVG. Items which are already listed as a Design
Goal are not repeated here. It is recognized that some of these
requirements might conflict or may not be possible.</P>


<A NAME="DRGeneralRequirements"></A>
<H2>General requirements</H2>

<OL class="REQT-LEVEL0">

  <LI><A NAME="DRConsistent"></A>Consistent visual results and behaviors across implementations
    <OL class="REQT-LEVEL1">
	  <LI>The specification needs to be complete and unambiguous
      <LI>The goal is to have at least two independent implementations
          each of SVG viewers and SVG generators under development as the
          specification is defined to help find and remove ambiguities
		  from the specification.
      <LI>An extensive conformance test suite needs to be delivered
          in conjunction with the final specification.
	</OL>


  <LI><A NAME="DRElegant"></A>Elegant, uniform, complete and consistent
    <OL class="REQT-LEVEL1">
	  <LI>Wherever possible, all graphical attributes and
	      operations should be available to all object types. For example,
		  if 2x3 transformation matrices are available for shape objects, then
		  2x3 transformation matrices should also be available for
		  text and image objects.
	</OL>


  <LI> <A NAME="DRPackaging"></A>Packaging
    <OL class="REQT-LEVEL1">
	  <LI>Stand-alone packaging: Compatible with the need of stand-alone
	  graphics authoring packages. It should be possible
	  for a graphics authoring application to save a stand-alone SVG
	  file. (&quot;Stand-alone packaging&quot; means that an SVG file
	  is saved as a separate, self-contained file, probably with a
	  .svg extension on platforms where the extension is important.)
	  <LI>Fragment packaging: Compatible with the need of consolidated
	  full-page Web authoring packages which would like to author/deliver
	  full pages of XML with optional vector graphics elements
	  interspersed as isolated components within the page. (&quot;Fragment
	  packaging&quot; means that snippets of SVG would appear inside
	  the content of a parent XML grammar. For example, a picture
	  of an arrow expressed in SVG might appear inline within an XML
	  file. The expected way this would be achieved would be by referencing
	  the SVG namespace within the XML file.)
	</OL>


  <LI><A NAME="DRPerformance"></A>Performance
    <OL class="REQT-LEVEL1">
      <LI>Reasonable display performance on commonly used end-user
          machines
      <LI>Highly efficient representation to minimize download times
	    <OL class="REQT-LEVEL2">
		  <LI>The working group should investigate abbreviation schemes
		      (particularly for path data) to minimize file sizes
		  <LI>The working group should also collaborate with other
			  working groups, such as the XML working group.
			  on binary compression alternatives.
	    </OL>
      <LI>Streamable (i.e., support progressive rendering)
	  <LI>Simple primitives (e.g., lines) should exhibit fast performance
	</OL>


  <LI><A NAME="DRAlternateRepresentations"></A>Alternate representations
    <OL class="REQT-LEVEL1">
	  <LI>The working group should investigate
      the issue of alternative representations in the form of text strings
	  or image data. Alternate representations as text or images
	  might provide a good answer for backwards compatibility in some cases
	  or provide for a faster display option for some drawings.
	  Alternate text strings would be particularly
	  valuable to visually impaired users.</ol>

  <LI><A NAME="DRBackwardCompatibility"></A>Backward compatibility
    <OL class="REQT-LEVEL1">
	  <LI>The working group should develop a reasonable
      backward compatibility strategy for when a user attempts to view
	  an SVG drawing in a browser which doesn't yet support SVG.</ol>

  <LI><A NAME="DRInternational"></A>Well internationalized
     <OL class="REQT-LEVEL1">
	  <LI>By virtue of being written in XML, SVG will already have
      baseline internationalisation capability (Unicode characters,
       language tagging). The working group will collaborate with
       the I18N working group to ensure that SVG is suitable for
       worldwide Web graphics.</ol>

  <LI><A NAME="DRAccessibility"></A>Accessibility
  <OL class="REQT-LEVEL1">
	  <LI>The working group should ensure that
  adaptive interfaces for
        people with disabilities are fully supported, and that mapping
        SVG content to these contexts is easy and graceful.
        </ol>
</ol>

<H2><A NAME="DRGraphicalFacilities"></A>Graphical facilities</H2>

<OL class="REQT-LEVEL0">

  <LI value="9"><A NAME="DRShapes"></A>Vector graphics shapes
     <P style="font-weight: normal">
     (Note: in the remainder of this document,
      the terms "vector graphic shape" will be abbreviated to
	  "shape" or "shape objects")</P>
    <OL class="REQT-LEVEL1">
      <LI>Path data
        <OL class="REQT-LEVEL2">
          <LI>Paths can be made up of any combination of the following:
            <UL>
              <LI>Straight line segments
              <LI>Cubic bezier curved segments
              <LI>Quadratic bezier curved segments
              <LI>Elliptical and circular arcs
              <LI>No other curve types (Other curve types such as
                  splines or nurbs are either technically
                  very difficult, industry-specific and/or
                  have not established themselves
                  as industry standards as much as beziers.)
            </UL>
          <LI>Compound paths (i.e., paths with donut holes) should be supported. Both
              the non-zero winding and even-odd fill rules should
              be supported in both fill and clip operations to ensure
			  compatibility with the design and publishing industries' existing
			  file formats and authoring applications. (Also, it is much easier to implement
			  these fill rules inside a renderer than it is in a file format converter.)
        </OL>

      <LI>A set of predefined shape types such as rectangles, rounded rectangles,
		   circles and ellipses should
		   be available so that simple objects can be defined without having
		   to learn bezier mathematics. The exact list of predefined object types
		   has not been decided yet.
      <LI>Any shape can be filled, stroked or used as a clipping path and/or mask.
          (See <A href="#DRFillOptions">Fill options</A>,
		  <A href="#DRStrokeOptions">Stroke options</A> and
		  <A href="#DRStencilingAndMasking">Stenciling and masking</A>, below.)
    </OL>


  <LI><A NAME="DRText"></A>Text data
    <OL class="REQT-LEVEL1">
	  <LI>Text strings should be expressed as XML character data
	      which could be marked up with arbitrary XML name spaces. (Text strings
		  as XML character data allow search engines to find the strings.)
      <LI>All text/font attributes from CSS should be supported. Complete support for
		  CSS is what the Web community will expect.
	      (See <A href="#DRCSSSupport">CSS support</A>, below)
      <LI>It is clear that precise text sizing/positioning is a requirement for the
	      graphics design community.
		  Thus, SVG should allow for precise control of text sizing, positioning,
          rotation, and skewing on a character-by-character basis. In particular,
          the working group should look to see if this feature could be packaged as
		  to provide for precise text on a path.
      <LI>It is clear that precise control of fonts and glyphs is a requirement for the
	      graphics design community.
		  It should be possible to achieve precise control of the exact font and the exact glyphs
          within a given font to use for a given character sequence so that
          graphic artists have a way to ensure that the end user sees what was
          intended
      <LI>The same fill/stroke/clip/mask capabilities that can be used with
          vector data should also be available to text data. For example,
          it should be possible to fill a text string with a gradient or
          stroke it with a dashed line pattern. This is a widely used
		  feature in the graphics design world and is required for compatibility
		  with existing graphics content.
	  <LI>The working group hasn't investigated yet whether it is advisable to
	      provide a capability to automatically position a text string relative
		  to another graphical element (e.g., automatically centering a text string
		  within a rectangle). It is clear that such a feature would be a great
		  convenience for hand-coders of certain types of drawings, such as diagrams.
		  The working group
		  should investigate whether there is an easy-to-use (for a hand-coder)
		  yet robust and elegant way of achieving this.
	  <LI>Having a text string determine the dimensions of a parent graphical object
	      (e.g., a box is drawn to fit around a text string) is too high-level of
		  a construct and is not planned for version 1 of SVG.
	  <LI>Adding a text-on-a-path capability to SVG is still under consideration.
	      The working group recognizes that there are many
		  technical complexities which make it difficult to design the
		  feature in such a way that it will be both sufficiently powerful and
		  sufficiently compatible with the needs of various authoring scenarios.
    </OL>


  <LI> <A NAME="DRImages"></A>Image data
    <OL class="REQT-LEVEL1">
      <LI>The same image formats available to HTML should be available to SVG
      <LI>The working group hasn't had time yet to address the issue of color
	      management on image data. The goals will be to:
		<OL class="REQT-LEVEL2">
		  <LI>achieve compatibility with how other specifications (e.g., HTML) perform
		      color management on image data
		  <LI>(just like the rest of SVG) take full advantage of color management systems
		      when supported by the browser and/or the platform operating system
			  (see <A href="#DRColor">Color support</A> below)
		  <LI>if different ICC profile are specified both as an attribute on an image
		      and embedded within the image, the attribute should win
		</OL>
    </OL>


  <LI><A NAME="DRColor"></A>Color support
    <OL class="REQT-LEVEL1">
      <LI>All colors need to be specified in the sRGB color space for compatibility
	      with other Web standards.
      <LI>It is clear that reliable color is important to both end users and
	      Web content creators.
		  sRGB does not answer all precise color needs, and most desktop platforms
	      support the more complete ICC-based color management system.
		  Thus, an alternative ICC-based color representation should be available for all
          color attributes. If the SVG processor supports color management, then
          the ICC color takes precedence over the sRGB color.
	  <LI>There has been little discussion so far on sport color support. Spot
      colors might be possible by specifying then using ICC profiles (perhaps via
      a  Named Color profile), or by storing spot color information as private
      data (metadata) in the SVG file.
    </OL>


  <LI><A NAME="DRTransparency"></A>Transparency support

  <p style="font-weight: normal">Transparency support is becoming
  commonplace in authoring applications and
   is widely used today in Web animations.
    <OL class="REQT-LEVEL1">
      <LI>Many existing authoring applications achieve transparency by adding an
	      opacity property wherever a color property is allowed.
		  For compatibility with these
		  applications, and because this represents a good technical solution
		  to many transparency needs, wherever a color property is allowed,
		  there will be a corresponding opacity property which indicates how
		  transparent a given object/component/attribute
          should be when blended into its background
      <LI>In group opacity, the collection
          of objects that makes up a group is (in effect) drawn into a
          temporary area in memory, and then the temporary area is blended
          as a single unit into the background graphics.
          Group opacity is necessary when you have an aggregate object such as a automobile
          which is drawn as a collection of overlapping, opaque components
          (e.g., the hubcap might be an opaque circle that is drawn on top of
          an opaque tire) and you want to blend that object as a unit into
          the background. Group opacity is a requirement for many animation
		  applications and has utility with static graphics also.
		  It is straightforward to implement, particularly once you have
		  support for transparent image objects, which is needed for GIF and PNG.
		  It is infeasible to achieve these effects without this feature.
		  Thus, group opacity should be supported in SVG.
     <LI>The working group decided that identification of
	      a transparency/blue-screen/chromaKey
	      color will not be supported for shapes and text because the opacity
		  features are sufficient. However, the transparency color feature
		  that exists in image file formats such as GIF and PNG will be supported.
	  <LI>See <A href="#DRCompositing">Compositing</A>, below.

    </OL>


  <LI> <A NAME="DRLayeringGrouping"></A>Grouping and layering
    <OL class="REQT-LEVEL1">
      <LI>There needs to be an ability to define groups (i.e., collections) of objects
	      to allow for convenient access for scripting applications.
	      Groups should have the following attributes (among others), all of
		  which are accessible and/or controllable via scripting:
		<OL class="REQT-LEVEL2">
		  <LI>Unique ID
		  <LI>z-index for explicit layering
		  <LI>visibility
		  <LI>transformations
		  <LI>opacity
		</OL>
	  <LI>Implicit layering: unless an explicit z-index value is provided,
	      objects will be drawn
	      bottom-to-top in the order which they appear in the input stream.
		  This strategy is compatible with most popular graphics
		  file formats.
	  <LI>Explicit layering: objects or collections of objects can be
	      assigned an explicit z-index value, which takes precedence over
		  the implicit bottom-to-top drawing order. (The bottom-to-top drawing order of
		  objects with the
		  same z-index relative to each other is the the order in which they
		  appear in the input stream.) This explicit layering is a requirement
		  for achieving certain types of animation effects.
    </OL>


  <LI><A NAME="DRTemplateObjects"></A>Template objects/symbols
    <OL class="REQT-LEVEL1">
	  <LI>There should be a capability for defining template objects that can
	      be instantiated multiple times with different attributes.
	  <LI>The template objects should be able to establish a full set of
	      default attributes, and the instantiated objects should be
		  able to override any of these default attriubutes.
    </OL>


  <LI><A NAME="DRFillOptions"></A>Fill options (i.e., painting the interior of a shape or text object)
    <P style="font-weight: normal">
          The following fill options should be available:
	</P>

     <OL class="REQT-LEVEL1">
	  <LI>Solid-color fill (see <A href="#DRColor">Color support</A> above)
	  <LI>Gradients
	    <OL class="REQT-LEVEL2">
		  <LI>Multiple gradient stops will be supported (not just two)
		  <LI>Both linear and radial gradients will be supported
		  <LI>It is still an open issue within the working group
		      whether additional gradient types should be supported.
			  Examples: conical, elliptical, square, rectangular,
			  Gouraud shaded triangle and  rectangular meshes.
		  <LI>Gradients should allow for both a linear ramp between
		      gradient stops and a well-defined sigma function for
			  the calculation of the intermediate colors between the
			  stops.
		  <LI>For all gradients, the specification should provide details
		      for the exact behavior of the gradient ramp. If there is
			  a disagreement about what the gradient ramps should be,
			  priority should be given to: (1) making sure the gradient
			  ramp rules are consistent with real-world lighting effects,
			  (2) retaining compatibility with as much existing content
			  as possible (with a bias towards existing content whose
			  users really care about how their gradients look)
		  <LI>The suggestion has been made to allow for substitution of
		      a different color table for use with a given gradient.
			  (The color stop positions stay the same, but the colors
			  used change.) This suggestion hasn't been discussed yet
			  in the working group.
		</OL>

	  <LI>Patterns (i.e., tiled object fill)
	    <OL class="REQT-LEVEL2">
		  <LI>Any objects (i.e., shapes, images, text) can be
		      used to fill any other objects
		  <LI>When objects are used to fill other objects, parameters
		      can be set to achieve tiling effects.
		  <LI>The tiling options
			  should be at least as capable as those found in the file
			  formats used by the design and publishing industries to
			  ensure compatibility
			  with existing artwork and authoring applications.
		</OL>
	  <LI>Other fill styles - The working group hasn't decided yet whether other fill styles
		      such as fractal patterns are appropriate.
	  <LI>Custom fill styles - See <A href="#DRExtensibility">Extensibility</A>, below.
    </OL>


  <LI><A NAME="DRStrokeOptions"></A>Stroke options (i.e., drawing the outline of a shape or text object)
     <OL class="REQT-LEVEL1">
	  <LI>The same attributes available for filling an object
	      (see <A href="#DRFillOptions">Fill options</A>, above)
	      should be available to stroke an object. For example,
		  you should be allowed to stroke with a pattern.
	  <LI>The set of stroke options should be at least as capable as the stroke options in
	      the file formats used by the design and publishing industries
	    <OL class="REQT-LEVEL2">
		  <LI>Arbitrary, continuous values for line width
		  <LI>The working group hasn't reached consensus yet on whether SVG should
		  support hairlines
		  (i.e., instructing the device to draw the thinnest possible line)
		  <LI>User-defined dash patterns and initial phase offset
		  <LI>Caps, joins and miterlimits
		</OL>
	  <LI>Arrowheads and polymarkers
	    <OL class="REQT-LEVEL2">
		  <LI>There should be a small set of predefined arrowheads
		  <LI>Arrowheads are optional and can be placed at the start and/or end of path objects
		  <LI>The working group should investigate the possibility of providing
		      for custom "arrowheads" at the start and/or end of a path object
			  which are defined by referencing a different graphical object or group.
			  This capability would solve the following needs:
			<UL>
			  <LI>Diagramming applications might use arrowheads extensively, but the
			      predefined arrowheads might not be satisfactory
			  <LI>Graphic designers who want to attach arrowheads to drawings will want
			      complete control of the visual characteristics of their arrowheads
			  <LI>This feature can be leveraged to provide a polymarker capability for
			      applications such as scatter diagrams
			</UL>
		</OL>
    </OL>


  <LI> <A NAME="DRTransformations"></A>Transformations
     <OL class="REQT-LEVEL1">
	  <LI>Arbitrarily nested 2x3 matrix transformations should be available.
	      This facility is necessary to ensure compatibility with existing
		  artwork and authoring tools.
	    <OL class="REQT-LEVEL2">
		  <LI>2x3 matrices are sufficient to achieve any types of translation,
		      scaling, rotation and skewing
		  <LI>Transformation matrices can be nested to an arbitrary depth. A
		      given transformation matrix is concatenated with the transformation
			  matrices of all parent objects.
	    </OL>
	  <LI>In the spirit of making SVG reasonably easy to use for content
	      creators who would have difficulty constructing 2x3 matrices,
		  SVG should offer an alternative set of simpler transformation attributes
		  (e.g., rotation=, scale=). The SVG specification, however, needs to
		  defined unambiguously what should happen if both the simpler
		  transformation attributes and a 2x3 transformation matrix is provided.
	  <LI>These transformations should apply to all object types (shapes,
	  images and text)  in a uniform and consistent manner

	  <LI>Transformed objects should have the option of exhibiting true scalability
	      (where all attributes should scale uniformly, and linewidths, images and
		  text should scale along with the sizes of the shapes). Additionally,
		  transformed objects should also have the option of selective
		  scalability such that certain attributes (e.g., stroke size and textsize)
		  are invariant.
    </OL>


  <LI><A NAME="DRCoordinateSystems"></A>Coordinate systems, relationship
  to CSS positioning
     <OL class="REQT-LEVEL1">
	  <LI>SVG should use CSS positioning for establishing a viewport for an
	      outermost SVG element, such as an &lt;svg&gt;...&lt;/svg&gt;
	      complete drawing or an SVG fragment within an XML Web page.
	  <LI>SVG will support local user coordinates
	  <LI>Real number values (i.e., an integer followed by a possible
	  decimal fractional component) should be possible for all
	  appropriate attributes and coordinates.
		  The language definition itself should not inhibit infinite precision.
    </OL>


  <LI><A NAME="DRAntialiasing"></A>Antialiasing
     <OL class="REQT-LEVEL1">
	   <LI>It is clear that the graphics design community not only wants
		   antialiasing to be available, but also wants to have the ability to turn
		   antialiasing on/off on an object basis in order to achieve precise
		   control of the rendering and possibly to control drawing speed.
		   Thus, there will be an antialias control attribute on each graphics
		   object in SVG.
	   <LI>Antialiasing adds a significant burden to the casual implementor
	       and isn't a requirement for all potential applications of SVG, such
		   as viewing CAD drawings. Thus, antialiasing control will be regarded as
		   a hint to the SVG processor, which can choose whether or not to honor
		   it. Major general-purpose implementations of SVG processors
		   such as commercial Web browsers should
		   honor and implement the antialiasing control hint.
    </OL>


  <LI> <A NAME="DRStencilingAndMasking"></A>Stenciling and masking
    <OL class="REQT-LEVEL1">
      <LI>Clipping paths
        <P style="font-weight:normal">
		Clipping paths are a commonly used feature in existing artwork and
		an integral part of all authoring products used by graphic designers.
		Clipping paths are as fundamental to the design and publishing industries'
		existing file formats and authoring tools as are nested transformation matrices.
		Clipping is relatively easy to implement in viewers using a
		raster mask approach in device space if you have code for drawing a
		filled path into an offscreen buffer. Nested clipping paths are easy to
		achieve on top of an unnested clipping path implementation by just looping
		through each parent clipping path one after another.
		The performance overhead with nested clipping paths in animation scenarios
		is probably small relative to other necessary computations (e.g, filling and stroking)
		and can be overcome on the user end by simply avoiding/minimizing the use of the feature.
		Without nested clipping paths, converters from the design and publishing industries'
		existing file formats will have a significant burden in determining how to flatten
		the nested clipping paths they encounter.
		Nested clipping paths are necessary to prevent lossless translation
		from the design and publishing industries' existing file formats.
		</P>
	    <OL class="REQT-LEVEL2">
		  <LI>Any shape or text object can be used as a hard-edge clipping path
		  <LI>Clipping paths can be nested arbitrarily to ensure compatibility with
		      existing artwork and authoring tools.
	    </OL>
	  <LI>Masks
        <P style="font-weight:normal">
		8-bit masking is a fundamental feature on all operating
		systems, and a key feature for both static and dynamic Web pages.
		</P>
        <OL class="REQT-LEVEL2">
		  <LI>Any graphics object (i.e., shape, text, or image)
		      can be used as an 8-bit alpha mask to control the alpha-compositing
			  of a different object (or group/collection of objects) into other objects
	    </OL>
    </OL>


  <LI><A NAME="DRFilterEffects"></A>Client-side filter effects such as shadowing
    <P style="font-weight:normal">
	Client-side filters provide for the possibility of significant
	file size and download time savings in many applications.
	An example is text drawn with a glow effect and a drop shadow.
	If client-side glow and drop shadow filters were available,
	then only the text string and the names of the filters would need to
	be downloaded, instead of today, where the text needs to be
	converted to a raster by the author.
	</P>
    <OL class="REQT-LEVEL1">
      <LI>SVG should include a set of built-in client-side filter effects for
	      commonly used effects such as shadowing. The definitions of these
		  effects should be unambiguous so that all implementations produce
		  the same visual results.
	  <LI>Additionally, the working group should investigate the feasibility
	      of a general filter mechanism which would allow for custom filter
		  effects to be downloaded and applied to a given graphical object
		  (see <A href="#DRExtensibility">Extensibility</A>, below)


    </OL>


  <LI><A NAME="DRCompositing"></A>Compositing
    <P style="font-weight:normal">
	Compositing means the rules by which a foreground object's colors are
	blended into a background object's colors. There are many different
	approaches to compositing. Alpha compositing (where each pixel has
	an 8-bit alpha channel which determines how opaque that pixel is)
	is the most common, but even this method has multiple variations.
	</P>
    <OL class="REQT-LEVEL1">
	  <LI>The working group needs to define standard rules for
	      how alpha compositing should work. Which color space (sRGB? Lab?)?
		  What are the exact formulas?
      <LI>The working group needs to decide whether SVG should offer
	      multiple compositing options
	      as standard features. Should SVG support all of the Porter/Duff
		  compositing options? Additionally, Photoshop offers many
		  Adjustment Layer options. Should these be supported?
	  <LI>See <A href="#DRExtensibility">Extensibility</A>, below.
    </OL>


  <LI><A NAME="DRCSSSupport"></A>CSS support
    <OL class="REQT-LEVEL1">
      <LI>All CSS text/font attributes from the most recently approved CSS recommendation
	      should be honored by all conforming SVG processors.
      <LI>The issue of CSS inheritance is still open. It is unclear that the
          standards world will have addressed how a parent XML/HTML grammar passes
          its current style table to a child grammar. Until this issue is addressed,
          the SVG working group cannot promise that version 1 of SVG will support
          the inheritance of CSS styles from a parent grammar. The working group
          should work towards achieving this highly desirable capability, however.
          Representatives from the CSS and XSL have requested working with
	      the SVG working on style sheet issues. They would like to discuss:
		<OL class="REQT-LEVEL2">
		  <LI>use either XSL or CSS stylesheets within SVG
          <LI>use stylesheets to apply properties to both the text AND graphic
              objects/assemblies within an embedded SVG component (to provide/enforce
             "house style" or common properties across all illustrations in a document).
	    </OL>
    </OL>


  <LI><A NAME="DRReferencePoints"></A>Connectable reference points
    <P style="font-weight:normal">
	Connectable reference points are useful constructs for many applications.
	In particular, diagramming applications could use connectable reference
	points to define the start and end points for lines that connect
	two different objects. The difficulty with connectable reference points
	is that they might introduce a large degree of complexity into the
	specification and the various implementations. It might be better
	to leave connectable reference points to a higher-level XML grammar which
    sits on top of SVG.
	</P>
    <OL class="REQT-LEVEL1">
      <LI>It is not a requirement for version 1 of SVG to provide for a mechanism
	      for defining connectable reference points. This is a complex issue
		  which might be better served by a higher-level XML grammar.
	  <LI>However, the working group should not exclude this as an option for
	      version 1 of SVG. If one of the working group members can come up with
		  a good proposal, then the working group should consider the proposal seriously.
	  <LI>See <A href="#DRDOMAccess">DOM access</A>, below, for more on connectable reference points.
    </OL>


  <LI><A NAME="DRParameterization"></A>Parameter substitution and formulas on coordinates
    <P style="font-weight:normal">
	Parameterized graphic objects, possibly built using a set of formulas
	to define how the object grows and stretches based on the values of
	its parameters and other aspects of the graphics, would provide for
	a powerful "intelligent graphics" capability. However, such as feature
	opens up many complex issues which might be better off in
	a higher-level XML grammar which
    sits on top of SVG.
	</P>
    <OL class="REQT-LEVEL1">
      <LI>Parameter substitution and formulas on coordinates are not requirements
	      for version 1 of SVG.
	  <LI>A simple parameter substitution strategy, however, might be easy to define,
	      simple to implement, and provide lots of value. In other words,
		  a simple parameter substitution strategy might provide 90% of the value
		  at 10% of the effort.
		  If one of the working group members can come up with
		  a good proposal, then the working group should consider the proposal seriously.
	  <LI>It is harder to conceive of a simple formula-based coordinate capability.
	      However, if someone of the working group members can come up with
		  a good proposal, then the working group should consider the proposal seriously.
    </OL>


  <LI><A NAME="DRPrintControl"></A>Ability to control whether a given object is printed.
    <OL class="REQT-LEVEL1">
      <LI>When the working group considers this feature, it should see whether
	      CSS's print control features are adequate.
    </OL>
  </ol>

<H2><A NAME="DRInteraction"></A>Interaction</H2>

 <OL class="REQT-LEVEL0">

  <LI value="28"><A NAME="DRZoomAndPan"></A>Zoom and pan
    <OL class="REQT-LEVEL1">
	  <LI>An SVG processor should support zoom and pan on graphics, with true
          scalability. Thus, all objects and attributes (including such things
	      as text and linewidths) should grow/shrink uniformly with the
	      zoom level.
	  </LI>
	</OL>


  <LI><A NAME="DRLinks"></A>Links
    <OL class="REQT-LEVEL1">
	  <LI>It should be possible to assign a link to any graphic object or group.
	  <LI>SVG should support all of the kinds of links into and out of a drawing as
	      would be appropriate. For example, it should provide for links to other views in the same file
		  or links to external media (i.e., a URL). Also, it should be possible
		  to link into a particular view within an SVG drawing.
	  <LI>As much as is appropriate, SVG should be compatible with XLink.
	  <LI>The working group discussed briefly the concept of linking into a moment
	      of time within an animation application. This should be investigated
		  by the working group as the specification is developed.
	</OL>


  <LI><A NAME="DREventHandling"></A>Event handling
     <OL class="REQT-LEVEL1">
	  <LI>It should be possible to assign event handlers to an individual
	      graphic object or group.
	  <LI>The list of event handlers should at least be as extensive as
	      what is available for HTML (e.g., mouseovers, mouseclicks).
	  <LI>Additional event handlers might prove to be valuable. For example,
	      an onzoom event handler might prove very useful to control what
		  content appears based on zoom level. The working group should
		  investigate onzoom and other possible event handlers.
	</OL>


  <LI><A NAME="DRSelection"></A>Object selection, copying/pasting to clipboard
     <OL class="REQT-LEVEL1">
	  <LI>It is highly desirable but not required that SVG viewing processors
	      have the ability to selectively copy/paste graphical elements,
		  particularly from the browser to the desktop environment.
	  <LI>The working group has not investigated yet whether it makes sense
	      to specify an object selection mechanism in SVG. However, it is
		  clear that the ability to select part of a drawing is a requirement
		  for clipboard/exchange purposes.
	  <LI>A particular detail is selecting text for the purposes of copying
	      to the clipboard. The working group hasn't discussed yet whether
		  it should be possible to select text strings (complete or partial)
		  from within an SVG processor.
	</OL>


  <LI><A NAME="DRDOMAccess"></A>DOM access
     <OL class="REQT-LEVEL1">
	  <LI>SVG should provide for complete DOM support for all attributes and
	      elements.
	  <LI>To provide robust hooks for animation applications, the DOM should
	      expose graphic objects down to the individual point.
	  <LI>Supplemental utility methods (e.g., query an object's bounds, its center,
	      its perimeter as expressed as a path, access to "connectable"
	      points for callouts or connection lines) would
	      be very helpful to people writing scripts that drive SVG drawings or
		  to higher level grammars (e.g., Web Schematics or MathML) which
		  might want to perform layout based on the bounds of a given
		  graphics object.
		  The SVG working group should collaborate with the DOM working group
	      to investigate whether it is possible within the constraints of DOM
		  to provide such utility methods.
	</OL>


  <LI><A NAME="DRAnimation"></A>Animation
    <P style="font-weight:normal">
          Built-in animation primitives will not be part of SVG. Animation
		  will only be possible via the DOM or a different specification,
          which might sit on top of SVG.</P>
  </ol>

<H2><A NAME="DRMiscellaneous"></A>Miscellaneous</H2>

   <OL class="REQT-LEVEL0">

  <LI value="34"><A NAME="DRPrivateData"></A>Inclusion of private data (metadata)
    <P style="font-weight: normal">
          To promote the use of SVG as an interchange format or as a
	      component of higher-level graphics languages, there needs
	      to be a provision for inclusion of application-specific or
		  industry-specific private data within an SVG drawing.
	</P>


  <LI><A NAME="DRExtensibility"></A>Extensibility
    <P style="font-weight: normal">
          It is highly desirable that SVG be extensible to cope with changing
		  requirements and for providing many valuable hooks to allow for
		  creation of more efficient and compelling Web pages. A well-designed
		  extensibility mechanism can allow for tomorrow's innovations to
		  be available in today's browsers (i.e., no need to wait for a new version
		  of the standard to be defined an implemented in browsers). A well-designed
		  extensibility mechanism could be the best solution for many valuable
		  features such as client-side filters on graphics data. Possible
		  extensibility facilities are custom paint servers (for filling
		  and stroking), custom object types, custom filters, custom
		  compositing engines and custom color spaces.
		  However, defining a useful and workable extensibility mechanism is
		  very difficult and frought with many obstacles, such as deficiencies in
		  cross-platform language standards. Thus, the working group should
		  look into an extensibility mechanism as a highly desirable feature and
		  review proposals from the members,
		  but an extensibility mechanism is not an absolute requirement for version 1
		  of SVG.
	</P>


  <LI><A NAME="DREmbedded"></A>Embedded components to achieve
  self-contained graphics files

     <OL class="REQT-LEVEL1">
	  <LI>Images - There has been some strong initial feedback has been that SVG should
		  provide for embedded images. The working group should collaborate
		  with other working groups (e.g., XML) to investigate the feasibility of
		  allowing for embedded images within an SVG drawing.
	  <LI>Fonts - There has been some strong initial feedback has been that SVG should
		  provide for embedded fonts. The working group has yet to
		  make decisions on this issue. The working group should collaborate
		  with other working groups (e.g., XML) to investigate the feasibility of
		  allowing for embedded fonts within an SVG drawing.
	</OL>

</OL>
<p><hr>

<address>Chris Lilley &lt;<a href="mailto:chris@w3.org">chris@w3.org</a>&gt;<br>
Chair, W3C SVG Working Group<br>
Last modified: $Date: 1998/11/03 23:41:19 $
</address>
<P><A HREF="http://validator.w3.org/"><IMG BORDER="0"
     SRC="http://validator.w3.org/images/vh40.gif"
     ALT="Valid HTML 4.0!" HEIGHT="31" WIDTH="88"></A>&nbsp;
<A HREF="http://www.w3.org/Style/CSS/Buttons">
  <IMG ALT="Made with CSS" BORDER="0" WIDTH="88" HEIGHT="31"
  SRC="http://www.w3.org/Style/CSS/Buttons/mwcos"></A></p>

</BODY>
</HTML>