Scalable Vector Graphics

Scalable Vector Graphics (SVG, englisch für skalierbare Vektorgrafik) ist die vom World Wide Web Consortium (W3C) empfohlene Spezifikation zur Beschreibung zweidimensionaler Vektorgrafiken. SVG, das auf XML basiert, wurde erstmals im September 2001 veröffentlicht. Einige der gebräuchlichsten Webbrowser können ohne nachträgliche Installation von Erweiterungen einen Großteil des Sprachumfangs darstellen. Beim Internet Explorer bis Version 8 ist dafür die Installation einer Erweiterung (Plug-in) erforderlich.

Animationen werden von SVG mittels SMIL unterstützt. Manipulationen des SVG-DOM sind mit Hilfe eingebetteter Funktionen via Skriptsprachen möglich.

Da SVG ein XML-basiertes Dateiformat ist, sind Inhalte von SVG-Dateien für computerunterstützte Übersetzung und andere Weiterverarbeitungen leicht zugänglich. Sie können prinzipiell auch direkt mit einem Texteditor bearbeitet werden. Bequemer ist allerdings die Bearbeitung mit speziellen Programmen (siehe Abschnitt SVG-Editoren).

Die empfohlene Dateiendung ist .svg oder, wenn die Datei mit gzip komprimiert ist, .svgz. Der MIME-Typ ist image/svg+xml.<ref>Introduction – SVG 1.1 World Wide Web Consortium, 14. Januar 2003</ref>

Geschichte

1998 wurden zwei Sprachen beim World Wide Web Consortium (W3C) zur Standardisierung eingereicht:

• Vector Markup Language (VML) von Microsoft und Macromedia.
• Precision Graphics Markup Language (PGML) von Adobe, IBM, Netscape und Sun.

Das W3C übernahm aber keine der beiden Sprachen als Empfehlung, sondern vereinigte sie und entwickelte sie unter eigener Regie weiter. Detaillierte Gründe für die Entwicklung einer neuen Sprache sind unter anderem einer detaillierten Anforderungsliste im ersten Arbeitswurf zu entnehmen.<ref>SVG Requirements</ref>

Am 4. September 2001 veröffentlichte das W3C unter dem Namen Scalable Vector Graphics (SVG) 1.0 Specification die erste Empfehlung (englisch recommendation).<ref>Scalable Vector Graphics (SVG) 1.0 Specification</ref> Diese Empfehlung wurde von Teilen der IT-Industrie als Standard akzeptiert. Microsoft folgte dem längere Zeit nicht und unterstützte in seinen Anwendungen nur die Vektorsprache VML. Die erste Version des Internet Explorers, die SVG nativ unterstützt, ist Version 9.<ref>Dean Hachamovitch: HTML5, Hardware Accelerated: First IE9 Platform Preview Available for Developers</ref> Ab dem Internet Explorer 10 unterstützt Microsoft VML nicht mehr.

Bereits am 3. August 2001 wurde ein erster Arbeitsentwurf für eine Modularisierung von SVG veröffentlicht, um für mobile Geräte mit geringerem Leistungsumfang dafür geeignete Teile von SVG als Empfehlung zugänglich zu machen.<ref>SVG Mobile Requirements</ref>

Dies führte dann letztlich zu Version 1.1 mit drei Profilen, 'Tiny' für Geräte mit geringer Leistung, 'Basic' für Geräte mit etwas höherem Leistungsumfang und 'Full', das den vollen Funktionsumfang von SVG 1.0 umfasst. Einmal abgesehen von Korrekturen von bekannten Fehlern deckt sich SVG Full 1.1 von den Funktionen und Merkmalen her mit SVG 1.0.

Am 14. Januar 2003 wurden die Empfehlungen zu SVG 1.1 und SVG Mobile veröffentlicht.<ref>Scalable Vector Graphics (SVG) 1.1 Specification</ref><ref>Mobile SVG Profiles: SVG Tiny and SVG Basic</ref>

Diese Empfehlungen wurden danach noch überarbeitet. Die letzte Bearbeitung der mobilen Variante stammt von 2009. Für SVG 1.1 gibt es eine zweite Bearbeitung vom 16. August 2011.<ref>Scalable Vector Graphics (SVG) 1.1 (Second Edition)</ref>

Zunächst wurde geplant, SVG 1.1 mit der Version 1.2 zu erweitern. Dies wurde allerdings primär von Anbietern mobiler Geräte mit Interesse aufgenommen, während die Anbieter von Darstellungsprogrammen für Rechner sich erst einmal auf die Implementierung von SVG 1.1 konzentriert haben. Das Profil für SVG Full 1.2 ist von daher nicht über einen Arbeitsentwurf hinaus gelangt.<ref>Scalable Vector Graphics (SVG) Full 1.2 (Working Draft)</ref>

An der mobilen Version von SVG 1.2 wurde allerdings weitergearbeitet. Inzwischen war bei mobilen Geräten auch eine deutliche Steigerung des Leistungsumfanges eingetreten, weswegen man sich auf ein Profil für den mobilen Markt beschränkt hat. Am 22. Dezember 2008 wurde dann für diese Version eine Empfehlung für ein Tiny-Profil veröffentlicht.<ref>Scalable Vector Graphics (SVG) Tiny 1.2 Specification</ref> Gegenüber 1.1 führt dies einige neue Merkmale und Funktionen ein, etwa von SMIL übernommene Elemente für Audio, Video und der Einbettung von anderen SVG-Dokumenten, das deklarative Entfernen von Elementen aus dem Dokument-Objekt-Modell, neue Erweiterungen für den Zugriff von Skripten auf das Dokument-Objekt-Modell, eingeschränkte Transformationen, Mal-Dienste für Farbe, die Möglichkeit eine Hintergrundfarbe für den Malbereich anzugeben, automatischer Textumbruch, Möglichkeit für interaktive Texteingabe und Änderung von Text. Außerdem ist es gelungen, in dieser Version einige Unklarheiten und Unstimmigkeiten hinsichtlich der deklarativen Animation zu beheben, was zum großen Teil dann auch in die zweite Bearbeitung von SVG 1.1 als Fehlerberichtigung übernommen wurde.

