1 Introduction
    
      
    Contents
    
    
        
    1.1 About SVG
    This specification defines the features and syntax for Scalable Vector Graphics
    (SVG).
    SVG is a language for describing two-dimensional graphics in
    XML [XML10]. SVG
    allows for three types of graphic objects: vector graphic
    shapes (e.g., paths consisting of straight lines and curves),
    images and text. Graphical objects can be grouped, styled,
    transformed and composited into previously rendered objects.
    The feature set includes nested transformations, clipping
    paths, alpha masks, filter effects and template objects.
    SVG drawings can be interactive
    and dynamic. Animations can be defined and triggered
    either declaratively (i.e., by embedding SVG animation elements
    in SVG content) or via scripting.
    Sophisticated applications of SVG are possible by use of a
    supplemental scripting language which accesses SVG Document Object Model (DOM), which
    provides complete access to all elements, attributes and
    properties. A rich set of event handlers such as
    onmouseover and onclick can be assigned to any SVG graphical
    object. Because of its compatibility and leveraging
    of other Web standards, features like scripting can be done on XHTML and SVG
    elements simultaneously within the same Web page.
    SVG is a language for rich graphical content. For
    accessibility reasons, if there is an original source document
    containing higher-level structure and semantics, it is
    recommended that the higher-level information be made available
    somehow, either by making the original source document
    available, or making an alternative version available in an
    alternative format which conveys the higher-level information,
    or by using SVG's facilities to include the higher-level
    information within the SVG content. For suggested techniques in
    achieving greater accessibility, see Accessibility.
      
    1.1.1 Modularization
    The modularization of SVG included here is a decomposition
    of SVG 1.0 and errata into a
    collection of abstract modules that provide specific units of
    functionality. These modules may be combined with each other
    and with modules defined in other specifications (such as
    XHTML) to create SVG subset and extension document types that
    qualify as members of the SVG family of document types. See Conformance for a description of SVG
    family documents, and [XHTMLplusMathMLplusSVG]
    for a profile that combines XHTML, MathML and SVG.
    Each major section of the SVG specification produces a
    module named after that section, e.g. "Text Module" or "Basic
    Structure Module". A module without the "Basic" prefix 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 a need to provide a
    subset of the functionality of the complete module, then
    a Basic module is created with the "Basic" prefix added to the
    name of the complete module. For example, the "Basic Text Module"
    is a subset of the "Text Module".
    It is an error for a profile of SVG 1.1 to include both the
    complete module and its basic subset module (e.g. the
    "Text Module" and the "Basic Text Module").
       
    1.1.2 Element and Attribute collections
    Most modules define a named collection of elements or
    attributes. These collections are used as a shorthand when
    describing the set of attributes allowed on a particular element (eg. the
    "Style" attibute collection) or the
    set of elements allowed as children of a particular element (eg. the "Shape" element collection). All
    collections have names that begin with an uppercase
    character.
    
    When defining a profile, it is assumed that all the element and
    attribute collections are defined to be empty. That way, a module
    can redefine the collection as it is included in the profile,
    adding elements or attributes to make them available within the profile.
    Therefore, it is not a mistake to refer to an element or attribute
    collection from a module that is not included in the profile, it
    simply means that collection is empty.
    
    
    The exception to this is the collection
    Presentation.attrib, which is the union of all the
    presentation attribute collections (i.e. all the attribute
    collections with the string "Presentation" in their name).
    Presentation.attrib is not defined in any module, but it
    exists in every profile.
    
    A subset module (ie. a Basic module) may define a different
    named collection from a superset module. Since it is an error
    to include a subset and superset module of the same group in a
    profile, all attribute and element collections will either be
    defined once by the module that includes them, or will have
    their default empty value (again, with the exception of
    Presentation.attrib which is not defined by any module).
      
    1.1.3 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
    complete modules listed in this specification (ie. every module
    that is not a subset module).
    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.
    
          
    1.2 SVG MIME type, file name extension and Macintosh file
    type
    The MIME type for SVG is "image/svg+xml" (see [RFC3023]). The
    registration of this MIME type is in progress at the W3C.
    It is recommended that SVG files have the extension
    ".svg" (all lowercase) on all platforms. It is
    recommended that gzip-compressed
    SVG files have the extension ".svgz" (all
    lowercase) on all platforms.
    It is recommended that SVG files stored on Macintosh HFS
    file systems be given a file type of "svg "
    (all lowercase, with a space character as the fourth letter).
    It is recommended that gzip-compressed
    SVG files stored on Macintosh HFS file systems be given a file
    type of "svgz" (all lowercase).
       
    1.3 SVG Namespace, Public Identifier and System
    Identifier
    The following are the SVG 1.1 namespace, public identifier
    and system identifier:
    
      - SVG Namespace:
- http://www.w3.org/2000/svg
- Public Identifier for SVG 1.1:
- PUBLIC "-//W3C//DTD SVG 1.1//EN"
- System Identifier for the SVG 1.1 Recommendation:
- http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd
The following is an example document
    type declaration for an SVG document:
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
         "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
     
     Note that DTD listed in the System Identifier is a modularized DTD (ie. its contents are spread over multiple files), which means that 
     a validator may have to fetch the multiple modules in order
     to validate. For that reason, there is a single flattened DTD
     available that corresponds to the SVG 1.1 modularized DTD. It
     can be found at http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-flat.dtd.
     
     
     
    
    1.4 Compatibility with Other Standards Efforts
    SVG leverages and integrates with other W3C specifications
    and standards efforts. By leveraging and conforming to other
    standards, SVG becomes more powerful and makes it easier for
    users to learn how to incorporate SVG into their Web sites.
    The following describes some of the ways in which SVG
    maintains compatibility with, leverages and integrates with
    other W3C efforts:
    
      - SVG is an application of XML and is compatible with the
      "Extensible Markup Language (XML) 1.0" Recommendation [XML10]
- SVG is compatible with the "Namespaces in XML"
      Recommendation [XML-NS]
- SVG utilizes "XML Linking Language (XLink)" [XLINK] for URI
      referencing and requires support for base URI specifications
      defined in "XML Base" [XML-BASE].
- SVG's syntax for referencing element IDs is a compatible
      subset of the ID referencing syntax in "XML Pointer Language
      (XPointer)" [XPTR].
- SVG content can be styled by either CSS (see "Cascading
      Style Sheets (CSS) level 2" specification [CSS2]) or XSL (see
      "XSL Transformations (XSLT) Version 1.0" [XSLT]). (See Styling with CSS and
      Styling with
      XSL)
- SVG supports relevant properties and approaches common to
      CSS and XSL, plus selected semantics and features of CSS (see
      SVG's styling
      properties and SVG's
      Use of Cascading Style Sheets).
- External style sheets are referenced using the mechanism
      documented in "Associating Style Sheets with XML documents
      Version 1.0" [XML-SS].
- SVG includes a complete Document Object Model (DOM) and
      conforms to the "Document Object Model (DOM) level 1"
      Recommendation [DOM1]. The
      SVG DOM has a high level of compatibility and consistency
      with the HTML DOM that is defined in the DOM Level 1
      specification. Additionally, the SVG DOM supports and
      incorporates many of the facilities described in "Document
      Object Model (DOM) level 2" [DOM2], including
      the CSS object model and event handling.
- SVG incorporates some features and approaches that are
      part of the "Synchronized Multimedia Integration Language
      (SMIL) 1.0 Specification" [SMIL1], including
      the 'switch' element and the systemLanguage attribute.
- SVG's animation features (see Animation) were developed in
      collaboration with the W3C Synchronized Multimedia (SYMM)
      Working Group, developers of the Synchronized Multimedia
      Integration Language (SMIL) 1.0 Specification [SMIL1]. SVG's
      animation features incorporate and extend the general-purpose
      XML animation capabilities described in the "SMIL Animation"
      specification [ 
      SMILANIM].
- SVG has been designed to allow future versions of SMIL to
      use animated or static SVG content as media components.
- SVG attempts to achieve maximum compatibility with both
      HTML 4 [HTML4]
      and XHTML(tm) 1.0 [XHTML]. Many of SVG's
      facilities are modeled directly after HTML, including its use
      of CSS [CSS2],
      its approach to event handling, and its approach to its
      Document Object Model [DOM2].
- SVG is compatible with W3C work on internationalization.
      References (W3C and otherwise) include: [UNICODE]
      and [CHARMOD].
      Also, see Internationalization
      Support.
