Appendix D: Conformance Criteria

This appendix is normative.

D.1. Introduction

In order to ensure that SVG-family documents are maximally portable among SVG-family user agents, this specification rigidly defines conformance requirements for both, as well as for SVG-family document types. While the conformance definitions can be found in this appendix, they necessarily reference normative text within this document and within other related specifications. It is only possible to fully comprehend the conformance requirements of SVG through a complete reading of all normative references.

D.2. Conforming SVG Document Fragments

An SVG document fragment is a Conforming SVG Document Fragment if it adheres to the specification described in this document (Scalable Vector Graphics (SVG) Specification) and also:

• is XML well-formed ([XML10], section 2.1),
• conforms to the Namespaces in XML specification [XML-NS],
• any CSS stylesheets conform to the core grammar of Cascading Style Sheets, level 2 revision 1 [CSS21],
• and any <?xml-stylesheet?> processing instruction conforms to Associating stylesheets with XML documents [XML-SS],
• conforms to the content model and attributes rules for the elements defined in this document (Scalable Vector Graphics (SVG) Specification)

SVG document fragments can be included within parent XML documents using the XML namespace facilities described in Namespaces in XML [XML-XS]. Note, however, that since a Conforming SVG Document Fragment must have an ‘svg’ element as its root, the use of an individual non-‘svg’ element from the SVG namespace is disallowed. Thus, the SVG part of the following document is not conforming:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE SomeParentXMLGrammar PUBLIC "-//SomeParent" "http://SomeParentXMLGrammar.dtd">
<ParentXML>
  <!-- Elements from ParentXML go here -->
  <!-- The following is not conforming -->
  <z:rect xmlns:z="http://www.w3.org/2000/svg"
          x="0" y="0" width="10" height="10" />
  <!-- More elements from ParentXML go here -->
</ParentXML>

Instead, for the SVG part to become a Conforming SVG Document Fragment, the file could be modified as follows:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE SomeParentXMLGrammar PUBLIC "-//SomeParent" "http://SomeParentXMLGrammar.dtd">
<ParentXML>
  <!-- Elements from ParentXML go here -->
  <!-- The following is conforming -->
  <z:svg xmlns:z="http://www.w3.org/2000/svg"
         width="100px" height="100px">
    <z:rect x="0" y="0" width="10" height="10"/>
  </z:svg>
  <!-- More elements from ParentXML go here -->
</ParentXML>

The SVG language or these conformance criteria provide no designated size limits on any aspect of SVG content. There are no maximum values on the number of elements, the amount of character data, or the number of characters in attribute values.

D.3. Conforming SVG Stand-Alone Files

A file is a Conforming SVG Stand-Alone File if:

• it is an XML document,
• its root element is an ‘svg’ element, and
• the SVG document fragment rooted at the document element is a Conforming SVG Document Fragment.

D.4. Conforming SVG Generators

A Conforming SVG Generator is a program which:

• always creates Conforming SVG Document Fragments and/or Conforming SVG Stand-Alone Files.
• does not create non-conforming SVG document fragments of the above types.

Additionally, an authoring tool which is a Conforming SVG Generator conforms to all of the Priority 1 accessibility guidelines from the document Authoring Tool Accessibility Guidelines 1.0 [ATAG] that are relevant to generators of SVG content. (Priorities 2 and 3 are encouraged but not required for conformance.)

SVG generators are encouraged to follow W3C developments in the area of internationalization. Of particular interest is the W3C Character Model and the concept of Webwide Early Uniform Normalization, which promises to enhance the interchangability of Unicode character data across users and applications. Future versions of the SVG specification are likely to require support of the W3C Character Model in Conforming SVG Generators.

On occasions when expression of the information exceeding single precision is desired for some use cases such as maps and technical drawings, it is encouraged that the following generation steps are utilized.

Although the real number precision of SVG is single-precision, presentation with an effective precision higher than single-precision may be obtained by generating SVG content that takes advantage of the fact that at least double-precision floating point must be used when generating a CTM (See CTM generation processing in the Conforming SVG Viewers section). The steps for generating content that takes advantage of this are:

1. Split content into tiles such that the number of significant digits required to position and size each object within a tile is within the range of single precision floats. Besides, in this description, the coordinate system which the original content has originally will be called source space.
2. Generate a coordinate transformation matrix per tile to transform from source space to tile space, where tile space is a coordinate system with origin (0,0) at the top left of the the tile. Each element of the transformation matrix must be within the range of single precision.
3. Transform the contents of each tile from source space to tile space using the generated coordinate transformation matrix. The result is that the parameters of each object can now be expressed with significant digits within the range of single precision floats.
4. For each tile, generate an inverse transformation matrix for the conversion of tile space to source space. This is used as a transform attribute of the element for the tile of the next step.
5. Arrange each tile as a separate user coordinate system in SVG. For example, the tiles may be expressed a ‘g’ elements with an transform attribute having the transformation matrix generated by the previous step. And the split graphics generated by the third step will be placed as children of it.

