SVG/ Start mit SVG

SVG:

Einführung: Beispiel 'Hello World'


SVG
1.1	1.7	8	1.5	3.2	3	?	?	1.x

Einer alten Tradition folgend soll mit einem Beispiel begonnen werden, welches die Zeichenfolge 'Hello World' zur Präsentation bringt:

 <?xml version="1.0"?>

 <svg xmlns="http://www.w3.org/2000/svg"
      version="1.1"
      xml:lang="en">
   <title>Hello World</title>
   <text x="50.5" y="80.25" font-size="20">Hello World</text>
 </svg>

Da jedes SVG-Dokument auch ein XML-Dokument ist, beginnt dies mit einer XML-Verarbeitungsanweisung in der ersten Zeile ohne vorhergehende weitere Zeichen.

Die zweite Zeile ist hier leergelassen. Hier können optional mehrere Zeilen mit XML-Stilvorlagenverarbeitungsanweisungen stehen, gefolgt von einer ebenfalls optionalen Dokumenttypdeklaration (siehe dazu auch das Kapitel Kurze Einführung in XML), im Bedarfsfalle auch mit der Definition eigener Abkürzungen darin.

Dann beginnt das SVG-Dokument mit der Anfangsmarkierung des Elementes svg. Dies ist das Wurzelelement des Dokumentes. Elemente wie svg bilden die Struktur des Dokumentes, ohne selbst unmittelbar zu einer Anzeige eines graphischen Inhaltes zu führen. Solche Elemente der Dokumentstruktur gruppieren Inhalte oder referenzieren sie. Näheres zu solchen Elementen wird im Kapitel Dokumentstruktur diskutiert.

Das Wurzelelement enthält die Angabe des Namensraumes von SVG mit dem Attribut xmlns. Dies ist wichtig, weil jeder XML-Formate spezifizieren darf, zum Beispiel auch die Straßenverkehrsgemeinschaft, die Schienenverkehrsgesellschaft, der 'Sportverein Guckste' oder auch die Sylter Verkehrsgesellschaft. Es gibt viele Möglichkeiten, wofür das Element svg stehen könnte, nicht nur für Skalierbare Vektorgraphik. Erst die Angabe des Namensraumes legt fest, wie die Elemente und die Struktur zu verstehen sind. Der obige gehört zur Skalierbaren Vektorgraphik und zu keiner anderen Möglichkeit.
Auf Namensräume wird ebenfalls näher im Kapitel Kurze Einführung in XML eingegangen.

Ferner ist mit dem Attribut version angegeben, dass die Version 1.1 von SVG verwendet wird.

Ebenfalls notiert ist mit dem allgemeinen XML-Attribut xml:lang die verwendete Sprache für Textinhalt. Weil 'Hello World' englisch ist, wird das entsprechend auf englisch (Wert: en) festgelegt.

Als nächstes folgt ein Element title mit einem für den Inhalt charakteristischen Titel für das Dokument. Ein SVG-Dokument ohne title ist zwar technisch möglich, überspitzt formuliert aber inhaltlich sinnlos. Mehr zur sinnvollen Verwendung dieses Elementes ist dem Kapitel Barrierefreiheit zu entnehmen.

Der Inhalt des Elementes title wird nicht direkt als Graphik ausgegeben, sondern erscheint vielleicht als Überschrift des Fensters mit der Graphik. Es handelt sich ebenfalls um ein Element der Kategorie Dokumentstruktur.

Damit der Text als Graphik sichtbar wird, wird sodann das Element text verwendet.
Mit den Attributen x und y wird der Text im Darstellungsbereich positioniert.

Das Element svg hat diesen Darstellungsbereich des Dokumentes erzeugt, in dem die graphischen Elemente dargestellt werden können. Ohne weitere Angaben, welche allerdings sowohl einfach möglich als auch in der Praxis sinnvoll sind, deckt sich der Darstellungsbereich des Dokumentes mit dem aktuell verfügbaren. Wird das Dokument nicht in ein anderes eingebettet, so ist dies der Darstellungsbereich der Anzeige, etwa das Fenster des Darstellungsprogrammes auf dem Monitor oder bei einem Drucker die Größe des Papieres. Wird das Dokument in ein anderes eingebettet, so bestimmt das einbettende Dokument in der Regel den verfügbaren Darstellungsbereich. Das kann allerdings auch so erfolgen, dass wiederum auf das einzubettende Dokument verwiesen wird, um die Größe zu bestimmen. Für den obigen Fall ohne weitere Angaben sollte das einbettende Format allerdings dann Regeln angeben, was zu tun ist, wenn das einzubettende Dokument selbst keine Angaben zur Größe enthält. Eine eindeutige Angabe mit dem noch zu diskutierenden Attribut viewBox für das Element svg vermeidet derartige Komplikationen, ohne eine Anpassung an den verfügbaren Anzeigebereich durch Skalierung zu verhindern.