Derzeit aktuelle Spezifikationen sind also die Version SVG Tiny 1.2 und die zweite Bearbeitung von SVG 1.1. Seit 2011 wird an SVG 2 gearbeitet, das zahlreiche Änderungen und Erweiterungen enthält.<ref>SVG2 Planning Page. Abgerufen am 30. Januar 2015. </ref><ref>SVG2 Requirements Commitments. Abgerufen am 8. Juli 2015. </ref> Dessen Fertigstellung soll bis 2016 erfolgen.

Dokument

Als XML-Dokument wird eine SVG in einer Baumstruktur aus verschiedenen Elementen und diesen Elementen zugewiesenen Attributen aufgebaut. Jede SVG-Datei beginnt, wie bei XML-basierten Sprachen üblich, mit der XML-Deklaration. Darauf können Verarbeitungsanweisungen folgen, etwa solche zur Referenzierung externer Stilvorlagen. Darauf kann eine Dokumenttypdeklaration folgen. Zu Version 1.0 und Version 1.1 gibt es entsprechende offizielle DTDs, die referenziert werden können, für SVG Tiny 1.2 gibt es dies nicht, dort kann allenfalls noch die interne Teilmenge notiert werden, etwa um eigene Entitäten zu definieren. Darauf folgt wie bei allen XML-Dokumenten das Wurzelelement, für SVG-Dokumente hat dieses den Namen svg. Um das Element und seinen Inhalt eindeutig dem SVG-Namensraum zuzuordnen und ihm so eine definierte Bedeutung zu geben, die mit den SVG-Empfehlungen zu tun hat, wird der Namensraum beim Wurzelelement mit der XML-Attributkonstruktion xmlns notiert.

<syntaxhighlight lang="xml"> <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg xmlns="http://www.w3.org/2000/svg"

   xmlns:xlink="http://www.w3.org/1999/xlink" 
   xmlns:ev="http://www.w3.org/2001/xml-events"
   version="1.1" baseProfile="full"
   width="800mm" height="600mm"
   viewBox="-400 -300 800 600">
   <title>Titel der Datei</title>
   <desc>Beschreibung/Textalternative zum Inhalt.</desc>

</svg> </syntaxhighlight>

Mit den Attributen width (englisch: Breite) und height (englisch: Höhe) des SVG-Elementes svg wird die Größe der Grafik definiert. Werden diese Attribute nicht gesetzt, wird die Größe impliziert, jeweils entsprechend einem Attributwert von 100% für width und height was 100 % der Höhe und Breite des verfügbaren Anzeigebereiches entspricht. Mit dem Attribut viewBox kann angegeben werden, welcher Bereich der Zeichenebene im Anzeigebereich dargestellt werden soll. Gegebenenfalls erfolgt also eine Transformation dieses Bereiches hin zum Anzeigebereich. Wird das Attribut nicht angegeben, deckt sich der Bereich mit dem Anzeigebereich, es findet also keine Transformation statt. Weil dem Autor die Größe des Anzeigebereiches nicht bekannt ist, ist die Verwendung von viewBox allgemein zu empfehlen, insbesondere wenn für width und height keine Angaben oder die in Prozent notiert sind.

Koordinatensystem und -angabe

Das anfängliche Koordinatensystem hat seinen Koordinatenursprung in der linken oberen Ecke des Zeichenbereichs. Es handelt sich dabei um ein internes, dimensionsloses Koordinatensystem, bei dem die X-Achse nach rechts und die Y-Achse nach unten weist. Dieses Koordinatensystem wird durch die Attribute width (Breite) und height (Höhe) für die Ausgabe dimensioniert. Durch Verwendung des Attributes viewBox und bei den meisten Nachfahren des Wurzelelementes auch durch Verwendung des Attributes transform ergibt sich ein vom anfänglichen Koordinatensystem abweichendes aktuelles Koordinatensystem. Alle relativen und absoluten Längenangaben innerhalb der Grafik werden auf dieses aktuelle Koordinatensystem bezogen.<ref name="coord">SVG – Coordinate Systems, Transformations and Units. W3C, 14. Januar 2003, abgerufen am 10. September 2009. </ref> Als Einheiten können in der Vollversion von SVG sowohl relative (wie em oder Prozent) als auch absolute Angaben (wie Meter oder Zoll) gewählt werden. Dafür stehen in SVG die von der Stilvorlagen-Sprache Cascading Style Sheets bekannten Einheiten<ref name="einh">SVG – Basiseinheiten. CSS4You, 20. Oktober 2006, abgerufen am 3. September 2009. </ref> zur Verfügung. Bei den tiny-Versionen werden im Inhalt hingegen nur dimensionslose Längen verwendet. Lediglich für width und height des Wurzelelementes sind wie in der Vollversion Einheiten zulässig. Dieses Vorgehen ist allgemein für SVG-Dokumente auch in der Vollversion sinnvoll, weil so fehleranfällige Umrechnungen von Einheiten vermieden werden.