Example Splitting vector graphics bigger than a tile

Before Splitting		After Splitting

Example Improving Significant Digits

Step 1 : Splitting content		Step 5 : Arranging tiles with smaller effective digits and appropriate translate
This example provides the significant figure of eight digits using tiles with the user coordinate system of seven digits.

D.5. Conforming SVG Servers

Conforming SVG Servers must meet all the requirements of a Conforming SVG Generator. In addition, Conforming SVG Servers using HTTP or other protocols that use Internet Media types must serve SVG stand-alone files with the media type "image/svg+xml".

Also, if the SVG file is compressed with gzip or deflate, Conforming SVG Servers must indicate this with the appropriate header, according to what the protocol supports. Specifically, for content compressed by the server immediately prior to transfer, the server must use the "Transfer-Encoding: gzip" or "Transfer-Encoding: deflate" headers as appropriate, and for content stored in a compressed format on the server (e.g. with the file extension "svgz"), the server must use the "Content-Encoding: gzip" or "Content-Encoding: deflate" headers as appropriate.

Note: Compression of stored content (the "entity," in HTTP terms) is distinct from automatic compression of the message body, as defined in HTTP/1.1 TE/ Transfer Encoding ([RFC2616], sections 14.39 and 14.41).

D.6. Conforming SVG DOM Subtree

A DOM subtree rooted at a given element is a Conforming SVG DOM Subtree if, once serialized to XML, is a Conforming SVG Document Fragment. If the DOM subtree cannot be serialized to XML, such as when a Comment node's data contains the substring "--", then the subtree is not a Conforming SVG DOM Subtree.

D.7. Conforming SVG Interpreters

An SVG Interpreter is a program which can parse and process SVG document fragments. Examples of SVG Interpreters are server-side transcoding tools (e.g., a tool which converts SVG content into modified SVG content) or analysis tools (e.g., a tool which extracts the text content from SVG content). An SVG viewer also satisfies the requirements of an SVG interpreter in that it can parse and process SVG document fragments, where processing consists of rendering the SVG content to the target medium.

A Conforming SVG Interpreter must be able to parse and process all XML constructs defined within XML 1.0 [XML10] and Namespaces in XML [XML-NS].

A Conforming SVG Interpreter must parse any SVG document correctly. It is not required to interpret the semantics of all features correctly.

Note: A transcoder from SVG into another graphics representation, such as an SVG-to-raster transcoder, represents a viewer, and thus viewer conformance criteria apply.

D.8. Conforming SVG Viewers

An SVG viewer is a program which can parse and process an SVG document fragment and render the contents of the document onto some sort of output medium such as a display or printer; thus, an SVG Viewer is also an SVG Interpreter.

Specific criteria that must apply to a Conforming SVG Viewer:

• The program must also be a Conforming SVG Interpreter.
• For interactive user environments, facilities must exist for zooming and panning of stand-alone SVG documents or SVG document fragments embedded within parent XML documents.
• In environments that have appropriate user interaction facilities, the viewer must support the ability to activate hyperlinks.
• If printing devices are supported, SVG content must be printable at printer resolutions with the same graphics features available as required for display (e.g., the specified colors must be rendered on color printers).
• On systems where this information is available, the parent environment must provide the viewer with information about physical device resolution. In situations where this information is impossible to determine, the parent environment shall pass a reasonable value for device resolution which tends to approximate most common target devices.
• The viewer must support JPEG and PNG image formats [JPEG] [PNG].
• Resampling of image data must be consistent with the specification of property image-rendering.
• Areas of an image of SVG content may have opacity less than 100%. The viewer must at least support Simple Alpha Compositing of the image of the SVG content onto the target canvas, as described in the Compositing and Blending Specification [COMPOSITING-BLENDING].
• SVG implementations must correctly support gzip-encoded [RFC1952] and deflate-encoded [RFC1951] data streams, for any content type (including SVG, script files, images). SVG implementations that support HTTP must support these encodings according to the HTTP 1.1 specification [RFC2616]; in particular, the client must specify with an "Accept-Encoding:" request header [HTTP-ACCEPT-ENCODING] those encodings that it accepts, including at minimum gzip and deflate, and then decompress any gzip-encoded and deflate-encoded data streams that are downloaded from the server. When an SVG viewer retrieves compressed content (e.g., an .svgz file) over HTTP, if the "Content-Encoding" and "Transfer-Encoding" response headers are missing or specify a value that does not match the compression method that has been applied to the content, then the SVG viewer must not render the content and must treat the document as being in error.
• The viewer must support base64 encoded content using the "data:" URL scheme [RFC2397] wherever URI referencing of whole documents (such as raster images, SVG documents, fonts and color profiles) is permitted within SVG content. (Note: fragments of SVG content which do not constitute an entire SVG document are not available using the "data:" URL scheme.)
• The viewer must support the following W3C Recommendations with regard to SVG content:
  • complete support for the XML 1.0 specification [XML10].
  • complete support for inclusion of non-SVG namespaces within SVG content as defined in Namespaces in XML [XML-NS]. (Note that data from non-SVG namespaces are included in the DOM but are otherwise ignored.)