Elemente, welche direkte graphische Formen repräsentieren, wie eben text oder auch Basisformen wie Rechtecke, Kreise, Ellipsen, Polygone und allgemeine Pfade, werden in weiteren Kapiteln erläutert. Dies sind Grundformen, Pfade und Text als Graphik.

Welche spezifischen Attribute es für ein Element gibt, ist jeweils bei der Beschreibung des Elementes angegeben. Oft hat der Wert eines Attributes eine bestimmte Struktur. Diese ist dann auch genau beschrieben. Sofern es sich um einen immer wiederkehrenden Typ handelt, ist er auch im Kapitel Grunddatentypen erläutert. In obigem Beispiel ergibt sich zum Beispiel die Frage, was als Wert jeweils für x und y und font-size notiert werden kann. Es wird etwa die Schreibweise '50.5' verwendet und nicht '50,5'. Letzteres hätte gegebenenfalls entweder eine andere Bedeutung für x und y als vermutlich beabsichtigt oder wäre sogar ein fehlerhafter Wert für font-size. Wie Zahlen zu notieren sind, ist ebenfalls im Kapitel Grunddatentypen erläutert.

Während die Elemente samt ihren Attributen festlegen, was dargestellt werden soll, gehört obiges font-size zu den Eigenschaften oder Präsentationsattributen, die festlegen, wie etwas dargestellt werden soll. Mit dem Präsentationsattribut font-size wird die Größe der Schrift des Textes angegeben. Präsentationsattribute werden wie gewöhnliche Attribute notiert, haben im Detail aber ein etwas anderes Verhalten, was dem von Eigenschaften in CSS entspricht, die es gleichnamig ebenfalls gibt. Bei obigem Beispiel bleiben da noch zahlreiche Fragen hinsichtlich der Präsentation offen, etwa in welcher Farbe, welche Schriftart etc. Eigenschaften und Präsentationsattribute werden im Kapitel Grafiken formatieren ausführlich vorgestellt. Diese Fragen werden in dem konkreten Beispiel für die Präsentation vom Darstellungsprogramm automatisch beantwortet. Das funktioniert, weil SVG für alle Präsentationsattribute, Eigenschaften und Attribute Rückfallwerte oder ein Rückfallverhalten vorsieht, auf welche vom Darstellungsprogramm zurückgegriffen wird, wenn es im Dokument keine weiteren anwendbaren Angaben gibt. In einigen Fällen, die in obigem Beispiel nicht vorliegen, ist allerdings die Angabe gewisser Attribute notwendig, sonst ist das Dokument fehlerhaft und die Darstellung kann abgebrochen werden.

Der Ursprung des anfänglichen Darstellungsbereiches befindet sich links oben, die x-Richtung zeigt nach rechts, die y-Richtung nach unten. In SVG ist es auch einfach möglich, neue Koordinatensysteme einzuführen oder Inhalte zu transformieren. Dies wird im Kapitel Transformationen erklärt.

Alle Elemente werden entsprechend wieder geschlossen. Das ist immer so bei XML und nicht spezifisch für SVG.

Rechts oben neben diesem Text ist zu sehen, wie eine typische Ausgabe aussehen könnte. Besonders bei Textinhalt sind die Rückfallwerte so definiert, dass die Ausgabe nicht eindeutig ist, also je nach Darstellungsprogramm etwas anders ausfallen darf.

Welche Informationen vermittelt das erste Beispiel?

