Scalable Vector Graphics (SVG) Version 1.1

1.1 Modularization

The modularization of SVG included here is a decomposition of SVG 1.0 and a small set of extra features into a collection of abstract modules that provide specific types of functionality. The modules are described in this specification and will be implemented by Document Type Definition and XML Schema in future drafts.

These modules may be combined with each other and with other modules to create SVG subset and extension document types that qualify as members of the SVG-family of document types.

Each major section of the SVG 1.0 specification produces a module named after that section, e.g. "Full Text Module". The term "Full" implies that the module includes the complete set of elements and attributes with no restrictions from the corresponding section of the specification. If there is need to provide a subset of the functionality in a Full module, then Basic and/or Tiny modules are created. A Tiny module is a subset of a Basic module which is a subset of a Full module.

It is an error for a profile of SVG 1.1 to include a module and a subset of that module (e.g. the Full Text Module and the Basic Text Module).

1.2 Profiling the SVG specification

The modularization of SVG 1.1 allows profiles to be described by listing the SVG modules they allow and possibly a small number of restrictions or extensions on the elements provided by those modules.

The Full profile of SVG 1.1 is the collection of all the Full modules listed in this specification. Future drafts of this document will include a table that lists all elements, attributes and properties, along with the modules in which they are included.

When applied to conformance, the unqualified term "SVG" implies the Full profile of SVG 1.1 defined by this specification. If an implementation does not implement the Full profile, it must state either the profile to which it conforms, or that it implements a subset of SVG.

2.1 The version attribute

The 'svg' element has an attribute version with a fixed value in SVG 1.0 [SVG 1.0]. It is redefined in SVG 1.1 as follows:

version = "<number>"

Indicates the SVG language version to which this document fragment conforms. For SVG 1.1 content, this attribute is required and should have the value "1.1".

2.2 The baseProfile attribute

In the situations where a DOCTYPE declaration is not available, SVG user agents require a method to identify the type of SVG content that the document fragment is using. The baseProfile attribute has been added to the 'svg' element in SVG 1.1 to provide this information. Each profile of SVG is required to define a value to be used for the baseProfile attribute, preferably the name of the profile.

baseProfile = "name"

Indicates the SVG language profile that this document fragment is based on. An SVG user agent is required to minimally support this base profile in order to render the document fragment correctly.

2.3 Full Core Attribute Module

The Full Core Attribute Module defines the attribute set StdAttrs that is the core set of attributes that can be present on any element.

2.4 Full Structure Module

2.5 Tiny Structure Module

2.6 Full Container Attribute Module

The Full Container Attribute Module defines the ContainerPresentationAttrs attribute set.

2.7 Full Viewport Attribute Module

The Full Viewport Attribute Module defines the ViewportPresentationAttrs attribute set.

3.1 Geographic Coordinate System

In order to allow interoperability between SVG content generators and user agents dealing with maps encoded in SVG, the SVG 1.1 specification encourages the use of a common metadata definition for describing the coordinate system used in the SVG files.

These metadata should be added under the 'metadata' element of the topmost 'svg' element describing the map. They consists of an RDF description of the Coordinate Reference System definition of the SVG map.

The definition should be conformant to the XML grammar described in the OpenGIS Recommendation on the Definition of Coordinate Reference System [OpenGIS Coordinate Systems]. In order to correctly map the 2-dimensional data used by SVG, the CRS must be of subtype ProjectedCRS or Geographic2dCRS. The first axis of the described CRS maps the x-axis and the second axis maps the y-axis.

The main interest of such metadata is to indicate to the User Agent that two or more SVG documents can be overlayed or merged into a single document. Obviously, if two maps reference the same Coordinate Reference System definition then they can be overlayed without reprojecting the data. If the maps reference different Coordinate Reference Systems, then a specialised cartographic User Agent may choose to transform the coordinate data to overlay the data. However, typical SVG user agents are not required to perform these types of transformations, or even recognise the metadata.

Below are two examples of the coordinate metadata.

<svg ...>
  <metadata>
    <rdf:RDF xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:crs = "http://www.ogc.org/crs" >
      <rdf:Description>
        <!-- The Coordinate Reference System is described 
             through an URI. Is that legal RDF/XML??? -->
        <crs:CoordinateReferenceSystem
               rdf:resource="http://www.sample.org/srs/epsg.xml#4326"/>
      </rdf:Description>
    </rdf:RDF>
  </metadata>
  <!-- The actual map content -->
</svg> 

<svg ...>
  <metadata>
    <rdf:RDF xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:crs = "http://www.ogc.org/crs" >
      <rdf:Description>
        <!-- In case of a well-known Coordinate Reference System
             an 'Identifier' is enough to describe the CRS -->
        <crs:CoordinateReferenceSystem>
          <crs:Identifier>
            <crs:code>4326</crs:code>
            <crs:codeSpace>EPSG</crs:codeSpace>
            <crs:edition>5.2</crs:edition>
          </crs:Identifier>
        </crs:CoordinateReferenceSystem>
      </rdf:Description>
    </rdf:RDF>
  </metadata>
  <!-- The actual map content -->
</svg>
   

3.2 Using Viewport Coordinates

The SVG Working Group considered adding the ability to allow graphical elements to be described using viewport coordinates into SVG 1.1. With this feature, graphical content such as toolbars or map legends could be statically placed within the user agent viewport and be unaffected by zoom and pan.

While the benefits of such a feature are obvious, the Working Group has decided to leave this feature out of SVG 1.1 and consider it for SVG 2.0. There are two reasons behind the decision: a substantial change to the rendering and coordinate system model is inappropriate for a minor update of the SVG specification and that the feature is difficult to describe and implement, and thus warrants heavy consideration to ensure the most appropriate solution is found.

4.1 Full Style Module

The Full Style Module defines the StyleAttrs attribute set.

5.1 Full Paint Attribute Module

The Full Paint Attribute Module defines the PaintPresentationAttrs attribute set.

5.2 Tiny Paint Attribute Module

The Tiny Paint Attribute Module defines the PaintPresentationAttrs attribute set.

5.3 Full Opacity Attribute Module

The Full Opacity Attribute Module defines the OpacityPresentationAttrs attribute set.

5.4 Full Graphics Attribute Module

The Full Graphics Attribute Module defines the GraphicsPresentationAttrs attribute set.

5.5 Tiny Graphics Attribute Module

The Tiny Graphics Attribute Module defines the GraphicsPresentationAttrs attribute set.

6.1 Full Hyperlinking Module

6.2 Full XLink Attribute Module

The Full XLink Attribute Module defines the XLinkRefAttrs attribute set.

6.3 Full ExternalResourcesRequired Attribute Module

The Full ExternalResourcesRequired Attribute Module defines the ExternalResourcesRequiredAttrs attribute set.

7.1 The requiredFeatureList attribute

SVG 1.1 will deprecate the requiredFeatures and requiredExtensions attributes and replace them with requiredFeatureList. This attribute will allow boolean logic expressions based on XPath to allow greater control over conditional processing. There will be a mapping from the deprecated syntax to the new syntax.

The feature strings used SVG 1.1 will be URIs.

7.2 Full Conditional Processing Module

8.1 Full Shape Module

9.1 Full Image Module

10.1 Simple Text Wrapping

SVG 1.1 will include new elements to support simple text wrapping, as shown in the example below.

<tblock>
   <!-- You can specify regions inline via <region> 
           or reference via <regionRef>.
           By default, display="none" on <region> and <regionRef>,
           but if you say display="inline" the contents will render. Only 
           <rect> supported in 1.1. -->
   <region>
     <rect id="foo" x="100" y="100" width="200" height="150"/>
   </region>
   <regionRef xlink:href="#Rect001"/>

   <flow>
     <p>
       My initial paragraph has a
       <span fill="red">RED</span>
       word, and has these other words, also.
     </p>

     <!-- Note the <br/> element below -->
     <p>
       <span>Second<br/>paragraph.</span>
     </p>
   </flow>
</tblock>
   

There will be seven new elements: 'tblock', 'region', 'regionRef', 'flow', 'p', 'span' and 'br'. All will be included in the Full Text Module and the Basic Text Module, but not the Tiny Text Module.

Each 'tblock' has at least one 'region' child to define the area in which text wrapping will occur. If multiple regions are defined, then once a region is filled the text will flow into the next region. The text to wrap is defined in the 'flow' element.

The default user agent style sheet for SVG 1.1 will specify 'p' as a block element, 'span' as an inline element and 'br' as a forced linebreak. When elements from arbitrary namespaces are inserted in a 'flow' element, the content of those elements will be wrapped according to the value of their display property. The SVG user agent will position the text based on the properties, not the elements or their tag names.

The algorithm for line breaking will be very simple, basically breaking on spaces, zero-width spaces and Unicode soft hypens. If it is necessary to break a line that does not have any of these characters, then the line will break after the last character that fits. The algorithm will support multiline bidirectional text. The algorithm will produce identical results across implementations when the text is rendered with an SVG font.

10.2 Full Text Module

10.3 Basic Text Module

10.4 Tiny Text Module

11.1 Color Element

The next version of this specification will include a element called 'solidColor' that provides a paint server with a solid color fill at a specified opacity. This way, elements can reference a solid fill style in the same manner as used for the other paint servers, gradients and patterns.

11.2 Full Color Module

11.3 Tiny Color Module

The Tiny Color Module defines identical elements to the Full Color Module. It also defines the same value for the ColorElements content set.

12.1 Full Gradient Module

13.1 Full Pattern Module

14.1 Full Clip Module

14.2 Basic Clip Module

15.1 Full Mask Module

16.1 Full Marker Module

17.1 Full Font Module

17.2 Tiny Font Module

18.1 Full Document Events Attribute Module

The Full Document Events Attribute Module defines the DocumentEventsAttrs attribute set.

18.2 Full Graphical Element Events Attribute Module

The Full Graphical Element Events Attribute Module defines the GraphicalElementEventsAttrs attribute set.

18.3 Full Animation Events Attribute Module

The Full Animation Events Attribute Module defines the AnimEventsAttrs attribute set.

19.1 Full Scripting Module

20.1 Full Cursor Module

21.1 Full View Module

22.1 Full Filter Module

22.2 Basic Filter Module

23.1 Full Animation Module

24.1 Full Extensibility Module