• All visual rendering must be accurate to within one device pixel (px unit) to the mathematically correct result at the initial 1:1 zoom ratio. It is suggested that viewers attempt to keep a high degree of accuracy when zooming.
• On systems which support accurate sRGB [SRGB] color, all sRGB color computations and all resulting color values must be accurate to within one sRGB color component value, where sRGB color component values range from 0 to 255.
• The viewer must use at least single-precision floating point for intermediate calculations on any numerical operations for conversion of coordinates. However, in order to prevent the rounding error on coordinate transformation, at least double-precision floating point computation must be used on CTM generation processing. Such minimum typical computation way is expressed with following formulas.
  $$(\mathrm{single})\mathrm{CTM}=(\mathrm{single})((\mathrm{double})\left[\begin{array}{ccc}{a}_1& c_1& e_1\\ b_1& d_1& f_1\\ 0& 0& 1\end{array}\right]\cdot <!--\; \cdot \; -->(\mathrm{double})\left[\begin{array}{ccc}{a}_2& c_2& e_2\\ b_2& d_2& f_2\\ 0& 0& 1\end{array}\right])$$

  
  $$
  (single)
  {\large \rm CTM} =
  (single)
  \left(
    (double)
    \left[
      \begin{matrix}
         a_1 & c_1 & e_1 \\
         b_1 & d_1 & f_1 \\
         0 &   0 &   1
      \end{matrix}
    \right]
    \cdot
    (double)
    \left[
      \begin{matrix}
         a_2 & c_2 & e_2 \\
         b_2 & d_2 & f_2 \\
         0 &   0 &   1
      \end{matrix}
    \right]
  \right)
  $$
  
    

  $$(\mathrm{single})\left[\begin{array}{c}{x}_{\mathrm{viewport}}\\ y_{\mathrm{viewport}}\\ 1\end{array}\right]=\mathrm{CTM}\cdot <!--\; \cdot \; -->(\mathrm{single})\left[\begin{array}{c}{x}_{\mathrm{userspace}}\\ y_{\mathrm{userspace}}\\ 1\end{array}\right]$$

  $$
  (single)
  \left[
  \begin{matrix}
  x_{\rm viewport} \\
  y_{\rm viewport} \\
  1
  \end{matrix}
  \right]
  =
  {\large \rm CTM} \cdot (single)
  \left[
  \begin{matrix}
  x_{\rm userspace} \\
  y_{\rm userspace} \\
  1
  \end{matrix}
  \right]
  $$
    

  Furthermore, when it has nested viewport coordinate sytstems, the ScreenCTM which is a transformation matrix produced by nested CTM for transforming user coordinates into the coordinates of an output device also must be generated by double-precision floating point computation.

Although anti-aliasing support is not a strict requirement for a Conforming SVG Viewer, it is highly recommended for display devices. Lack of anti-aliasing support will generally result in poor results on display devices.

The Web Accessibility Initiative is defining User Agent Accessibility Guidelines 1.0 [UAAG]. Viewers are encouraged to conform to the Priority 1 accessibility guidelines defined in this document, and preferably also Priorities 2 and 3. Once the guidelines are completed, a future version of this specification is likely to require conformance to the Priority 1 guidelines in Conforming SVG Viewers.

A Conforming SVG Viewer must be able to apply styling properties to SVG content using presentation attributes.

If the user agent supports Cascading Style Sheets, level 2 revision 1 [CSS21], a Conforming SVG Viewer must support CSS styling of SVG content and must support all features from CSS 2.1 that are described in this specification as applying to SVG (see Styling). The supported features from CSS 2.1 must be implemented in accordance with the conformance definitions from the CSS 2.1 specification ([CSS21], section 3.2).

If the user agent includes an HTML or XHTML viewing capability or can apply CSS/XSL styling properties to XML documents, then a Conforming SVG Viewer must support resources of MIME type "image/svg+xml" wherever raster image external resources can be used, such as in the HTML or XHTML ‘img’ element and in CSS/XSL properties that can refer to raster image resources (e.g., ‘background-image’).

D.8.1. Conforming High-Quality SVG Viewer

A higher order concept is that of a Conforming High-Quality SVG Viewer.

A Conforming High-Quality SVG Viewer must support the following additional features:

• Professional-quality results with good processing and rendering performance and smooth, flicker-free animations.
• On low-resolution devices such as display devices at 150dpi or less, support for smooth edges on lines, curves and text. (Smoothing is often accomplished using anti-aliasing techniques.)
• Color management via ICC profile support (i.e., the ability to support colors defined using ICC profiles).
• Resampling of image data must conform to the requirements for Conforming High-Quality SVG Viewers as specified in the description of property image-rendering.
• At least double-precision floating point computation on coordinate system transformation numerical calculations.