Jedes SVG-Bild befindet sich im Element svg zwischen der Anfangsmarkierung <svg> und der Endmarkierung </svg>
In dem svg wird ein Namensraum angegeben: xmlns="http://www.w3.org/2000/svg". Dies ist notwendig, um das Format SVG selbst zu identifizieren. Gegebenenfalls gibt es Angaben zu weiteren Namensräumen, um weitere verschiedene verwendete XML-Formate zu identifizieren und miteinander zu mischen. Bei SVG sind es oft XLink, XHTML, RDF oder MathML. Es ist aber auch jedes andere XML-Format möglich. Es wird allerdings nicht jedes Format von jedem Darstellungsprogramm interpretiert. SVG hat aber definierte Regeln, wie nicht interpretierte andere Formate im Zweifelsfalle zu ignorieren sind. Es hat auch Regeln, wo Inhalte in anderen Formaten zu notieren sind, damit sie nicht ignoriert werden, sofern das Darstellungsprogramm sie kennt.
Eine Versionsangabe dokumentiert, welche Version von SVG im Dokument verwendet wird.
Es gibt Elemente, die der Struktur und der Arbeitserleichterung für den Autor dienen, und andere für die Angabe von graphischen Inhalten. Daneben gibt es weitere Elementtypen, etwa solche, die einen Maldienst wie ein Muster oder einen Farbverlauf definieren.
Ein Element title ist wichtig als Textrepräsentation des gesamten Dokumentes.
Die Elemente können Attribute besitzen, denen Werte zugewiesen werden. Elemente samt ihren Attributen beschreiben, was für ein Objekt dargestellt wird. Das Element selbst macht mit seinem Namen eine allgemeine Angabe, die Attribute bestimmen eher im Detail, um was es sich handelt.
Daneben gibt es weitere allgemein anwendbare Attribute wie xml:lang, die jedes Element und dessen Inhalt näher beschreiben können.
Eigenschaften oder Präsentationsattribute bestimmen, wie Inhalte dargestellt werden.
Das anfängliche Koordinatensystem von SVG arbeitet mit der Einheit Pixel des jeweiligen Ausgabegerätes. Der Ursprung befindet sich links oben, davon wird die x-Achse nach rechts gezählt und die y-Achse nach unten.

Grunddatentypen

In SVG teilen einige Attributwerte und Eigenschaftswerte eine gemeinsame Datenstruktur oder ‑syntax. Wenn ein Attributwert oder Eigenschaftswert eine solche allgemeine Struktur hat oder aus einer Liste solcher Strukturen besteht, ist in der Beschreibung jeweils nur ein Schlüsselwort angegeben.

Solch allgemeine Strukturen sind hier erläutert. Beim ersten Lesen kann ein Überfliegen reichen, im Zweifelsfalle ist das aber später genau nachzusehen, weil davon die Funktion diverser Anwendungen abhängen kann.

Zahlen

Häufig ist in Form von Zahlen anzugeben, wo eine graphische Form positioniert sein soll oder wie groß sie ist, allgemein der Wert eines Attributes oder einer Eigenschaft. Die verwendbaren Zahlen sind in SVG angegeben. Wichtig ist etwa bei nicht ganzzahligen Zahlen, dass zur Abtrennung des nichtganzzahligen Teiles ein Punkt '.' verwendet wird, nicht wie im deutschen Sprachraum ein Komma. Einmal abgesehen von Farbangaben, die getrennt diskutiert werden, erfolgen die Angaben im Dezimalsystem (Ziffern 0 bis 9).

Ganze Zahlen als einzig erlaubte Werte kommen in SVG eher selten vor, können aber ebensogut wie nichtganzzahlige Zahlen notiert werden.

Folgendes sind Beispiele für korrekt notierte Zahlen:

73.1234
-0.002
.154
-.897
+13.2
0000.123
1.24E+2 (wissenschaftliche Notation, hinter dem E nur ganze Zahlen, Vorzeichen optional)
1.24e+2 (wissenschaftliche Notation)
1E0 (wissenschaftliche Notation)
-.0E-1 (wissenschaftliche Notation)

Folgendes sind Beispiele für falsch notierte Zahlen:

73,1234 (Komma nicht als Trennzeichen für den nicht ganzzahligen Bereich)
1.000,7432 (keine weiteren Trennzeichen außer dem Punkt für den nicht ganzzahligen Bereich)
1,000.7432 (keine weiteren Trennzeichen außer dem Punkt für den nicht ganzzahligen Bereich)
- .897 (Leerzeichen zwischen Vorzeichen und Zahl nicht erlaubt)
+ 13.2 (Leerzeichen zwischen Vorzeichen und Zahl nicht erlaubt)
1.24D+2 (für wissenschaftliche Notation nur E oder e)
7.9e-1.7 (hinter dem E nur ganze Zahlen)
A8 (keine Hexadezimalnotation)
E+2 (vor dem E muss eine Zahl stehen)