Im Gegensatz zu den ganzzahligen Pixelkoordinaten bei Rastergrafiken (z. B. JPEG, PNG, BMP) sind SVG-Koordinaten Gleitkommazahlen. Pixel-Angaben in Rastergrafiken hingegen haben eine beschränkte Auflösung, sind sie doch in ihrem Wertebereich auf ganze Zahlen sowie die Abmessungen des Bildes beschränkt – entsprechend der Natur der Pixel, die ja kleine, gleich große, unifarbene Rechtecke sind. Bei rasterbasierten Ausgabemedien – zum Beispiel einem Monitor – bezeichnet eine SVG-Angabe wie (x = '100' y = '200') nicht den ganzen Bildschirmpixel, sondern dessen obere linke Ecke (oder eine der anderen Ecken der entsprechenden Nachbarpixel). Vorausgesetzt bei diesem Beispiel ist, dass die Skalierung des SVG-Dokuments passend gewählt ist.

Elemente

SVG hat unterschiedliche Typen von Elementen:

• Elemente mit grafischer Präsentation, aufgebaut aus grafischen Primitiven
• Text in einer bestimmten Schriftart, die dem Render-Programm zur Verfügung stehen muss.
• Gruppierungselemente einerseits für darzustellende Elemente, aber auch als Vorrat zur Referenzierung durch andere Elemente
• Elemente zur Bereitstellung von Textalternativen und Metainformationen
• Elemente zur Bereitstellung von Maldiensten wie Farben, Farbverläufen und Mustern, auch von Markierungen, Masken oder Filtern
• Elemente zur Animation
• Elemente zur Aufnahme von anderen Sprachstrukturen (Stilvorlagen, Skripte, darstellbare Fragmente aus anderen Namensräumen)
• Elemente zur Einbettung externer Dokumente (Vektorgrafiken oder auch Rastergrafik), interner und externer Dokumentfragmente
• Elemente zur Definition von Schriftarten und alternativen Darstellungen von Glyphen

Grafische Elemente

Alle grafischen Elemente in SVG bauen auf einfachen Grundelementen, so genannten grafischen Primitiven auf. Durch Kombination mehrerer grafischer Primitive lassen sich komplexe Objekte erzeugen. Für alle grafischen Elemente können Füllung, Art der Umrisslinie und Transparenz durch Attribute festgelegt werden. Die in SVG verfügbaren grafischen Elemente sind:

Pfad

Das Element <path /> definiert eine Kurve, bestehend aus einer beliebigen Anzahl von Unterpfaden, die wiederum aus einer Kombination von Strecken, Ellipsenbögen, quadratischen und kubischen Bézierkurven bestehen, die mit Hilfe von relativen oder absoluten Koordinaten beschrieben werden. Der Pfad kann geschlossen, gefüllt und als Clipping-Pfad verwendet werden. Der Pfad ist das mächtigste Grafikelement in SVG. Praktisch alles, was durch andere Grafikelemente gezeichnet werden kann, kann durch ein Pfad-Element äquivalent dargestellt werden. Die weiteren Grafikelemente existieren, um einerseits eine bessere Nutzbarkeit zu gewährleisten, andererseits aber auch, um die inhaltliche Bedeutung klarer herauszustellen, weil der Notation eines entsprechenden Pfades im Quelltext oft nicht auf den ersten Blick anzusehen ist, ob es sich um einen einfachen Kreis, eine Ellipse, ein Rechteck mit abgerundeten Ecken handelt. Ferner erleichtert es auch die Animation dieser speziellen Formen. Sie können ebenso wie das Pfad-Element als Umriss gezeichnet, gefüllt und zum Clipping benutzt werden (mit Ausnahme des <image />-Elements). Eine weitere Ausnahme ergibt sich daraus, dass die Tiny-Profile keine Ellipsenbögen erlauben, somit sind Kreise, Ellipsen und auch Rechtecke mit elliptisch abgerundeten Ecken in diesem Profil nicht exakt mit dem Element <path /> konstruiert werden, mit den dafür vorgesehenen Spezialelementen schon.

Kreis

Das Element <circle /> definiert einen Kreis, der durch seinen Radius und durch die Position des Mittelpunktes beschrieben wird.

Ellipse

Das Element <ellipse /> definiert eine Ellipse, die durch ihre zwei Halbachsenradien, deren Ausrichtung und, analog zum Kreiselement, durch die Position ihres Mittelpunktes beschrieben wird.

Rechteck

Das Element <rect /> definiert ein Rechteck über die Position seiner oberen linken Ecke, seiner Breite und seiner Höhe. Optional können die Ecken des Rechteckes abgerundet werden.

Linie

Das Element <line /> definiert eine einfache gerade Linie (Strecke), die über die Koordinaten ihrer beiden Endpunkte beschrieben wird.

Polygonzug

Das Element <polyline /> definiert eine beliebige Zahl von Punkten, die als Polygonzug durch Strecken verbunden werden. Die Punkte werden über Koordinatenpaare beschrieben.

Polygon

Das Element <polygon /> definiert ein Vieleck, das über seine Eckpunkte beschrieben wird. Wie beim Polygonzug werden auch hier die Eckpunkte als Koordinatenpaare angegeben und in der Reihenfolge ihrer Definition miteinander verbunden.

Text

Mit dem Element <text /> wird Text in die Grafik eingebettet. Das Textelement kann über Attribute, wie zum Beispiel Schriftgröße und Schriftart, Laufrichtung und Wortabstand formatiert werden. Text kann zudem über Unterelemente wie <tspan /> strukturiert werden.

Bild

Das Element (<image />) bindet eine Rastergrafik ein, die über eine Pfadangabe, Breite und Höhe sowie die Position beschrieben wird.

Gruppierung

Alle diese Elemente können durch das Gruppenelement (<g />) zusammengefasst werden. Transformationen und Styling, die auf das Gruppenelement angewendet werden, gelten für alle damit zusammengefassten untergeordneten Elemente.

