Some SVG displaying software will not display animations or
other runtime modifications - for example, server side rasterizers
or SVG-enabled printers. Therefore, 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 necessarily 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 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 according to the version of XML used (either the
XML 1.0 [ XML10 ] or XML 1.1 [
XML11 ]) and conforms to the
corresponding Namespaces in XML specification (Namespaces in XML
1.0 [ XML-NS10 ] or Namespaces
in XML 1.1 [
XML-NS11 XML-NS
]).
- Conforms to all applicable 'C' conformance criteria in
Character Model for the World Wide Web 1.0: Fundamentals [ CHARMOD ]
- 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 the
Namespaces in XML 1.0 specification [ XML-NS10 ] or the
Namespaces in XML 1.1 specification [ XML-NS11 XML-NS ]
(depending on the version of XML used).
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 conditional processing
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 as a whole 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 such as Character Model for the World Wide
Web 1.0: Normalization [ CHARMOD-norm
CHARMOD-NORM ] Future versions of the SVG
specification may require support of that specification 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 . "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 .
An SVG interpreter is a program which can parse and process SVG
document fragments. Examples of SVG interpreters are a search engine (e.g. a service which indexes text,
metadata, or other SVG content), 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 ].
A Conforming SVG Interpreter must conform to all
applicable 'I' conformance criteria in Character Model for the
World Wide Web 1.0: Fundamentals [ CHARMOD ].
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
.)
A Conforming SVG Interpreter which indexes
SVG content (e.g. a search engine) must, at a minimum, extract and
process all textual data, including the content of the
text content
elements and descriptive
elements ,with attention
paid to author-supplied alternate languages for purpose of
presentation and translation. Additionally, it should process
element types, document structure, metadata, and link data to
inform the indexing. A Conforming SVG Interpreter which indexes
images should categorize and represent SVG content as an image.
Such an SVG Interpreter may apply heuristics to the geometric
semantics of the SVG document or to the rendered image (such as
performing shape-recognition) to improve indexing.
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 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 .
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 .
Specifications and implementations are allowed to extend the SVG
specification but in order to claim conformance the following
criteria need to be met:
- An extension must support the normative chapter of the SVG
specification that defines conformance to SVG.
- An extension must support the normative chapter of the SVG
specification that details extensibility.
- An extension must support the normative chapter of
the SVG specification that defines conditional
processing. If using features defined in SVG Full, an extension
must not redefine the syntax of the syntax of those features. An
extension must not redefine the semantics of any existing SVG
element or attribute. SVG attribute and element names must not be
reused in extensions, even in a separate namespace, in order to
avoid author confusion. D.7 Non-XML Encoding Conformance
Requirements An SVG Document Fragment, SVG Stand-Alone Document or
SVG Included Document encoded using a non-XML encoding (e.g.
efficient XML compression) conforms to this specification if and
only if the non-XML encoding in question guarantees roundtripping
from XML to the encoding and back in such a way that the resulting
document when processed by an SVG user-agent must always render,
animate, and interact in the exact same way as the original. Note
that this requires a high-level of fidelity from the encoding
including, but not limited to, the ability to encode non-conforming
content and content from foreign namespaces without loss,
maintaining ID typing supplied by the internal subset of the formal
part the Document Type Definition, and not remo th