Ferner ist der Bereich eingeschränkt, aus dem Zahlen verwendet werden können, bei den tiny-Profilen ist der erlaubte Bereich -32767.9999 bis +32767.9999
Zudem dürfen nicht mehr als 4 Stellen hinter dem Punkt angegeben werden.

Diese Einschränkung hängt vor allem damit zusammen, dass tiny-Dokumente von Mobiltelephonen interpretiert werden können sollen. Diese haben nicht so leistungsfähige Prozessoren wie vollwertige Rechner oder notebooks. Aufgrund der technischen Einschränkung hilft es natürlich auch nicht, diese Beschränkung mit Tricks wie Skalierungen und Verschiebungen von Koordinatensystemen zu umgehen (obgleich dies nicht explizit ausgeschlossen wurde).

Bei dem kompletten Profil 1.1 ist der erlaubte Bereich deutlich größer, mindestens -3.4e+38 bis +3.4e+38 muss interpretiert werden. Natürlich, sofern es für das Dokument ausreicht, ist es vorteilhaft, sich auf Werte zu beschränken, die für tiny erlaubt sind, so können diese Dokumente von allen Darstellungsprogrammen interpretiert werden, wenn sie keine weiteren Angaben enthalten, die im tiny-Profil nicht vorkommen.

Längen

Längen beschreiben einen Abstand. Eine Länge ist eine Zahl, optional gefolgt von einer Einheit. In den tiny-Profilen entfällt die Einheit mit Ausnahme der Längenangaben in den Attributen width und height des Hauptelementes svg. Ohne Angabe einer Einheit ist die Einheit '1' im lokalen Koordinatensystem. Mögliche Einheiten sind die in CSS2.0 (!) genannten, für SVG 1.1 und SVG tiny 1.2: em, ex, px, pt, pc, cm, mm, in und Prozentangaben.

em und ex beziehen sich auf die aktuelle Größe der Schriftart.

px entspricht 1 in lokalen Koordinaten. Bei diversen Attributen sind nur Angaben in lokalen Einheiten also ohne Angabe der Einheit erlaubt.

Die absoluten Einheiten pt, pc, cm, mm und in sind alle eindeutig ineinander umrechenbar. Zur Umrechnung dieser Einheiten in px oder lokale Koordinaten braucht das Darstellungsprogramm allerdings immer eine weitere Information, zum Beispiel über die Auflösung des Monitors oder Druckers, wo die Graphik darzustellen ist. Auflösung ist hier im üblichen Sinne gemeint als Pixel pro Meter oder in amerikanischen Einheiten dpi (dots per inch). Zum einen ist dieser Umrechnungsfaktor insbesondere bei Monitoren vielen Darstellungsprogrammen nicht bekannt und zum anderen kann der Faktor je nach Monitor und Nutzer variieren. Genaugenommen wäre die Angabe der Auflösung bei den meisten Betriebssystemen und Monitoren seit Jahren problemlos verfügbar, viele Darstellungsprogramme lesen diese verfügbare Information aber nicht aus, sondern arbeiten mit willkürlichen Schätzungen.

So oder so ist dem Autor der Umrechnungsfaktor nicht bekannt, was die Anzeige für ihn beim späteren Nutzer schwer vorhersagbar macht, wenn absolute Einheiten insbesondere mit lokalen Einheiten gemischt werden.

Die Größe von em oder ex kann der Autor hingegen im Dokument entweder mit absoluten Einheiten oder in lokalen Einheiten eindeutig festlegen. Geschieht dies nicht, ergibt sich em aus den Voreinstellungen des Nutzers. ex ergibt sich aus der jeweiligen Schriftart relativ zu em. Soweit der Autor keine eigene Schriftart angelegt hat, wo diese Einheit präzise festgelegt ist, ist auch hier der Umrechnungsfaktor relativ zu em nur schwer vorhersagbar.