- SVG is compatible with W3C work on Web Accessibility [WAI]. Also, see Accessibility Support.
In environments which support [DOM2] for other
    XML grammars (e.g., XHTML [XHTML]) and which also
    support SVG and the SVG DOM, a single scripting approach can be
    used simultaneously for both XML documents and SVG graphics, in
    which case interactive and dynamic effects will be possible on
    multiple XML namespaces using the same set of scripts.
    
      
    1.5 Terminology
    Within this specification, the key words "MUST", "MUST NOT",
    "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
    "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
    described in RFC 2119 (see [RFC2119]).
    However, for readability, these words do not appear in all
    uppercase letters in this specification.
    At times, this specification recommends good practice for
    authors and user agents. These recommendations are not
    normative and conformance with this specification does not
    depend on their realization. These recommendations contain the
    expression "We recommend ...", "This specification recommends
    ...", or some similar wording.
    
      
    1.6 Definitions
    
      -  basic shape
- Standard shapes which are predefined in SVG as a
      convenience for common graphical operations. Specifically: 'rect', 'circle', 'ellipse', 'line', 'polyline', 'polygon'.
      -  canvas
- A surface onto which graphics elements are drawn, which
      can be real physical media such as a display or paper or an
      abstract surface such as a allocated region of computer
      memory. See the discussion of the SVG canvas in the chapter on
      Coordinate Systems, Transformations and
      Units.
      -  clipping path
- A combination of 'path', 'text' and basic shapes which serve as the
      outline of a (in the absence of anti-aliasing) 1-bit mask,
      where everything on the "inside" of the outline is allowed to
      show through but everything on the outside is masked out. See
      Clipping paths.
      -  container element
- An element which can have graphics elements and other
      container elements as child elements. Specifically: 'svg', 'g', 'defs' 'symbol', 'clipPath', 'mask', 'pattern', 'marker', 'a' and 'switch'.
      - 
      current innermost SVG document
      fragment
- The XML document sub-tree which starts with the most
      immediate ancestor 'svg' element of a given SVG
      element.
      -  current SVG document
      fragment
- The XML document sub-tree which starts with the outermost
      ancestor 'svg' element of a given SVG
      element, with the requirement that all container elements
      between the outermost 'svg' and this element are
      all elements in the SVG language.
      -   current transformation matrix
      (CTM)
- Transformation matrices define the mathematical mapping
      from one coordinate system into another using a 3x3 matrix
      using the equation [x' y' 1] = [x
      y 1] * matrix. The current transformation
      matrix (CTM) defines the mapping from the user
      coordinate system into the viewport coordinate system. See Coordinate
      system transformations.
      -  fill
- The operation of painting the interior of a shape or the interior of the
      character glyphs in a text string.
      -  font
- A font represents an organized collection of glyphs in which the various
      glyph representations will share a common look or styling
      such that, when a string of characters is rendered together,
      the result is highly legible, conveys a particular artistic
      style and provides consistent inter-character alignment and
      spacing.
      -  glyph
- A glyph represents a unit of rendered content within a font. Often, there is a
      one-to-one correspondence between characters to be drawn and
      corresponding glyphs (e.g., often, the character "A" is
      rendered using a single glyph), but other times multiple
      glyphs are used to render a single character (e.g., use of
      accents) or a single glyph can be used to render multiple
      characters (e.g., ligatures). Typically, a glyph is defined
      by one or more shapes such
      as a path, possibly with additional
      information such as rendering hints that help a font engine
      to produce legible text in small sizes.
      -  graphics element
- One of the element types that can cause graphics to be
      drawn onto the target canvas. Specifically: 'path', 'text', 'rect', 'circle', 'ellipse', 'line', 'polyline', 'polygon', 'image' and 'use'.
      -  graphics referencing
      element
- A graphics element which uses a reference to a different
      document or element as the source of its graphical content.
      Specifically: 'use' and 'image'.
      -  local URI reference
- A Uniform Resource Identifier [URI] that does
      not include an <absoluteURI> or <relativeURI> and thus
      represents a reference to an element within the current
      document. See References and the
      'defs' element.
      -  mask
- A container
      element which can contain graphics elements
      or other container elements which define a set of graphics
      that is to be used as a semi-transparent mask for compositing
      foreground objects into the current background. See Masks.
      -  non-local URI reference
- A Uniform Resource Identifier [URI] that
      includes an <absoluteURI> or <relativeURI> and thus
      (usually) represents a reference to a different document or
      an element within a different document. See References and the 'defs' element.
      -  paint
- A paint represents a way of putting color values onto the
      canvas. A paint might consist of both color values and
      associated alpha values which control the blending of colors
      against already existing color values on the canvas. SVG
      supports three types of built-in paint: color, gradients and patterns.
      -  presentation attribute
