Some SVG displaying software will not display animations or other run-time modifications - for example, server side rasterizers or SVG-enabled printers.TherefFore, this specification has different conformance levels for static and dynamic SVG viewers.
D.2 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.
All examples are informative, not normative. All chapters are normative except for specific sections marked as being informative. All appendices state whether the appendix is normative or informative. In the case of a conflict between the prose of this specification and the RelaxNG schema, the prose is authoritative (for example, the prose description of some attributes has an EBNF grammar for allowed values, which the RelaxNG is not able to express). Similarly in the case of a conflict between a DTD or W3C XML Schema and the RelaxNG schema, the RelaxNG is authoritative (RelaxNG can express some constraints on content models that are problematic to express in W3C XML schema, and expresses namespaces in a natural and more general way than a DTD is able to).
D.3 SVG Content Conformance
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) including SVG's schema (see Relax NG schema) and also:
-
Is well-formed as defined
in either XML 1.1 or
XML 1.0 and conforms to
Namespaces in XML 1.1;
-
Matches the NVDL script below, or alternatively if after having
removed all elements not in the SVG namespace, and all attributes on
elements in the SVG namespace that are in a namespace that isn't
that of XLink, XML Events, or XML attributes, it validates against
the Relax NG schema;
-
Where the specification provides further constraints not expressed
in the schema (such as for instance EBNF grammars for attribute
values), it complies to them.
NVDL script:
<rules xmlns='http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0'>
<namespace ns='http://www.w3.org/2000/svg'>
<validate schema='Tiny-1.2.rng'>
<mode>
<namespace ns='http://www.w3.org/2000/svg' match='attributes'>
<reject/>
</namespace>
<namespace ns='' match='attributes'>
<attach/>
</namespace>
<namespace ns='http://www.w3.org/XML/1998/namespace' match='attributes'>
<attach/>
</namespace>
<namespace ns='http://www.w3.org/1999/xlink' match='attributes'>
<attach/>
</namespace>
<namespace ns='http://www.w3.org/2001/xml-events' match='elements attributes'>
<attach/>
</namespace>
<anyNamespace match='elements attributes'>
<mode>
<anyNamespace>
<allow/>
</anyNamespace>
</mode>
</anyNamespace>
</mode>
</validate>
</namespace>
</rules>
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.
A document is a Conforming SVG Stand-Alone Document if:
- it conforms to the criteria for Conforming SVG Document Fragment; and
- its root element is an 'svg' element in the SVG namespace.
SVG document fragments can be included within parent XML
documents using the XML namespace facilities described in Namespaces in
XML 1.1.
An SVG document fragment that is included within a parent XML document
is a Conforming Included SVG Document Fragment if the SVG document
fragment, when taken out of the parent XML document, conforms to the
criteria for Conforming SVG Document Fragments.
In particular, note that individual elements from the SVG
namespace cannot be used by themselves. Thus, the SVG
part of the following document is not conforming:
<ParentXML xmlns="http://ns.example/">
<!-- 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 Included
SVG Document Fragment, the document could be modified as follows:
<ParentXML xmlns="http://ns.example/">
<!-- 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>
It is sometimes desirable to create content conforming to a larger profile, and have fallback to a lower profile. For example, some SVG content might have a switch element where one branch, protected by a test attribute that will evaluate to false in a conformant SVG 1.2 Tiny viewer, uses features not available in SVG Tiny 1.2 (pattern fills, clipped images, filter effects) and another branch has SVG Tiny 1.2 content (such as a gradient fill). The parts of the content that will be rendered by an SVG Tiny 1.2 viewer are all SVG Tiny 1.2, yet the content a s awhole does not conform to SVG Tiny 1.2.
An SVG document fragment is a Conditionally Conforming SVG Tiny 1.2 Document Fragment if:
- All elements with a requiredFeature string not defined in this specification are marked as false
- All elements with a requiredExtension are marked as false
- The document fragment is transformed to remove all elements (and their children) marked false
- The transformed document fragment is a Conforming SVG Document Fragment
A Conforming SVG Generator is a program which:
When writing elements that have an ID defined, SVG Generator
SHOULD prefer the 'xml:id'
attribute [XMLID] over the 'id' attribute
for content that is known to target SVG versions 1.2 and above, and
SHOULD include both if the content is intended to work for versions
prior to 1.2. If both 'xml:id'
and 'id' are included on the
same element, their value MUST be the same.
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.
Conforming SVG Authoring Tools must meet all the requirements of a Conforming SVG Generator. Additionally, a Conforming SVG Authoring Tool must conform 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.)
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 content is compressed with gzip or deflate (i.e.an svgz file), Conforming SVG Servers must indicate this with the
"Content-Encoding: gzip" or "Content-Encoding: deflate" headers, as appropriate,if the protocol supports them.
Note: This compression of content (the entity,in HTTP terms) is distinct from automatic compression of the message,as defined in HTTP/1.1 TE/Transfer Encoding.
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.
In a Conforming SVG Interpreter, the XML parser
must be able to parse and process all XML constructs defined
within [XML11] and
[XML-NS].
A Conforming SVG Interpreter must be able to parse and process a conforming SVG Tiny 1.1 document fragment [SVGM11].
There are two sub-categories of Conforming SVG
Interpreters:
- Conforming Static SVG Interpreters must be able
to parse and process the static language features of SVG that
correspond to the feature string "http://www.w3.org/Graphics/SVG/feature/1.2/#SVG-static" (see Feature strings).
- In addition to the requirements for the static category,
Conforming Dynamic SVG Interpreters must be able to
parse and process the language features of SVG that
correspond to the feature string "http://www.w3.org/Graphics/SVG/feature/1.2/#SVG-all" (see
Feature strings) and
which support all of the required features in the SVG DOM described in this
specification.
A Conforming SVG Interpreter must parse any SVG document
correctly. It is not required to interpret the semantics of all
features correctly. It needs only check the syntax of
attribute values on elements in the SVG namespace, and element
content models in the SVG namespace that it
knows about from the profile it implements (SVG Tiny 1.2).
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. (See 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.
There are two sub-categories of Conforming SVG
Viewers:
- Conforming Static SVG Viewers support the static
language features of SVG that correspond to the feature
string "http://www.w3.org/Graphics/SVG/feature/1.2/#SVG-static" (see Feature strings). This
category often corresponds to platforms and environments
which only render static documents, such as printers.
- Conforming Dynamic SVG Viewers support the
language features of SVG that correspond to the feature
string "http://www.w3.org/Graphics/SVG/feature/1.2/#SVG-all" (see Feature strings). This
category often applies to platforms and environments such as
common Web browsers which support user interaction and
dynamic document content (i.e., documents whose content can
change over time). (User interaction includes support for
hyperlinking, events [e.g., mouse clicks], text selection,
zooming and panning [see Interactivity]. Dynamic document
content can be achieved via declarative animation or by scripts
modifying the SVG DOM.)
Specific criteria that apply to both Conforming Static
SVG Viewers and Conforming Dynamic SVG
Viewers:
- 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/JFIF [JPEG] [JFIF]
and PNG [PNG]
image formats. Other image formats may be supported in addition.
- Resampling of image data must be consistent with the
specification of property 'image-rendering'.
- The viewer must support alpha channel blending of the
image of the SVG content onto the target canvas.
- 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 minumum gzip and deflate, and
then decompress any gzip-encoded
and deflate-encoded
data streams that are downloaded from the server. Implementations
must also support progressive rendering of compressed data streams.
- The viewer must support content using the
data: protocol [RFC2397]
wherever IRI
referencing of whole documents (such as raster images,
SVG documents, fonts and color profiles) is permitted within
SVG content. This support must include use of base64 encoded content.
(Note: fragments of SVG content which do not
constitute an entire SVG document are not available using the
"data:" protocol.)
-
The viewer must support the following W3C Recommendations
with regard to SVG content:
- complete support for the XML 1.1 specification [XML11].
- complete support for "Namespaces in XML 1.1" [XML-NS],
including inclusion of non-SVG namespaces
within SVG content.
(Note that data from non-SVG namespaces are included in
the DOM but are otherwise ignored from the point of
view of rendering and interaction.)
- All visual rendering should be accurate to within one
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.
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.
Specific criteria that apply to only Conforming Dynamic
SVG Viewers:
- In Web browser environments, the viewer must have the
ability to search and select text strings within SVG
content.
- In interactive environments, the viewer must have
the ability to select and copy text from SVG content to the
system clipboard.
The Web Accessibility Initiative [WAI] has defined "User Agent
Accessibility Guidelines 1.0" [UAAG]. A Conforming
SVG Viewer must conform to the Priority 1 accessibility
guidelines defined in [UAAG], and should conform also to Priorities 2
and 3.
A Conforming SVG Viewer must be able to apply
styling properties to SVG content using presentation
attributes (see properties shared with
CSS and XSL).
If the user agent includes an XHTML or SMIL viewing
capability, 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 XHTML
'img' element.
If the user agent can apply CSS/XSL styling properties to XML
documents (including XHTML, SMIL, or XForms documents), then
a Conforming SVG Viewer must support
resources of MIME type "image/svg+xml" in CSS/XSL
properties that can refer to raster image resources (e.g.,
'background-image').