Bei einer Mischung von solchen Einheiten mit Angaben im lokalen Koordinatensystem wird es also dazu kommen, dass der Autor das jeweilige Ergebnis nicht vorhersagen kann. Es empfiehlt sich also in der Regel das Vorgehen wie bei den tiny-Profilen, Einheiten nur bei width und height des Hauptelements svg anzugeben, dann ist sichergestellt, dass die Größen innerhalb der Graphik relativ zueinander immer gleich sind.

Prozentangaben werden bei verschiedenen Anwendungen unterschiedlich interpretiert. Bezieht sich die Angabe auf einen Anzeigebereich, wie bei width und height des Hauptelementes svg, so ist der prozentuale Anteil des verfügbaren Anzeigebereiches gemeint. Bei anderen Prozentangaben, die sich auf den Anzeigebereich beziehen, ist das der prozentuale Anteil der Diagonale desselben.

Bei der Interpretation des Dokumentes werden die Einheiten jeweils in lokale Einheiten umgerechnet, bevor der graphische Inhalt dargestellt wird. In der Praxis zeigt sich, dass viele Darstellungsprogramme Probleme mit der korrekten Umrechnung haben (Stand: 2001/2018). Besonders bei der Addition und Interpolation bei Animationen können grobe Fehler auftreten, weswegen dringend zu raten ist, keine verschiedenen Einheiten anzugeben und am besten alles in lokalen Einheiten zu notieren, um Problemen aus dem Wege zu gehen. Explizit ausgenommen sind davon die genannten width und height des Hauptelements svg. Kombiniert mit einer viewBox in lokalen Koordinaten kann dort eine Größenangabe in absoluten Einheiten, in em, ex oder Prozent sehr sinnvoll sein und hat nur zur Folge, dass der Inhalt einmal komplett skaliert wird. Allerdings ist meist bei der Anzeige auf einem Monitor nicht damit zu rechnen, dass bei einer Angabe wie width="10cm" wirklich eine Anzeige mit einer Breite von 10cm erfolgt. Aufgrund der genannten Mängel der Darstellungsprogramme wird sich vermutlich meist eine andere Breite der Darstellung auf dem Monitor ergeben. Drucker können solche Angaben eher korrekt umsetzen, sofern diese SVG interpretieren können. Da der Fehler der Darstellungsprogramme allerdings nur auf einem falschen Konversionsfaktor beruht, bleibt immerhin das Aspektverhältnis korrekt.

Weitere Probleme bei Längeneinheiten ergeben sich in der Praxis aus verwirrenden oder gar widersprüchlichen Angaben in CSS 2.1 zum Zusammenhang von Pixeln und absoluten Längenangaben (in Zentimeter, Millimeter, Zoll etc), die leider auch Einfluß auf Darstellungsprogramme für SVG haben können. Eine falsche Interpretation der verwirrenden Angaben führt etwa zu der verwegenen Praxis, einen Zoll mit 96 Pixeln zu identifizieren und entsprechend die Länge von interationalen Standardeinheiten wie mm und cm von diesem falsch definierten Zoll abzuleiten.

Eine damit verwandte Verwirrung ergibt sich etwa bei neueren Versionen von Inkscape (~0.92), wo es Probleme bei der korrekten automatischen Dimensionierung von per Element image eingebundenen Pixelgraphiken geben kann. Was bei früheren Versionen problemlos automatisch funktioniert hat, erfordert nun oftmals ein manuelles Eingreifen der Autoren. Inkscape bestimmt die automatisch angenommene Größe kaum nachvollziehbar nicht aus der Äquivalenz der Pixel zu lokalen Einheiten, sondern aus eigenen Hypothesen zur Umrechnung von Pixeln in Zoll, auch wenn die Graphik durchgehend lokale Einheiten und gar kein Zoll verwendet. Kurzum, die Einheitenverwirrung von CSS 2.1 zieht zunehmend weitere Kreise mit teils überraschenden Auswirkungen.

Umrechnung zwischen den Einheiten und Beschreibung in Tabellenform:

Einheit	SVG-Abkürzung	Beschreibung
Pixel	px	Ein Pixel, eine Einheit in lokalen Koordinaten
Geviertbreite und -höhe	em	Schriftgröße der aktuellen Schriftart
x-Höhe	ex	Die Höhe des Buchstabens x in der aktuellen Schriftart (bei einer Schriftart immer relativ zu em exakt festlegbar, beziehungsweise geschätzt, wenn nicht festgelegt und kein x vorhanden ist)
Punkt, englisch: point	pt	0.3527mm oder 1/72 Zoll
Pica	pc	4.23mm oder ⅙Zoll oder 12pt
Millimeter	mm	ein Millimeter
Zentimeter	cm	zehn Millimeter
Zoll, englisch: inch	in	25.4 Millimeter