- An XML attribute on an SVG element which specifies a
      value for a given property for that element. See Styling.
      -  property
- A parameter that helps specify how a document should be
      rendered. A complete list of SVG's properties can be found in
      Property Index. Properties are
      assigned to elements in the SVG language either by presentation
      attributes on elements in the SVG language or by using a
      styling language such as CSS [CSS2]. See Styling.
      -  shape
- A graphics element that is defined by some combination of
      straight lines and curves. Specifically: 'path', 'rect', 'circle', 'ellipse', 'line', 'polyline', 'polygon'.
      -  stroke
- The operation of painting the outline of a shape or the outline of
      character glyphs in a text string.
      -  SVG canvas
- The canvas onto which the SVG
      content is rendered. See the discussion of the SVG canvas in the chapter on
      Coordinate Systems, Transformations and
      Units.
      -  SVG document fragment
- The XML document sub-tree which starts with an 'svg' element. An SVG
      document fragment can consist of a stand-alone SVG document,
      or a fragment of a parent XML document enclosed by an 'svg' element. When an 'svg' element is a descendant
      of another 'svg' element, there are two
      SVG document fragments, one for each 'svg' element. (One SVG
      document fragment is contained within another SVG document
      fragment.)
      -  SVG viewport
- The viewport within the SVG canvas which defines the
      rectangular region into which SVG content is rendered. See
      the discussion of the SVG
      viewport in the chapter on Coordinate Systems, Transformations and
      Units.
      -  text content element
- One of SVG's elements that can define a text string that
      is to be rendered onto the canvas. SVG's text content
      elements are the following: 'text', 'tspan', 'tref', 'textPath' and 'altGlyph'.
      -  transformation
- A modification of the current
      transformation matrix (CTM) by providing a supplemental
      transformation in the form of a set of simple transformations
      specifications (such as scaling, rotation or translation)
      and/or one or more transformation matrices.
      See Coordinate
      system transformations.
      -  transformation matrix
- Transformation matrices define the mathematical mapping
      from one coordinate system into another using a 3x3 matrix
      using the equation [x' y' 1] = [x
      y 1] * matrix. See current
      transformation matrix (CTM) and Coordinate
      system transformations.
      -  URI Reference
- A Uniform Resource Identifier [URI] which
      serves as a reference to a file or to an element within a
      file. See References and the 'defs' element.
      -  user agent
- The general definition of a user agent is an application
      that retrieves and renders Web content, including text,
      graphics, sounds, video, images, and other content types. A
      user agent may require additional user agents that handle
      some types of content. For instance, a browser may run a
      separate program or plug-in to render sound or video. User
      agents include graphical desktop browsers, multimedia
      players, text browsers, voice browsers, and assistive
      technologies such as screen readers, screen magnifiers,
      speech synthesizers, onscreen keyboards, and voice input
      software.
 
 A "user agent" may or may not have the ability to retrieve
      and render SVG content; however, an "SVG user agent"
      retrieves and renders SVG content.
      -  user coordinate system
- In general, a coordinate system defines locations and
      distances on the current canvas.
      The current user coordinate
      system is the coordinate system that is currently
      active and which is used to define how coordinates and
      lengths are located and computed, respectively, on the
      current canvas. See initial
      user coordinate system and Coordinate
      system transformations.
      -  user space
- A synonym for user
      coordinate system.
      -  user units
- A coordinate value or length expressed in user units
      represents a coordinate value or length in the current user coordinate system.
      Thus, 10 user units represents a length of 10 units in the
      current user coordinate system.
      -  viewport
- A rectangular region within the current canvas onto which graphics elements are to be
      rendered. See the discussion of the SVG viewport in the
      chapter on Coordinate Systems,
      Transformations and Units.
      -  viewport coordinate system
- In general, a coordinate system defines locations and
      distances on the current canvas.
      The viewport coordinate
      system is the coordinate system that is active at the
      start of processing of an 'svg' element, before
      processing the optional viewBox attribute. In the
      case of an SVG document fragment that is embedded within a
      parent document which uses CSS to manage its layout, then the
      viewport coordinate system will have the same orientation and
      lengths as in CSS, with the origin at the top-left on the viewport. See The initial viewport and
      Establishing a
      new viewport.
      -  viewport space
- A synonym for viewport coordinate
      system.
      -  viewport units
- A coordinate value or length expressed in viewport units
      represents a coordinate value or length in the viewport coordinate
      system. Thus, 10 viewport units represents a length of 10
      units in the viewport coordinate system.