You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1099 lines
51 KiB
1099 lines
51 KiB
<!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. ("Stand-alone packaging" 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. ("Fragment
|
|
packaging" 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 <svg>...</svg>
|
|
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 <<a href="mailto:chris@w3.org">chris@w3.org</a>><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>
|
|
<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>
|