Koordinaten

Eine Koordinate ist eine Längenangabe im lokalen Koordinatensystem, also der Abstand zum Ursprung in Richtung der x- beziehungsweise y-Achse.

Listen

In SVG sind Attributwerte häufig Listen, zum Beispiel von Zahlen. Wie die Listen zu notieren sind, ist insbesondere in SVG 1.1 nicht ganz einheitlich geregelt, in SVG tiny 1.2 wurde jedoch versucht, dies weitgehend zu verschiedenen Gruppen zu vereinheitlichen.

Oft geht es um Listen, bei denen die Listenpunkte mit Leerraum (englisch: whitespace) zu separieren sind. Dabei handelt es sich neben dem normalen Leerzeichen auch um jene Zeichen, die verwendet werden, um Zeilenumbrüche im Quelltext zu erreichen. Je nach Betriebssystem wird das mit einem oder mehreren Zeichen erreicht, die alle als Leerraum angesehen werden. Es können dann mehrere davon in beliebiger Reihenfolge zur Separation genommen werden. Auch der Liste vorangestellter oder nachfolgender Leerraum ist zulässig.

Ein weiterer Listentyp ist der mit einem Komma als Separator. Auch da kann vor und nach dem Komma noch Leerraum stehen. Ein Komma darf jedoch weder dem ersten Listenwert vorangehen, noch dem letzten folgen (Im Falle von Animationen wird anstatt des Kommas ein Semikolon verwendet. Damit können dann auch Listen animiert werden).

Zudem gibt es dann die Möglichkeit, dass der Autor sich bei jedem Separator aussuchen kann, ob dies nur Leerraum ist oder auch ein Komma enthält. Dies ist die häufigste Möglichkeit. Die wird auch kurz 'durch Leerraum oder Komma separierte Liste' genannt.

Leerraum in diesem Sinne sind als unicode: #x9, #xD, #xA, #x20
oder anders notiert: "space" (U+0020), "tab" (U+0009), "line feed" (U+000A), "carriage return" (U+000D),
also das normale Leerzeichen, Tabulatorzeichen, Zeilenvorschub und Wagenrücklauf.

IRI, URI, URL

IRI (englisch: internationalised resource identifier), URI (englisch: unified resource identifier) und URL (englisch: unified resource locator) sind Referenzen zu (anderen) Dokumenten oder Dokumentfragmenten. Die Identifizierer sind etwas allgemeiner als die Lokatoren. Letztere bezeichnen vor allem eindeutig, wo das bezeichnete Dokument(fragment) zu finden ist, während Identifizierer auch der eindeutigen Identifizierbarkeit dienen können, nicht immer auch der direkten Lokalisierbarkeit.

Derartige Konstruktionen sind formatunabhängig festgelegt, also nicht spezifisch für SVG.

An einigen Stellen ist auch eine funktionale Notation vorzunehmen, besonders bei Eigenschaften oder den damit äquivalenten Präsentationsattributen trifft dies zu. Die funktionale Notation einer IRI sieht wie folgt aus: url("IRI") Dabei steht IRI für die zu notierenden Referenz. Die Buchstabenkombination 'url' gilt dabei unabhängig davon, ob es sich um eine IRI, URI oder URL handelt.

Sprachidentifizierer

Ein Sprachidentifizierer dient der Angabe einer gesprochenen oder geschriebenen Sprache wie deutsch oder englisch. Insbesondere kann für Fragmente von Dokumenten, die Text enthalten, damit maschinenlesbar und -verstehbar die verwendete Sprache angegeben werden. Dazu dienen eindeutig definierte Sprachmarkierungen. Derartige Konstruktionen sind formatunabhängig festgelegt, also nicht spezifisch für SVG.

Fragmentidentifizierer

Fragmentidentifizierer sind eindeutige Bezeichner für Dokumentfragmente, die also in dem jeweiligen Dokument nicht mehrmals in gleicher Form auftauchen dürfen. Typische Attribute, die einen Fragmentidentifizierer als Wert haben, sind in SVG id und in SVG tiny 1.2 und XML allgemein auch xml:id.

