This document presents requirements and use cases for the new features and improved existing features that will be incorporated into SVG2, the next major revision of the Scalable Vector Graphics specification.
This is revision $Id: Overview.html,v 1.3 2011-10-27 00:09:02 cmccorma Exp $.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is the 26 October 2011 Editor’s Draft of the SVG2: Use Cases and Requirements specification. Please send comments about this document to firstname.lastname@example.org (archived) with “[SVG2Reqs]” at the start of the subject line.
It is intended that this document be eventually published as a W3C Note, but not before work on the SVG2 specification, for which it documents the requirements, has been published as a Candidate Recommendation. As work on SVG2 progresses, new use cases and requirements that would be appropriate for inclusion may be discovered. As such, the requirements document will be somewhat of a work in progress, and intended to be more of a repository for the reasons why certain functionality has been included in the specification, rather than being a prescriptive document that prevents any deviation from the Working Group’s initial decisions. This document does not make any normative requirements of the SVG2 specification that is to be written.
Publication as an Editor’s Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Since the initial publication of the Scalable Vector Graphics 1.0 specification in 2001, very little has changed in terms of the set of features that it supports. [SVG10] In 2003, SVG 1.1 was published, which primarily was a reformulation of SVG 1.0 using a modularized DTD. [SVG11] The Second Edition of SVG 1.1, published in August 2011, incorporated a number of bug fixes and clarifications to the language, but still not introduce any new features. [SVG11SE] Over the ten years that SVG has been available, authors have encountered various limitations of the language. With SVG2, the Working Group intends to produce a specification evolved from SVG 1.1 that solves a number of problems that authors commonly run up against and which are impossible or cumbersome to work around. SVG2 will also include a few larger new features in response to author demand over the years.
This document presents requirements for these new and refined features in SVG2. A use case to support each of these requirements is also given. These requirements will be used to inform the development of SVG2.
This section lists requirements that have been identified for the SVG2 specification.
There should be a way to construct a marker with some of its component graphical elements having a fill or stroke taken from the fill or stroke of the element referencing the marker.
There is no way in SVG 1.1 to create a marker where particular elements within the marker definition have fills and strokes that are related to the fill and stroke of the element referencing the marker, except in one limited case: the fill and stroke values of the referencing element inherit directly into the shadow tree for the marker content. This is almost always not what the author wants, however, as often markers are a single, simple shape whose fill should use the same paint as the stroke of the referencing element. For more complex markers, it is also less likely that simply inheriting property values will allow the desired elements to be styled correctly.
Authors instead resort to creating one marker for each color it is to be rendered with, which would be unnecessarily wasteful if it were possible to assign the fill or stroke paints from the referencing element to particular elements within the marker definition.
In SVG 1.1 there are only two kinds of gradients – linear and radial. Some kinds of gradients, such as those required to do lifelike illustrations, cannot be represented simply with just these two kinds of gradients. To work around this, authors would need to create a pattern that consisted of many small linear or radial gradients patched together. Ideally, authors should be able to directly create the kinds of gradients that can be output from common illustration tools.
In addition, other comparable vector graphics formats, such as PDF, do include support for more advanced gradients. It is desirable to be able to convert from PDF to SVG without unnecessary subdivision and conversion of the gradients in the document.
Some authors wish to perform some kind of non-affine transformation effect to shapes in script. This is possible to do with basic shapes and paths, since it is easy to access or generate the path data for those elements. With text elements, this is not possible, since the author needs access to the particular font that the implementation has selected, as well as to the result of the text layout engine. To support authors performing custom geometric effects on text without their having to reimplement a text layout and shaping engine, and without needing access to raw font data from which they would need to extract glyph data, we should provide an API that can expose the outlines and positions of glyphs for a run of text, post layout.
Paths in SVG are specified using combinations of straight line and quadratic & cubic Bézier curve segments. There are two notable difficulties that authors have with the authoring of path data strings:
It would be helpful to authors if it were possible to author curved paths by specifying a sequence of points the path is to pass through. It would also be helpful to be able to specify paths in a "turtle graphics" manner, where as well as there being a current position for a relative path command to use, there would be a current bearing.
The structure of an SVG document is used simultaneously to control the painting order of elements as well as to group elements together so that common effects can be applied to them. Sometimes, authors wish to take an element from the middle of a document tree and have it rendered above elements that it otherwise would appear underneath. Being able to control the rendering order with a property would make it simpler for authors to achieve this affect than to have to move the element within the DOM.
There are many new CSS text properties that have come into existence since the publication of SVG 1.0. It would be beneficial to authors if these properties were allowed to apply to SVG text content as far as possible and makes sense.
The members of the SVG Working Group wish to thank those in the SVG community who contributed to recent requests for features to be considered for SVG2.