Auch das Element <a /> eignet sich entsprechend zur Gruppierung von darzustellenden Inhalten, kann aber zusätzlich eine Verweisfunktionalität bekommen.

Auch das Element <defs /> dient in gewisser Weise der Gruppierung, dessen Inhalt wird aber nicht direkt dargestellt werden, sondern ist als Vorrat gedacht, aus dem andere Elemente referenzieren können.

Textalternativen, Barrierefreiheit und Zugänglichkeit

Wie bei den meisten vom W3C empfohlenen Formaten wird auch bei SVG besonderer Wert darauf gelegt, dass Autoren einfache Möglichkeiten gegeben werden, Inhalte zugänglich anzubieten. Basis ist dabei primär die Möglichkeit der Bereitstellung einer Textalternative. Umgedreht könnte man auch die grafische Repräsentation des Dokumentes als Alternative zu diesem Textinhalt bezeichnen. Fehlt eine hinreichende Textalternative, erlaubt das den formalen Rückschluss, dass das Dokument keine relevante Information enthält.

Jedes SVG-Dokument, das inhaltlich relevant ist, sollte daher mindestens als erstes Kindelement des Wurzelelementes ein Element <title /> haben. Wie der Name schon andeutet, wird darin der Titel des Werkes als Text genannt, etwa im Sinne einer Kurzzusammenfassung. Titel können auch lediglich der Identifikation eines Werkes in einer externen Diskussion dienen (wie man Werke von Künstlern bezeichnet, wenn man über diese Werke diskutieren will).

Auf <title /> kann ein Element <desc /> folgen. Der Inhalt von <desc /> ist eine ausführlichere Beschreibung des Werkes, eher was seine Bedeutung und Funktion anbelangt, als deren grafische Umsetzung. Der Inhalt von <desc /> kann einfacher Text sein, er kann aber auch mit einem anderen XML-Format wie etwa XHTML strukturiert werden. <title /> und <desc /> stellen zusammen die Textalternative zum grafischen Inhalt des Dokumentes dar. Dies ist damit der Kerninhalt des Dokumentes hinsichtlich der Funktion von Barrierefreiheit und Zugänglichkeit und erlaubt somit auch Personen Zugang zur Information des Dokumentes, die die grafische Repräsentation nicht sehen können oder wollen. Da die inhaltliche Bedeutung grafischer Repräsentationen nicht zwangsläufig einfach zu verstehen ist, kann dieser alternative Inhalt natürlich auch für andere Personen sehr nützlich sein. Als Alternative wird jedenfalls diese Textalternative nur dargestellt, falls die grafische Repräsentation nicht dargestellt wird. Zusätzlich kann eine Darstellung der Textalternative erfolgen, wenn der Nutzer dies anfordert.

Auf <desc /> kann ferner ein Element <metadata /> folgen, das primär dazu gedacht ist, Metainformationen über das Dokument zu beinhalten. Diese Metainformationen werden in der Regel strukturiert notiert, damit sie automatisch von Programmen ausgewertet werden können. Zur Strukturierung eignet sich zum Beispiel das XML-Format RDF oder Elemente und Terme gemäß Dublin Core.

Fast alle anderen Elemente von SVG können ebenfalls <title />, <desc /> und <metadata /> mit beschriebener Funktion enthalten, sie bilden dann entsprechend die Textalternative und Metainformation für das Element, in dem sie notiert sind, einschließlich der Nachfahren dieses Elementes.

Das Konzept weist hinsichtlich Mehrsprachigkeit Schwächen auf, insbesondere was das Element <title /> des Wurzelementes anbelangt, das nur mit einer Sprache notiert werden kann. Bei mehrsprachigen Werken kann es also sinnvoll sein, den Inhalt dieses Elementes nur als sprachinvariante Identifikation des Werkes zu betrachten und die eigentliche mehrsprachige Textalternative in den beiden anderen Elementen unterzubringen, die mehr Struktur aufweisen können.

Präsentation und Stilvorlagen

Die Darstellung von Elementen kann mit Präsentationsattributen beeinflusst werden. Festgelegt werden können zum Beispiel Füllung, Konturlinie und Transparenz der Elemente, sowie bei Text die Eigenschaften der Schrift. Zu den Präsentationsattributen gibt es auch jeweils gleichnamige Eigenschaften gemäß Cascading Style Sheets (CSS), die sich eignen, um mit einer Silvorlage eine alternative Präsentation anzubieten. Die Eigenschaften und damit Stilvorlagen sind bei den Profilen vom Typ tiny nicht vorgesehen. Die Präsentationsattribute und die zugehörigen Eigenschaften richten sich dabei in weiten Teilen nach den im XML-Umfeld weit verbreiteten Stilvorlagen-Sprachen XSL und CSS.<ref name="styling">SVG – Styling. W3C, 14. Januar 2003, abgerufen am 10. September 2009. </ref> Über zusätzliche Elemente können nicht nur Farben, sondern auch Farbverläufe und Muster verwendet werden.

Durch die Verfügbarkeit von Präsentationsattributen und Eigenschaften kann ähnlich wie bei der Kombination (X)HTML und CSS eine Trennung zwischen Inhalt und Dekoration vorgenommen werden. Als inhaltlich relevant oder als für das Verständnis des Dokumentes wichtig wird dabei betrachtet, was mit Elementen und Attributen notiert wird, als Dekoration das, was als alternative Präsentation mit Stilvorlagen in einer anderen Sprache wie CSS angeboten wird.