Die Konstruktion beginnt immer mit einem Buchstaben (a-z, A-Z ohne Sonderzeichen) oder dem Zeichen '_' oder ':', optional gefolgt von weiteren Buchstaben oder Ziffern oder folgenden Zeichen: '.', '-', '_', ':'. Derartige Konstruktionen sind formatunabhängig festgelegt, also nicht spezifisch für SVG. Exakt sind die erlaubten Zeichen in der XML-Spezifikation unter dem Stichwort 'Name' nachzulesen.

Medientypen

Insbesondere wenn auf andere Dokumente verwiesen wird oder diese in das aktuelle Dokument eingebettet werden sollen, ist es relevant, den Medientyp des jeweiligen anderen Dokumentes machinenlesbar und -verstehbar angeben zu können, dazu dienen speziell definierte Medientypenmarkierer oder internet-Medientypen, ehemals auch MIME-Typen genannt (englisch: Multipart Internet Mail Extensions).

Genauigkeit

Hinsichtlich der Genauigkeit der Darstellung werden in den Spezifikationen ebenfalls Angaben gemacht. In der finalen Darstellung auf dem Bildschirm (oder beim Ausdruck) soll eine Genauigkeit nicht schlechter als ein Pixel des Ausgabegerätes erreicht werden, wenn möglich besser. Bei einer Entdeckung einer größeren Ungenauigkeit bei einem Darstellungsprogramm ist dies also das Kriterium, um zu beurteilen, ob das Programm fehlerhaft arbeitet oder ob das eine erlaubte Toleranz ist.

Zeichenreihenfolge

In SVG wird das sogenannte Malermodell verwendet, um die Zeichenreihenfolge festzulegen, wenn mehrere darzustellende Elemente in einem Dokument vorliegen – was meistens der Fall sein wird. Die darzustellenden Elemente werden in der Reihenfolge gemalt, wie sie im Quelltext stehen. Also was weiter vorne steht ist unten und gegebenenfalls teilweise oder ganz verdeckt. Was zuletzt im Quelltext steht, ist oben und verdeckt gegebenenfalls Elemente, die früher im Quelltext stehen.

Ausnahmen ergeben sich dadurch, dass nicht alle Elemente darzustellen sind. Das ist dann im Detail zu diskutieren, wenn die entsprechenden Elemente vorgestellt werden. Als kurzer Ausblick: Elemente, die in einem defs-Element notiert sind, sind nicht direkt darzustellen, haben im Malermodell also auch keine bestimmte Position, solange sie nicht zum Beispiel mit dem Element use zur Darstellung referenziert werden. In diesem Falle wird das darzustellende Element use dann durch das referenzierte Elemente ersetzt und die Position von use im Quelltext bestimmt die Zeichenreihenfolge.

Für einen Autor ist also hauptsächlich relevant, die Elemente im Quelltext in der für ihn richtigen und wichtigen Reihenfolge anzuordnen, wenn sie sich überlappen. Diese Reihenfolge ist allenfalls mit subtilen Tricks zu ändern. Für zukünftige Versionen von SVG wird allerdings über eine Funktionalität ähnlich der Eigenschaft z-index von CSS diskutiert.

Der wesentliche Trick bei einer scheinbaren Änderung der Zeichenreihenfolge besteht darin, den Betrachter über den Sachverhalt hinwegzutäuschen, dass die Zeichenreihenfolge gar nicht geändert wurde. Dazu werden einige verschiedene Möglichkeiten von SVG ausgenutzt und Eigenschaften des menschlichen Denkens und der Wahrnehmung, welche von der Evolution her darauf optimiert sind, Objekte räumlich einzuordnen und zu interpretieren und veränderliche Strukturen als Bewegungen zu interpretieren.

Das erste Beispiel zeigt sowohl den einfachen Sachverhalt, dass nacheinander im Quelltext stehende Objekte übereinander gemalt werden, als auch eine Methode, mit der suggeriert wird, dass dem nicht so sei:
Verkeilte Vierecke.
Vier teiltransparente symmetrisch angeordnete Rechtecke liegen so, dass eine Ecke eines Rechtecks jeweils eine Ecke eines anderen Rechtecks verdeckt. Das passiert reihum, bis es beim letzten Rechteck zu einem Problem der Zeichenreihenfolge kommt. Daher wird dieses in Teile zerlegt und der problematische Teil wird vor den anderen Rechtecken gemalt.

