Different sets of SVG conformance requirements exist for:
An SVG document is a Conforming SVG Document if it adheres to the specification described in this document (Scalable Vector Graphics (SVG) Specification) and also:
A file is a Conforming SVG Stand-Alone File if:
SVG document can be included within parent XML documents using the XML namespace facilities described in Namespaces in XML.
An SVG document that is included within a parent XML document is a Conforming Included SVG Document if the SVG document, when taken out of the parent XML document, conforms to the SVG Document Type Definitions (DTD).
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:
<?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/Graphics/SVG/svg-19990706.dtd" 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, 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/Graphics/SVG/svg-19990706.dtd" width="100px" height="100px" > <z:rect x="0" y="0" width="10" height="10" /> </z:svg> <!-- More elements from ParentXML go here --> </ParentXML>
A Conforming SVG Generator is a program which:
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.
An SVG interpreter is a program which can parse and process SVG documents. A Conforming SVG Interpreters must be able to:
An SVG viewer is a program which can parse and process an SVG document and render the contents of the document onto some sort of output medium such as a display or printer. Usually, an SVG Viewer is also an SVG Interpreter.
An SVG Viewer is a Conforming SVG Viewer if:
Although anti-aliasing support isn't a strict requirement for a Conforming SVG Viewer, it is highly recommended. Lack of anti-aliasing support will generally result in poor results on display devices.
A higher class concept is that of a Conforming High-Quality SVG Viewer which must support the following additional features:
The following are implementation notes that correspond to features which span multiple sections of the SVG specifications. (Note that various other sections of this document contain additional section-specific implementation notes.)
SVG makes extensive use of URI references to other objects. For example, to fill a rectangle with a linear gradient, you define a <lineargradient> element and give it an ID (e.g., <lineargradient id="MyGradient"...>, and then you can specify the rectangle as follows: <rect style="fill:url(#MyGradient)"...>.
In SVG, among the facilities that allow URI references are:
Forward references are disallowed. All references should be to elements which are either defined in a separate document or defined earlier in same document. References to elements in the same document can only be to elements which are direct children of a <defs> element. (See Defining referenced and undrawn elements: the <defs> element.).
Invalid references should be treated as if no value were provided for the referencing attribute or property. For example, if there is no element with ID "BogusReference" in the current document, then fill="url(#BogusReference)" would represent an invalid reference. In cases like this, the element should be processed as if no 'fill' property were provided. Where a list of property values are possible and one of the property values is an undefined reference, then process the list as if the reference were removed from the list.
When a graphical object is referenced by another graphical object (such as when referenced graphical object is used as a clipping path), the referenced object does not change location, size or orientation. Thus, referenced graphical objects are "pinned" to the user coordinate system that is in place within its own hierarchy of ancestors and is not affected by the user coordinate system of the referencing object.