Wie bei allen XML-Formaten können externe Stilvorlagen mit entsprechenden Verarbeitungsanweisungen referenziert werden. Zusätzlich hat SVG auch ein spezielles Element style, in dem Stilvorlagen notiert werden können. Mit einem Attribut style kann zudem bei jedem Element eine Stilvorlage notiert werden. Da dem Attributwert von style allerdings eine recht hohe Priorität zukommt und die Stilvorlage zudem als Attributwert schlecht vom eigentlichen Inhalt getrennt ist, gilt die Verwendung des Attributes als einfach vermeidbar und schlecht hinsichtlich des Prinzips der Trennung von Inhalt und Dekoration.

Transformation

Jedes Element und jede Gruppe von Elementen kann durch eine Reihe affiner Transformationen in Position, Orientierung und Form verändert werden. Die Transformation wird einem beliebigen Element als Attribut angehängt. Zur Verfügung stehen Translation (Parallelverschiebung), Rotation, Skalierung, Scherung, sowie die Kombination verschiedener Transformationen in Form einer 3×3-Matrix. Die Matrix wird auf Punkte in projektiver Darstellung angewandt und stellt somit die Kombination einer linearen Abbildung in Form einer 2×2-Matrix mit einer Translation dar, ohne jedoch zwischen den beiden letzten Abbildungstypen unterscheiden zu müssen.<ref name="transf">SVG – The transform attribute. Abgerufen am 28. August 2009. </ref> Die Transformationen können beliebig kombiniert werden, wobei die Hintereinanderausführung von Transformationen der Multiplikation der Transformationsmatrizen entspricht.

Beispiele: Eine Parallelverschiebung hat in SVG die Darstellung

„translate(tx ty)“ = „matrix(1 0 0 1 tx ty)“ = <math>

\begin{pmatrix} 1&0&t_x\\ 0&1&t_y\\ 0&0&1\\ \end{pmatrix} </math>,

eine Skalierung in x- und y-Richtung

„scale(sx sy)“ = „matrix(sx 0 0 sy 0 0)“ = <math>

\begin{pmatrix} s_x&0&0\\ 0&s_y&0\\ 0&0&1\\ \end{pmatrix}</math>.

Eine Abbildung wirkt auf einen Punkt P – d. h. auf dessen projektive Darstellung in homogenen Koordinaten – indem diese von links mit der entsprechenden Abbildungsmatrix multipliziert wird. Wird P um T verschoben, so sind seine neuen Koordinaten

<math>

T(P) = T\cdot P = \begin{pmatrix}1&0&t_x\\ 0&1&t_y\\ 0&0&1\\ \end{pmatrix} \cdot\begin{pmatrix}p_x\\ p_y\\ 1\\ \end{pmatrix} =\begin{pmatrix}p_x+t_x\\ p_y+t_y\\ 1\\ \end{pmatrix} </math> analog für eine Skalierung mit S:

<math>

S(P) = S\cdot P = \begin{pmatrix}s_x&0&0\\ 0&s_y&0\\ 0&0&1\\ \end{pmatrix} \cdot\begin{pmatrix}p_x\\ p_y\\ 1\\ \end{pmatrix} =\begin{pmatrix}s_x\cdot p_x\\ s_y\cdot p_y\\ 1\\ \end{pmatrix} </math> Für die Hintereinanderausführungen von T und S gilt in diesem Falle

<math>

T\circ S = T\cdot S = \begin{pmatrix}s_x&0&t_x\\ 0&s_y&t_y\\ 0&0&1\\ \end{pmatrix} </math> sowie

<math>

S\circ T = S\cdot T = \begin{pmatrix}s_x&0&s_x\!\cdot\! t_x\\ 0&s_y&s_y\!\cdot\! t_y\\ 0&0&1\\ \end{pmatrix} </math> die letzte Darstellung kann in SVG z. B. codiert werden als

„scale(sx sy) translate(tx ty)“

oder als

„matrix(sx 0 0 sy sx·tx sy·ty)“

Animation

SVG hat Elemente, mit denen Animation interaktiv und deklarativ bewerkstelligt werden kann, das heißt ohne Skripte rein durch Angaben in der XML-Auszeichnungsprache. SVG übernimmt dabei von SMIL Elemente und die Interpretation derselben in den eigenen Namensraum.

Durch die von SMIL übernommenen Elemente können deklarative Animationen realisiert werden. In den Empfehlungen ist im Detail beschrieben, welche Merkmale animierbar sind und in welcher Weise. Animierbar sind die meisten Attribute und Eigenschaften, zusätzlich gibt es die Möglichkeit, die Position von Gruppierungselementen oder darstellbaren Elementen zu animieren.

Zeitangaben können von Millisekunden bis Stunden angegeben und verschieden ausgezeichnet werden. Für die meisten Animationselemente wird ein Pflichtattribut benötigt, das die Art der Animation festlegt. Weitere grundlegende Komponenten sind Zeitangaben, Zustände während der Animation (optional), der Zustand nach der Animation, und ob die Animation nach Beendigung wiederholt werden soll, ob der Animationseffekt dann kumulativ ist und ob er additiv hinsichtlich anderer Animationen mit niedrigerer Priorität und der notierten Attributwerte sein soll. Für die Zeitangabe werden logische Begriffe wie begin (englisch: Start, Beginn) end (englisch: Ende) und dur (englisch „duration“: Dauer) verwendet. Start, Wiederholungen etc. können auch von Ereignissen wie Mausberührung oder -klick abhängig gemacht werden.

Die Auswahl des animierten Attributes oder der animierten Eigenschaft wird in SVG durch zwei Attribute festgelegt: attributeName gibt den Namen des zu animierenden Attributes oder der zu animierenden Eigenschaft an, attributeType gibt an, ob ein Attribut animiert wird oder eine (CSS-)Eigenschaft. Im illustrierten Beispiel wird angedeutet, dass die Füllung (fill-Attribut) eines Rechtecks sowie dessen Transformation (transform-Attribut) über die Dauer von fünf Sekunden animiert wird. Die Illustration selbst enthält keine Animation. Zu Beginn ist das Rechteck blau gefüllt und nicht verdreht, nach fünf Sekunden ist es grün gefüllt, etwas versetzt und um 150° verdreht. Die Zwischenzustände können je nach den angegebenen Attributen diskret geändert werden, sich gleichmäßig, aber auch ungleichmäßig ändern, im Beispiel schematisch durch vier Zwischenschritte dargestellt.