Ein problematisches Objekt wird also an unkritischen Stellen in mehrere Objekte aufgetrennt, die entsprechend dem gewünschten Effekt im Quelltext in die beabsichtigte Reihenfolge gebracht werden.

Teilweise durchsichtige verkeilte Vierecke

Das Vorgehen wird insbesondere bei teildurchsichtigen Objekten problematisch, wenn diese aufgrund von Rundungsfehlern vom Darstellungsprogramm geringfügig falsch positioniert oder dimensioniert werden. Wegen der Teiltransparenz kann hier nicht mit einem Überlapp gearbeitet werden, um solche Ungenauigkeiten der Darstellungsprogramme zu vertuschen. Folgendes ist ein entsprechendes Beispiel mit teilweise durchsichtigen Füllungen und Strichen:
Teilweise durchsichtige verkeilte Vierecke.
Je nach Größe des Darstellungsbereiches ist bei einigen Programmen der Schnitt zu erkennen. Dies kann weitgehend umgangen werden, wenn der Schnitt entlang von ohnehin vorhandenen Kanten erfolgt. Bei so einfachen Objekten wie in diesem Beispiel ergibt sich ferner die Möglichkkeit, die aus der Teiltransparenz resultierenden Farbwerte zu berechnen und die kritischen Stellen mit entsprechenden nicht transparenten Objekten zu verdecken.

Tribar als Beispiel für ein Penrose-Vieleck

Mit präziser Berechnung und mit ebenfalls in SVG verfügbaren Farbverläufen kann ferner der Eindruck eines dreidimensionalen Objektes erweckt werden, obwohl es in SVG immer nur um Flächen geht. Dies kann sogar so weit ausgenutzt werden, dass dem Betrachter Objekte untergeschoben werden können, die lokal räumlich aussehen, als Gesamtobjekt aber so gar nicht möglich sind:
Tribar als Beispiel für ein Penrose-Vieleck.
Der Eindruck von vorne und hinten wird hier einfach durch eine präzise berechnete Anordnung von Flächen erweckt, die zudem mit Farbverläufen gefüllt sind, die einen Beleuchtungseffekt vortäuschen und so das Objekt plastisch erscheinen lassen.

Noch interessanter wird die Situation, wenn sich die Reihenfolge scheinbar zeitlich ändern soll. Bei folgendem Beispiel soll der Eindruck erweckt werden, dass sich ein Planet um eine Sonne dreht. Bei einer Seitenansicht ist der Planet also einmal vor der Sonne und einmal dahinter:
Umrundung eines Objektes.
Der gewünschte Effekt wird bei diesem Beispiel dadurch erreicht, dass einfach ein Objekt vor der Sonne animiert wird und eines dahinter. Mit einem passenden Zeitablauf wird einfach jeweils eines der beiden Objekte komplett transparent gesetzt. Entsprechend könnte auch die Anzeige oder Sichtbarkeit animiert werden. Ein anderer Ansatz wäre ein zeitabhängiger Ausschnitt (clip-Funktion in SVG), oder eine zeitabhängige Maske (mask-Funktion in SVG), wobei das eine Objekt als Ausschnitt beziehungsweise Maske für die Darstellung der anderen dient.

In einer komplizierteren Situation können auch einfach alle Objekte im Element defs notiert werden. Diese werden von entsprechend vielen use-Elementen referenziert, bei denen mit dem gewünschten Zeitablauf einfach animiert wird, welches Objekt jeweils referenziert wird:
Zufällig bewegte Kreise.

Kombiniert mit präziser Berechnung des Zeitablaufes und der perspektivischen Projektion kann so zumindest für einfache Objekte leicht der Eindruck von dreidimensionalen bewegten Objekten erzeugt werden:
Animierter Sterntetraeder.

Kompliziertere aperiodische Zeitabläufe sind so allerdings nur über einen endlichen Zeitraum darstellbar. Insofern ist es sehr hilfreich, dass für die nächste Version von SVG eine Möglichkeit vorgesehen ist, die Zeichenreihenfolge zu ändern. Auch perspektivische Projektionen sind in Vorbereitung, wodurch sich in Zukunft für den Autor der rechnerische Zeitaufwand deutlich reduzieren wird, um solche Effekte zu erreichen.

SVG: