W3C

SVG Transforms Requirements

W3C Editors Draft 13 February 2009

This version:
http://www.w3.org/TR/2007/WD-SVGTransformsReqs-20081209/
Latest version:
http://www.w3.org/TR/SVGTransformsReqs1/
Editors
Jun Fujisawa, Canon <jun.fujisawa@canon.co.jp>
Anthony Grasso, Canon <anthony.grasso@cisra.canon.com.au>

Abstract

This document lists the design principles and requirements for the creation of a SVG specification related to Transforms.

Status of this Document

This is a W3C Working Draft for review by W3C Members and other interested parties. It is a draft document and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C Recommendations and other technical documents, including Working Drafts and Notes, can be found at http://www.w3.org/TR/

This is the first release of the SVG Transforms Requirements. It is expected that this document will progress through a number of working drafts, including "Last Call", before being published in final form.

This document was developed by the Scalable Vector Graphics (SVG) working group as part of the W3C Graphics Activity. The authors of this document are the SVG Working Group members.

Feedback on this document should be sent to the email list the public mailing list of the SVG Working Group (list archives). To subscribe send an email to www-svg-request@w3.org with the word subscribe in the subject line.

The latest information regarding patent disclosures related to this document is available on the Web. As of this publication, the SVG Working Group are not aware of any royalty-bearing patents they believe to be essential to SVG.

This section represents the status of this document at the time this version was published. It will become outdated if and when a new version is published. The latest status is maintained at the W3C.

Contents

1 Introduction

SVG is an W3C XML technology that describes two-dimensional grpahics. There are currently two SVG Recommendations; SVG 1.1 and SVG Tiny 1.2. SVG 1.1 was designed primarily for 2 dimensional Web content, and as such supports only 2 dimensional object features for screen display. Similarly SVG Tiny 1.2 was designed primarily for 2 dimensional Web content on mobile devices. Industry, developer and community feedback has suggested a desire to form a module that allows 2.5 dimensional effects to be achieved in SVG.

In response, the SVG Working Group will develop a module to extend the transformation capabilities of SVG called SVG Transforms. The current feeling within the Working Group is that SVG Transforms will be a set of content requirements and conformance criteria that allow 3D transformations of 2D objects. It is very likely that there will be a set of new language features proposed which are required for SVG Transforms, but will be equally useful in other domains. It is expected then, that some of these new features will become part of the core SVG language and other modules that are built from SVG.

2 Terminology

The following key words and phrases used throughout this document are defined here for clarity. The terms Must, Should, and May are used to specify the extent to which an item is a requirement for the SVG working group in defining SVG. These recommendations should not be mistaken as a guide to implementors.

  1. 'Must' means that the item is an absolute requirement.
  2. 'Should' means that there may exist valid reasons in particular circumstances to ignore the item, but the full implications must be understood and carefully weighed before choosing a different course.
  3. 'May' means that item will be considered, but further examination is needed to determine if the item should be treated as a requirement.
  4. 'SVG' refers to SVG in general without reference to any version or profile.
  5. 'SVG 1.0' refers to the original SVG specification.
  6. 'SVG 1.1' refers to the modularized version of SVG 1.0.
  7. 'SVG Tiny 1.2' refers to the most recent release of SVG and will reference this specification.
  8. 'SVG Transforms' refers to an SVG Transformation, and an SVG specification for Transforms.

3 Usage Scenarios

The following usage scenarios illustrate some of the ways in which SVG Transforms might be used for various applications. They may be used as design cases during the development of the SVG transforms module, and should be useful in helping non-members of the SVG Working Group to understand the intent and goals of this task.

Use Interfaces. SVG Transforms could be used to describe a user interface that has a 3D appearence. The interface can be rescalled for different screen sizes.

Web Graphics and Fonts. SVG Transforms could be used to enhance the web experience of a website. Effects could be used that make the text appear 3D.

Mapping. SVG Transforms could be used to change the angle or perspective of a raster or SVG map. A perspective view on a map makes viewing of upcoming intersections and roads easier to follow. Additionally it gives the viewer the effect of travellind down the road on the map.

3D Movement of Objects. 3D Movement can be given to existing SVG content containing Graphics, Images, Movies and Text. A container element with SVG Transforms applied could placed around existing content to give the content the appearance 3D Movement.

Perspective view of Objects. Perspective views can be given to exisiting SVG content containing Grahpics, Images, Movies and Text to give the illusion that they are vanishing in the distance. A container element with SVG Transforms applied could be placed around existing content to give the content a perspective view.

Game Effects. The transform extensions provided by SVG XTransorms can be used for online gaming and hand held gaming devices. Such applications may require the illusion of a 3D environment but do not have the processing capabilities or the bandwidth to support a full 3D polygon model. SVG Transforms could be used as an alternative for such applications.

Interchange Format. User selects "Export.." or "Save As..." from a 3D vector drawing or CAD application and chooses the SVG file type. The application then converts its internal vector format to SVG with SVG Transforms and saves the file to disk. This behaviour is very similar to the Adobe Illustrator or Microsoft Visio export behaviour.

4 Special Considerations for Transforms

Implementation commitments. SVG Transforms will provide additional transformation options to the author. To support SVG Transforms, implementations may need to extend thier transformation pipeline to allow operations with larger matricies to be performed. Addtional mathematical operations may be required by the implementation to support SVG Transforms.

Ease of authoring. The additional transformations provided by SVG Transforms should use a syntax that is similar to current SVG transformations and coordinates. Units should be kept consistent with the current SVG specifications to ensure ease of authoring. The transform commands that SVG Transforms provides should be intuative and if possible easily recognised by a person skilled in the art of graphics and 3D drawing.

5 Requirements

  1. General Requirements
    1. SVG Transforms must consider the constraints of limited memory and processor devices.
    2. SVG Transforms must be a separate module to the core profiles (SVG Tiny 1.2, SVG Full 1.1).
    3. Conformance criteria for SVG Transforms must be produced. The criteria should be separated into sections relevant to particular application types (eg. SVG files/document fragments, SVG generators, SVG viewers, SVG printers, etc.)
    4. Software or documents must pass the relevant criteria to be able to claim conformance to the particular application type.
    5. A conformance test suite must be developed for SVG Transforms. The test suite must be made publicly available. Conformance test suites for other uses of SVG Transforms (e.g. prepress guidelines) may be developed.
    6. A specification referencing SVG Transforms must declare if animations applies when a 'Transform' chain is in its scope.
  2. Coordinate Systems, Transformations and Units
    1. SVG Transforms must adopt the current SVG Tiny 1.2 transformations in addition to any new transformations it specifies.
    2. SVG Transforms must maintain a similar syntax and units of length as the current SVG Tiny 1.2 transformations.
    3. SVG Transforms must support 3D transformations.
    4. SVG Transforms must support nesting of 3D transformations.
    5. SVG Transforms must support perspective transformations.
    6. Content using SVG Transforms must be projected onto a 2D plane.
  3. Scripting
    1. A dynamic SVG Transforms viewer must support inspection and modification of the new SVG transform items, using a method compatible with the SVG 1.1 DOM and the SVG Tiny 1.2 uDOM.
  4. Animation
    1. A dynamic SVG Transform viewer must support animation of all properties listed as animatable.
    2. A dynamic SVG Transforms viewer must support animiation of all the new transformations in the transformation extension list.
  5. Existing Specifications
    1. SVG Transforms must strive to achieve and maintain CSS compatibility where possible.
    2. SVG Transforms must allow for transformations to be passed to an OpenVG compliant renderer. It is desirable to allow different rendering engines that comply to the OpenVG API to be easily switchable for implementations.
    3. SVG Transforms must allow for transformations to be passed to an OpenGL compliant renderer. It is desirable to allow different rendering engines that comply to the OpenGL API to be easily switchable for implementations.

6 References

SVG 1.1
Scalable Vector Graphics (SVG) Tiny 1.2 Specification, Ola Andersson, Robin Berjon, Erik Dahlstrom, Andrew Emmons, Jon Ferraiolo, Anthony Grasso, Vincent Hardy, Scott Hayman, Dean Jackson, Chris Lilley, Cameron McCormack, Andreas Neumann, Craig Northway, Antoine Quint, Nandini Ramani, Doug Schepers, Andrew Shellshear, editors, W3C, 22 December 2008 (Recommendation). See http://www.w3.org/TR/SVGMobile12/
SVG 1.1/1.2/2.0 Requirements
SVG 1.1/1.2/2.0 Requirements Document, Dean Jackson, editor, W3C, 22 April 2002. See http://www.w3.org/TR/SVG2Reqs/
Mobile SVG Profiles
Mobile SVG Profiles: SVG Tiny and SVG Basic, Tolga Capin, editor, W3C, 14 January 2003 (Recommendation). See http://www.w3.org/TR/SVGMobile