Grafische Effekte und Filter

Bekannte Grafikfilter sind aus Desktop-Publishing-Programmen übernommen worden und arbeiten nach dem Matrizen-Prinzip, bei dem Operatoren und Funktionen die Form der Matrix ausdrücken. Es wird jede einzelne Bildposition mit dem definierten Filtereffekt berechnet und auf die nächste übertragen. Auf diese Weise lassen sich Bilder und Grafiken auf verschiedenste Art und Weise bearbeiten.

Programmierung

SVG stellt mit Ausnahme des Profils Tiny 1.1 einen Zugriff auf das XML-Dokument-Objekt-Modell (DOM) bereit und zusätzlich auch eine eigene Erweiterung dieses DOMs. Damit wird es möglich, die Präsentation eines SVG-Dokumentes zu manipulieren. Dies wird meistens mit Skriptsprachen wie ECMAScript/JavaScript genutzt, um während der Präsentation diese dynamisch zu ändern, um Betrachtern einen interaktiven alternativen Zugang zum Inhalt zu ermöglichen. Die DOM-Repräsentation kann allerdings auch vor der Betrachtung manipuliert werden, wonach dann wirklich ein inhaltlich geändertes Dokument abgespeichert werden kann.

SVG selbst fordert allerdings nicht, dass eine bestimmte Skriptsprache interpretiert werden muss. Auch von daher haben solche Skripte formal nicht die Möglichkeit, wirklich den Inhalt oder die Bedeutung eines Dokumentes während der Betrachtung zu ändern. Hinsichtlich Zugänglichkeit und Barrierefreiheit ist dies immer von Autoren zu bedenken, die Skripte in Dokumenten verwenden möchten.

Über das DOM können zum Beispiel neue Objekte erzeugt werden, die Elementen und ihren Eigenschaften entsprechen. Die DOM-Repräsentation eines Dokumentes kann so auf Benutzereingaben wie Mausklicks und -bewegungen reagieren oder auch vollständig algorithmisch generiert werden. Das lässt sich etwa in Web-Anwendungen nutzen (vergleiche den Grafikeditor SVG-edit,<ref>Webseite von SVG-edit</ref> Diagramme in Google Docs<ref>Introduction to Using Chart Tools auf Google Developers</ref> oder Kartenanwendungen<ref>Mappetizer</ref>).

Zur Manipulation von SVG definiert der SVG-Standard das SVG-DOM.<ref>Spezifikationen des SVG Document Object Models in Version 1.1 und des SVG Micro DOM in Version 1.2</ref> Es erweitert das für alle XML-Arten gleiche Standard-DOM durch SVG-spezifische Datentypen und Funktionen, etwa für grafische Transformationen (Affine Abbildungen). Diese Schnittstelle ist für verschiedene Programmiersprachen standardisiert (für die standardisierte JavaScript-Teilmenge ECMAScript, Java, Perl und Python<ref>Inhaltsverzeichnis der SVG Tiny 1.2 Spezifikationen</ref>). In vielen gängigen Darstellungsprogrammen wird JavaScript zur DOM-Manipulation verwendet.

Beispiel

Das folgende Beispiel illustriert die Verwendung eines SVG-Dokuments zur Anzeige einer einfachen Vektorgrafik. Es zeigt das Grundgerüst eines SVG-Dokumentes sowie die Verwendung der grafischen Primitive line, rect und polygon. Das Polygon, das zur Darstellung der Pfeilspitze verwendet wird, wird außerdem mit Hilfe einer Transformation um 135° um die Spitze gedreht.

Die rechts dargestellte Grafik Variable Resistor.svg (Schaltbild eines Potentiometers) ist mit dem folgenden, kommentierten Quelltext erzeugt:

<syntaxhighlight lang="xml"> <?xml version="1.0" encoding="UTF-8"?> <svg xmlns="http://www.w3.org/2000/svg" version="1.1" baseProfile="full" width="700px" height="400px" viewBox="0 0 700 400">

<line x1="0" y1="200" x2="700" y2="200" stroke="black" stroke-width="20px"/> <rect x="100" y="100" width="500" height="200" fill="white" stroke="black" stroke-width="20px"/> <line x1="180" y1="370" x2="500" y2="50" stroke="black" stroke-width="15px"/> <polygon points="585 0 525 25 585 50" transform="rotate(135 525 25)"/> </svg> </syntaxhighlight>

Profile

In SVG gibt es drei Profile, die für die Darstellung auf unterschiedlichen Ausgabegeräten abgestimmt sind und jeweils unterschiedlich umfangreich den SVG-Standard definieren. Sie werden im Wurzelelement (SVG) mit dem Attribut baseProfile angegeben.<ref name="profiles">Mobile SVG Profiles: SVG Tiny and SVG Basic. W3C, abgerufen am 29. August 2009. </ref>

SVGT

(baseProfile="tiny") SVG Tiny 1.1 ist für stark beschränkte Mobile internet devices (MID) und Mobiltelefone gedacht. Es definiert nur eine kleine Untermenge des SVG-Standards. SVG Tiny 1.2 ist für deutlich leistungsfähigere mobile Geräte gedacht und geht in seinen Merkmalen teils sogar über SVG Full 1.1 hinaus, klammert einige andere Teile von Version 1.1 aber auch aus.

SVGB

(baseProfile="basic", englisch „einfach, grundlegend“) ist für etwas leistungsfähigere MIDs gedacht, definiert aber nicht den gesamten SVG-Standard.

SVGF

(baseProfile="full", englisch „voll, vollständig“) ist für Computer als Ausgabegerät gedacht und umfasst SVG voll.

Durch die Benutzung von Profilen wird auch leistungsschwachen Geräten ermöglicht, mit standardkonformen SVG-Dateien zu arbeiten. Autoren sollten sich also bemühen, dass die zentralen Inhalte mit dem eingeschränkten Funktionsumfang sinnvoll präsentiert werden, die verwendeten zusätzlichen Möglichkeiten des vollen Profiles also nicht essentiell für das Verständnis des Inhalts sind. Darstellungsprogramme können solche Angaben natürlich auch nutzen, um den Nutzer zu warnen, dass das Programm eventuell nicht alle Inhalte korrekt anzeigen kann, wenn eine Version oder ein Profil verwendet wird, das im Programm gar nicht implementiert ist.

Verbreitung

Desktop

Einige Desktop-Umgebungen benutzen SVG als Format für Programmsymbole, Hintergrundbilder oder Mauszeiger. Der zusätzliche Ressourcenverbrauch zum Rendern wird dabei durch steigende Hardwareressourcen kompensiert, so etwa von Grafikkarten direkt übernommen. Beispielhafte Projekte sind das Oxygen Project<ref>siehe auch: Oxygen Project in der englischsprachigen Wikipedia; Homepage der Entwickler</ref> für KDE und das Tango Desktop Project<ref>siehe auch: Tango-Desktop-Project in der englischsprachigen Wikipedia; offizielle Homepage</ref> für GNOME.

Editoren

Programme, mit denen SVG-Dateien erstellt und bearbeitet werden können, sind u. a.:

• Adobe Illustrator (proprietär; Windows, Mac OS)
• CorelDRAW (proprietär; Windows)
• Inkscape – Grafik- und Zeichenprogramm (freie Software; Linux/Unix, Windows, Mac OS X; verwendet SVG als natives Dateiformat (mit Inkscape-Erweiterungen))
• Apache OpenOffice – Nativer Import und Export mit Einschränkungen (freies Office-Paket)
• LibreOffice – Nativer Import und Export mit Einschränkungen (freies Office-Paket)
• PhotoLine (proprietär; Windows, Mac OS)
• Scribus (freie Software; Unix, Linux, Mac OS X, OS/2, Windows)
• Xara Designer Pro – Grafik- und Zeichenprogramm (proprietär für Windows)
• SVG-edit<ref>SVG-edit</ref> – Online-Grafikeditor (freie Software; browserbasierend – verwendet SVG, das Browser-DOM und Javascript zum Editieren)
• Microsoft Visio (proprietär; Windows)

Von Editoren erzeugte SVG-Dateien sind oft größer und komplexer als manuell erzeugte Dateien. Grundformen wie Rechtecke und Kreise sind manuell einfach zu definieren, während Editoren oft aufwendigere Pfad-Elemente verwenden.

SVG-Interpretation in Darstellungsprogrammen

SVG wurde in erster Linie für das World Wide Web entworfen. Moderne Darstellungsprogramme (unter anderem sogenannte Webbrowser) können große Teile davon korrekt darstellen, d. h., sie benötigen kein SVG-Zusatzprogramm (Browser-Plug-in). Verschiedenen Quellen zufolge wird SVG bei ca. 80 % der Internet-Nutzer mindestens rudimentär interpretiert. Wie die folgende Tabelle zeigt, hängt jedoch der tatsächlich verfügbare Funktionsumfang stark vom Darstellungsprogramm ab. Leider ist auch nicht von bloßen Verbesserungen bei neuen Versionen desselben Darstellungsprogrammes auszugehen, meist gibt es eine Kombination von Verbesserungen und Rückschritten.

Beispielsweise sind für den Internet Explorer der oben erwähnte Unschärfefilter erst ab der Version 10 und Animationen überhaupt nicht verfügbar. Bei einigen Programmen werden ferner auch SVG-Schriftarten komplett ignoriert.

Zu bedenken ist bei der Tabelle zudem auch, dass die dafür verwendeten Tests jene aus der offiziellen Test-Suite zur SVG-Empfehlung sind, die nicht dazu dient, den Funktionsumfang von Darstellungsprogrammen zu testen, sondern umgekehrt, ob Merkmale der Empfehlung implementiert wurden und implementierbar sind. Die Tests sind also nicht unabhängig von den Autoren der Empfehlung entstanden und einige der Autoren der Tests sind gleichzeitig Mitarbeiter der Unternehmen, die die Darstellungsprogramme entwickeln und anbieten. Es handelt sich also nicht um einen systematischen und unabhängigen Test der Fähigkeiten der Programme. Es ist also nicht notwendig ein guter Anhaltspunkt dafür, wie wahrscheinlich es ist, dass ein „normales“ SVG-Dokument korrekt präsentiert wird, weil „normale“ Dokumente meist viele Merkmale verwenden, Tests zu SVG-Spezifikationen aber beinahe nur die jeweils mit dem Dokument getesteten Merkmale. Die Gewichtung und Verwendung richtet sich dabei zudem eher nach der Komplexität der Merkmale und der Implementierung, nicht nach der typischen Verwendung in „normalen“ Dokumenten durch Autoren.

Bei anderen Ansätzen wird eher die Frage gestellt, ob bestimmte Merkmale für Autoren wirklich praktisch nutzbar sind.<ref>Compatibility table for support of SVG in desktop and mobile browsers. Abgerufen am 20. Januar 2013. </ref> Auch hier empfiehlt es sich ähnlich wie bei der offiziellen Test-Suite natürlich, die einzelnen Testbeispiele im Detail durchzugehen und zu schauen, in welcher Tiefe und in welcher Kombination mit anderen Merkmalen überhaupt getestet wurde und wie unabhängig die Autoren der Tests von denen der Empfehlung und den Anbietern der Darstellungsprogramme sind, um zu einer zuverlässigen Aussage hinsichtlich der Nutzbarkeit für Autoren und Betrachter zu kommen.

Zum Beispiel bietet die Firma Savarese Software Research eine Erweiterung für den Internet Explorer in Version 6 bis 8 an.<ref>Savarese Plugin</ref> Bekannt seit den Anfängen von SVG, aber nicht mehr weiterentwickelt, ist auch eine entsprechende Erweiterung der Firma Adobe, das in den Anfangsjahren von SVG praktisch das dominierende Programm zur Präsentation von SVG war.

Einige JavaScript-Bibliotheken (z. B. dojo.gfx, Raphaël, SVG Web) bieten die Möglichkeit, Bildelemente in JS-Syntax zu beschreiben. Falls SVG nicht interpretiert wird, kann über diesen Umweg dann automatisch ein vom Darstellungsprogramm interpretiertes Dokument-Objekt generiert werden (z. B. VML oder Flash), ansonsten wird direkt eine SVG generiert. All das kann jedoch bedeuten, dass nicht alle von SVG gebotenen Möglichkeiten genutzt werden können. Es muss also nicht alles von einer Sprache in eine andere transformierbar sein oder von der verwendeten Bibliothek transformiert werden können, zusätzlich zu dem Problem, dass eine Interpretation der verwendeten Skriptsprache auch nicht notwendig komplett oder überhaupt verfügbar sein muss. Die Methode bietet sich also eher als vom Betrachter jeweils aktiv auswählbare Alternative an, nicht als Pauschallösung.

Mit Acid3 liegt ein Test vor, der Darstellungsprogramme in gewissem Rahmen darauf prüft, ob sie SVGs korrekt darstellen können.

Interpretation durch Suchmaschinen

Seit September 2010 berücksichtigt Google SVG bei der Bildersuche.<ref>@-web Suchmaschinen Blog, 2. September 2010</ref> Damit ist SVG neben JPEG, GIF, PNG, Bitmap und WebP eines von sechs Grafikformaten, die Google berücksichtigt.<ref>@-web Suchmaschinen Blog, 14. Mai 2012</ref> Auch Bing berücksichtigt mittlerweile SVG.

Auch für Suchmaschinen sind Textalternativen und von Programmen analysierbare strukturierte Metainformationen von besonderer Bedeutung, um Auskunft über den Inhalt einer Grafik geben zu können. Die Möglichkeiten von SVG als XML-Format sind denen der genannten Rastergrafikformate gleichwertig oder überlegen und von Autoren zudem ohne spezielle Programme einfach zu ergänzen.

The Graphical Web

Seit 2002 findet einmal jährlich die Konferenz The Graphical Web statt, bei der in Vorträgen und Workshops aktuelle Entwicklungen im Umfeld von SVG vorgestellt werden. Bis 2011 hieß diese Konferenz SVG Open.

• Pittsburgh, USA, 23. bis 26. September 2015<ref>Homepage The Graphical Web 2015</ref>
• Winchester, Großbritannien, 26. bis 30. August 2014<ref>Homepage The Graphical Web 2014</ref>
• San Francisco, USA, 21. bis 23. Oktober 2013<ref>Homepage The Graphical Web 2013</ref>
• Zürich, Schweiz, 11. bis 14. September 2012<ref>Homepage The Graphical Web 2012</ref>
• Cambridge, USA, 17. Oktober bis 20. Oktober 2011<ref>Homepage SVG Open 2011</ref>
• Paris, Frankreich, 30. August bis 1. September 2010<ref>Homepage SVG Open 2010</ref>
• Mountain View, USA, 2. bis 4. Oktober 2009<ref>Homepage SVG Open 2009</ref>
• Nürnberg, Deutschland, 26. bis 28. August 2008<ref>Homepage SVG Open 2008</ref>
• Minato, Tokio, Japan, 4. bis 7. September 2007
• Victoria, Kanada, 16. bis 19. Oktober 2006 (ausgefallen)
• Enschede, Niederlande, 15. bis 18. August 2005
• Tokio, Japan, 7. bis 10. September 2004
• Vancouver, Kanada, 13. bis 18. Juli 2003
• Zürich, Schweiz, 15. bis 17. Juli 2002

Siehe auch

• Grafiksoftware
• Grafikformat
• Dateikonverter

Literatur

•  Alexander Adam: SVG, Scalable Vector Graphics. Franzis Verlag, 2002, ISBN 978-3-7723-6190-6.
•  Francis Hemsher: SVG Companion. 2011 (englisch, Barnes & Noble E-Book).
•  Marcel Salathé: SVG – Scalable Vector Graphics … für professionelle Einsteiger. Markt+Technik, München 2001, ISBN 978-3-8272-6188-5.
•  Helma Spona: SVG – Webgrafiken mit XML. vmi-Buch, 2001, ISBN 978-3-8266-7181-4 (online bei data2type).

Weblinks

• Scalable Vector Graphics (SVG) Specification beim World Wide Web Consortium (englisch)
• Scalable Vector Graphics Tiny (SVGT) Specification beim World Wide Web Consortium (englisch)
• Tutorial zum Thema SVG mit Beispieldateien
• Übersicht der SVG-Unterstützung in verbreiteten Browsern (englisch)
• Linkkatalog zum Thema SVG bei DMOZ

Einzelnachweise

<references />