Dr. O. Hoffmann
Bilder, die man aufhängt umgekehrt,
mit dem Kopf nach unten, Fuß nach oben,
ändern oft verwunderlich den Wert,
weil ins Reich der Phantasie erhoben.
Christian Morgenstern
Ohne hier SVG komplett und systematisch vorzustellen, wollen wir doch mal ein paar
Grundformen angucken.
Diese Abschnitte dienen mehr der Ergänzung der teilweise etwas knappen
Spezifikation oder auch anderer Anleitungen zu SVG. Spezifikationen sind auch nicht
dazu gedacht, für alles und jedes Beispiele zu geben, die sollen knapp sein, daher
ist es sinnvoll, sie mit Beispielen zu ergänzen. Da es sich hier nur um
Ergänzungen handelt, bietet es sich an, auf Dinge intensiver einzugehen, für die
in einer einfachen Anleitung wohl nicht so viel Platz wäre, die aber vielleicht
gerade besonders spannend sind, weil sie immer zu kurz wegkommen oder ohne Hilfe
von Skriptsprachen wie PHP oder gar Programmen kaum zu handhaben sind.
Dennoch sollte man mit der hiesigen Schilderung bereits recht weit kommen - komplette Listen von
möglichen Werten für Attribute sollten natürlich in der Spezifikation nachgelesen werden.
Der Leser ist ausdrücklich
eingeladen, die Beispiele auf dem eigenen Rechner zu speichern und mit verschiedenen
Parametern herumzuspielen, um zu sehen, was wie genau funktioniert. Wenn sich interessante
weitere Themenschwerpunkte ergeben, kann ich ja auch per email angeschrieben werden -
vielleicht erstelle ich dazu dann eine weitere Seite mit hoffentlich nützlichen Ideen.
Beginnen wir zunächst mit einem Grundgerüst einer SVG-Datei
und einer weiteren Variante, wie dies mit PHP
aussehen könnte.
Eine SVG-Datei beginnt mit einer XML-Verarbeitungsanweisung
gefolgt von einer doctype-Angabe (siehe Beispiele, entfällt in der Regel bei der Version 1.2).
Weitere SVG-Elemente stehen in einem Grundelement namens svg
,
welches somit eine ähnliche Funktion hat wie das html
-Element in XHTML.
Titel und Beschreibung sollten angegeben werden, dafür gibt es die Elemente title
und desc
.
Die Beschreibung sollte kurz in Worte fassen, was auf dem Bild oder in der Animation zu sehen ist, damit auch solche Nutzer schnell informiert sind, die das Format nicht ansehen können.
Es hat sich auch bewährt, eine viewBox
zu
nutzen, dann kann die Größe des Bildes sehr einfach nachträglich über die
Angaben von Höhe und Breite im svg
-Element an andere Bedürfnisse
angepaßt werden. Das erspart dem Autor auch weitere Einheiten-Dramen innerhalb des
Bildes, etwa kommen für SVG tiny andere
Längeneinheiten als px (muß dann nicht angegeben werden) nur für die
Attribute width
und height
des
svg
-Elementes in Betracht, da etwa
%, cm, mm für andere Elemente
in der Regel nicht zulässig sind.
Die vier Zahlen des viewBox
-Attributes bezeichnen
x und y des Startpunktes links oben und Höhe und Breite des Anzeigebereiches.
Innerhalb des svg
-Bereiches beziehen sich dann alle Angaben auf die
Koordinaten der viewBox
in Einheiten von 1, wenn nicht
anders angegeben. Nullpunkt ist links oben, die y-Achse zeigt
nach unten, die x-Achse nach rechts, wenn nichts anderes angeben ist.
Es handelt sich um ein links-System, wie es
für Computergraphik nicht unüblich ist.
Es gibt allerdings viele Menschen, die lieber den Ursprung links unten haben
und die y-Achse nach oben zeigen lassen wollen.
Zwar ist dies einfach möglich, indem man per Transformation (siehe späteres Kapitel)
eine Spiegelung an der x-Achse vornimmt, was dann allerdings bei möglichen Textinhalten
zur Folge hat, daß diese spiegelverkehrt dargestellt werden - also wieder einzeln
zurücktransformiert werden müßten. Eine einfachere Variante besteht darin,
alle zu notierenden y-Werte mit -1 zu multiplizieren, bevor man sie in die Datei
einträgt und die viewBox
eben mit einem passend gewählten negativen
y-Wert beginnen zu lassen.
Folgendes Beispiel zeigt eine leere SVG-Datei in der Version 1.1, welche
derzeit (2009) neben der neuen Version SVG Tiny 1.2 aktuell ist. Letztere ist
für mobile Geräte optimiert, enthält aber bereits zahlreiche Neuerungen.
Andere Bereiche von SVG, die für mobile Geräte als nicht
erforderlich angesehen werden oder für leistungsschwächere Prozessoren eher nicht
in Frage kommen, sind in SVG Tiny 1.2 allerdings nicht enthalten, so daß
man genau gucken muß, was man wirklich braucht. Ältere Versionen als 1.1 sollte man
nicht mehr verwenden.
Bei SVG 1.2 gibt es keine DTD
mehr, daher in der Regel auch keine Dokumenttypdeklaration. In zukünftigen Formaten werden generell andere
Mechanismen zur Spezifikation des Dokumenttyps verwendet werden. Die Deklaration findet aber nach wie
vor Verwendung, wenn der Autor Abkürzungen oder Entitäten definieren will.
<?xml version="1.0" encoding="iso-8859-1" ?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="200px" height="200px" viewBox="0 0 200 200" xmlns="http://www.w3.org/2000/svg" version="1.1" xml:lang="de"> <title>Grundform: Leer</title> <desc>SVG-Beispiel eines Grundgerüstes</desc> <!-- Ein Kommentar, Syntax wie bei XHTML und anderen XMLs. Zur Beschreibung von Inhalten ist es aber meist besser, das Element desc in das zu beschreibende Element einzubetten, denn dafür ist das Element desc da. --> </svg>
xml:lang
ist ein XML-Universalattribut zur Kennzeichnung der
verwendeten Sprache, kann nahezu bei jedem Element gesetzt werden und gilt dann auch für alle Kindelemente.
Ohne Angabe des Attributes baseProfile
s gilt das normale
SVG gemäß
der Versionsangabe, mit baseProfile
="tiny"
oder "basic" im SVG-Element gilt dann der jeweilige
Teilbereich von SVG:
leere SVG-Datei,
leere SVG-tiny-Datei,
leere SVG-basic-Datei
Das Dokument kann bei tiny und basic den allgemeinen Dokumenttyp enthalten, wie angegeben,
wird jedoch direkt auf diese Profile abgezielt, sollte auch der speziellere Dokumenttyp verwendet
werden. Für die Zukunft sind jedenfalls die Attribute relevant, da es dann keinen Dokumenttyp mehr geben wird.
leere SVG-tiny-Datei,
leere SVG-basic-Datei.
Ein Beispiel für eine leere Datei in der Version 1.2 mit baseProfile
="tiny".
Eine neue Eigenschaft viewport-fill
ist ebenfalls angegeben, die dazu dient,
den Anzeigebereich mit einer Farbe zu füllen:
leere SVG-Tiny-1.2-Datei.
Leider habe ich in letzter Zeit jede Menge defekte SVG-Dateien bei meinen
Streifzügen durch das Netz entdecken müssen. Sei es, daß der ganze Dateikopf
fehlte oder aber der server nicht den richtigen
MIME-Typ
gesendet hat, die Dateien mit fehlerhaftem (X)HTML
in eine Seite integriert waren oder sonst ein Fehler vorlag, das Ergebnis war immer
das gleiche, die Datei konnte nicht angezeigt werden. Der komplette Dateikopf, der
richtige MIME-Typ und fehlerfreies Arbeiten sind keine Spielerei. SVG
ist ein XML-Format.
Ein korrekt arbeitendes Darstellungsprogramm wird die Datei nicht anzeigen, wenn sie
fehlerhaft ist. Gegebenenfalls muß eben der server richtig konfiguriert werden
oder die Dateien müssen komplett mit PHP abgeboten werden,
wo der Autor
selbst bestimmen kann, welcher MIME-Typ gesendet wird, wie wir im nächsten
Beispiel sehen können.
Alle Seiten mit defekten SVG-Dateien haben explizit das
Adobe-plugin empfohlen, woraus
geschlossen werden kann, daß dieses ungeeignet ist zur ausschließlichen
Kontrolle bei der Entwicklung von SVG-Dateien, da es grobe Fehler zu übersehen
scheint. Teils scheint die Ursache auch darin zu liegen, daß viele Autoren das plugin im microsoft
internet explorer verwendet haben, der Angaben zum MIME-Typ fehlerhaft interpretiert hat und so
Dateien an das plugin weitergeleitet hat, die nicht den passenden MIME-Typ aufwiesen.
Da ist dringend eine Alternative erforderlich, etwa Opera 9.
Zu empfehlen ist auch ein durchgehender Test mit dem W3C-Validator.
Das ist für SVG der gleiche wie für (X)HTML - die Adresse ist
unter dem Menüpunkt Verweise zu finden. Der Nutzen des W3C-Validators
ist bei SVG allerdings deutlich beschränkt. Die komplexe Syntax von zahlreichen
Attributen wird gar nicht geprüft, Namensräume sind festgelegt, SVG Tiny 1.2
kann nicht getestet werden, beziehungsweise der Validator interpretiert die Versionsangaben falsch und
liefert daraufhin falsche Fehlermeldungen bei neuen Bestandteilen von SVG Tiny 1.2.
Damit SVG-Dateien im internet immer richtig angezeigt werden, muß der
server den richtigen
MIME-Typ
oder Content-Typ senden. Um das tun zu können,
sollte die Dateiendung .svg sein oder bei gzipten Dateien
.svgz, entsprechend soll der server im Verzeichnis der
MIME-Typen folgende Zuordnung haben:
image/svg+xml svg svgz
Sofern SVG, welches mit PHP
erzeugt wird, keine besondere Endung zugeordnet ist,
muß die Zuordnung des MIME-Typs
der Autor mittels der
header
-Funktion vornehmen, zum Beispiel ein
SVG-header einschließlich
charset:
header("Content-type: image/svg+xml; charset=iso-8859-1");
oder wie im folgenden Beispiel ohne charset,
dann gilt gegebenenfalls der vom server gesendete charset
oder wenn das nicht erfolgt UTF-8. SVG kennt keine Maskierung von
Sonderzeichen (es sei denn, der Autor definiert sie selbst), deshalb ist es wichtig, bei Verwendung von
Sonderzeichen wie Umlauten und dem ß den charset anzugeben
und zu senden, mit dem die Datei abgespeichert wurde.
Statische Dateien sind entsprechend abzuspeichern,
dynamisch erzeugte dürfen nur passende Zeichen enthalten.
Für einige Darstellungsprogramme ist es vorteilhaft, beim komprimierten svgz folgenden
header
an den ersten anzuhängen:
header("Content-encoding: gzip");
Sollte der server falsch konfiguriert sein und die server-Konfiguration nicht zugänglich sein,
aber ein Apache mit dem htaccess-Modul verwendet werden, so kann man in die Datei .htaccess
folgendes schreiben:
AddType image/svg+xml .svg
AddType image/svg+xml .svgz
AddEncoding gzip .svgz
Die Datei .htaccess wird dann entweder ins Hauptverzeichnis kopiert oder in jenes
Verzeichnis, in dem anzuzeigende SVGs liegen. Diese Zeilen entsprechen übrigens
auch denen, die man in einer Konfigurationsdatei notieren kann, die Angabe des
MIME-Typs erfolgt allerdings eigentlich in einer
gesonderten Datei, meist /etc/apache/mime.types oder /etc/mime.types, wo
genau kann unter dem Stichwort ' TypesConfig' in der Konfigurationsdatei
nachgelesen werden.
Folgendes ist eine leere SVG-PHP-Datei mit Eingabemöglichkeiten für Breite, Höhe, Maßeinheit und einem freien Parameter:
<?php # SVG mit PHP # horizontale Bildbreite if(isset($_GET['x'])) { $horizontal=$_GET['x']; settype ($horizontal, 'integer'); if ($horizontal <= 0) { $horizontal=400; } } else { $horizontal=400; } # vertikale Bildbreite if(isset($_GET['y'])) { $vertikal=$_GET['y']; settype ($vertikal, 'integer'); if ($vertikal <= 0) { $vertikal=400; } } else { $vertikal=400; } # Maßeinheit fuer x und y if(isset($_GET['m'])) { $masseinheit=$_GET['m']; if (!(($masseinheit =="%") OR ($masseinheit =="cm") OR ($masseinheit =="mm")) ){ $masseinheit ="px"; } } else { $masseinheit="px"; } # freier Parameter if(isset($_GET['n'])) { $n=$_GET['n']; } else { $n=5; } # SVG-header senden: $content="Content-type: image/svg+xml"; header($content); # XML-Verarbeitungsanweisung senden, # vorsichtshalber mit echo ausgeben, # falls auf dem server 'php-short-tags' aktiviert sind - # was meist bei XML zu Problemen führt. echo "<?xml version=\"1.0\" encoding=\"iso-8859-1\" ?> \n"; # # Beim Element svg kann man die Breite und Höhe # angeben - hier per PHP als GET-Parameter einzugeben # viewBox bezieht sich darauf, welche Koordinaten # im Weiteren benutzt werden. # xmlns ist der Namensraum. # Das Element desc enthält eine optionale, # hoffentlich hilfreiche Beschreibung. ?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="<?php echo $horizontal.$masseinheit ;?>" height="<?php echo $horizontal.$masseinheit ;?>" viewBox="0 0 1000 1000" preserveAspectRatio="none" xmlns="http://www.w3.org/2000/svg" version="1.1"> <title>SVG-Beispiel: Leer</title> <desc>SVG-Beispiel leer </desc> </svg>
Leere SVG-PHP-Datei
Wenn man schon die Abmessungen von außen vorgeben kann, ist es nützlich,
vorgeben zu können, ob das Verhältnis Seite zu Höhe gleich bleiben soll
oder nicht, dazu dient das Attribut preserveAspectRatio
mit den
zahlreichen Einstellmöglichkeiten, auf die ich hier nicht weiter eingehen werde.
none jedenfalls fordert eine Umskalierung des Bildes, so daß die
viewBox
die Bildabmessungen komplett ausfüllt, gegebenenfalls wird das Bild dazu verzerrt dargestellt.
Wird das Attribut nicht angegeben, werden x und y mit dem gleichen Wert skaliert.
Wenn das nicht anders automatisch erfolgt, kann mit PHP auch die Kompression
durchgeführt werden, um bei der Übertragung Kapazitäten einzusparen:
Leere, komprimierte SVG-PHP-Datei
(Quelltext zur GZIP-komprimierten SVG-Datei).
Ansonsten kann das wohl auch in der php.ini oder per ini_set automatisch
erledigt werden, ebenso wie vom Apachen selbst,
pro server muß da allerdings dann genau einmal eine konsequente Entscheidung bei der Konfiguration getroffen werden,
dann ist es weder notwendig noch korrekt, das in jedem Dokument nochmal einzeln zu machen, sonst hätte man
mehrfach komprimiert, was unsinnig ist.
Ist der Betreuer des servers unwillig oder unfähig, für SVG korrekte
Eintragungen vorzunehmen, so kann der Autor dieses statt seiner für jede
einzelne Datei durchführen. Dazu dient folgendes kleine PHP-Skript:
Beispielaufruf mit einer der folgenden statischen Dateien.
<?php # svg-Datei anzeigen if(isset($_GET['was'])) { # wir wollen nicht, dass in andere Verzeichnisse geguckt wird... $was=str_replace("/", "?",$_GET['was']); } else { $was="leer"; } # Extension, Endung? if(isset($_GET['ext'])) { # wir wollen nicht, dass in andere Verzeichnisse geguckt wird... $ext=str_replace("/", "?",$_GET['ext']); } else { $ext="svg"; } if (($ext != "svg") AND ($ext != "svgz")){ $ext="svg"; } # Dateinamen zusammensetzen und # im aktuellen Verzeichnis lokalisieren $filename="./$was.$ext"; if (file_exists($filename)) { header("Content-type: image/svg+xml; charset=iso-8859-1"); if ($ext == "svgz") { header("Content-encoding: gzip"); } readfile($filename); } else { header("Content-type: text/plain"); echo "Kein Zugriff oder Datei nicht existent!"; } ?>
Zwischen <svg ...>
und </svg>
können nun zum einen direkt dargestellte geometrische Formen
eingefügt werden, zum Beispiel Rechteck, Kreis, Ellipse, Linie, eine beliebige Kurve.
Daneben gibt es zum anderen weitere
Informationen, die der Autor angeben kann oder sogar sollte - Alternativtext, zusätzliche
Metainformationen und einen Vorrat von Objekten, die später benutzt werden können.
Das sind allesamt Informationen, die nicht unmittelbar, also zumindest ohne weitere Aktion durch
den Betrachter oder den Autor angezeigt werden.
Am wichtigsten sind vermutlich die bereits genannten Elemente title
und desc
, diese können nicht
nur im svg
-Element direkt stehen, sondern in jedem Graphikelement und in jedem
Containerelement, die später unter dem Stichwort Gruppierungen etwas genauer
erläutert werden. desc
enthält eine Beschreibung der Funktion des
Graphikelementes oder der umschlossenen Gruppe, title
gibt dem Element oder
der Gruppe einen Titel. Nützlich ist das besonders, wenn ein Darstellungsprogramm
zwar XML versteht, aber keine Graphik anzeigen kann - der Nutzer erhält immer
noch sinnvolle Beschreibungen. So bekommen etwa auch sehbehinderte oder blinde
Nutzer oder Nutzer von Text-Darstellungsprogrammen, sogar Suchmaschinen Zugang zum graphischen
Inhalt des Dokumentes.
Zwar ist die Interpretation der beiden Elemente bei den meisten
Darstellungsprogrammen noch mangelhaft, es bleibt aber zu hoffen, daß dies alsbald zum
Nutzen des Nutzers besser wird. Opera 9 etwa stellt das title
-Element genau wie das
title
-Attribut in XHTML dar. Batik/Squiggle tut das
für title
und desc
, sofern die nicht zum
Haupt-svg
-Element gehören.
Bei Opera 9 gibt es aber auch beim title
-Element noch Lücken, etwa wenn eine Gruppe
ein solches Element hat, die Elemente der Gruppe aber auch, so wird das title
-Element der
Gruppe nie angezeigt, sonst ist es nicht unterscheidbar von dem eines Einzelelementes.
Opera 9 zeigt auch weder title
noch desc
an, wenn Graphik
ausgeschaltet wird, ermöglicht also keinen Zugang zur Textalternative.
Während Opera sich bei XHTML bezüglich der
Zugänglichkeit von Dokumenten viel Mühe gibt, ist da bei SVG
noch einige Arbeit zu leisten. Amaya 9 und Konqueror+KSVG zeigen da
mit alternativen Textansichten ein deutlich besseres Verhalten, obgleich die Textinformation
auch bei diesen noch ordentlich strukturiert sein könnte.
Zu bedenken ist bei title
und desc
, daß es sich dabei
eben um Textalternativen handelt, die alternativ zur graphischen Darstellung eine Textrepräsentation
ermöglichen. Das title
-Attribut in XHTML
hingegen dient dazu, ergänzende Informationen anzubieten, besonders zu interaktiven Elementen
wie Verweisen. Insofern ist die Funktionalität eine komplett andere. Der Inhalt der Elemente
ergibt einen Sinn, gerade wenn oder jedenfalls auch wenn der graphische Inhalt nicht dargestellt wird.
Ein weiteres Element, welches weitere Informationen zum Inhalt aufnehmen kann, ist das Element
metadata
, welches überall auftreten kann, wo auch title
und desc
auftreten können. Wie der Elementname schon andeutet, dient es
allgemein dazu, Metainformation über den jeweiligen Inhalt bereitzustellen. Es wird oft dazu
verwendet, Informationen zum Autor und zu Lizenzbedingungen in einer anderen, automatisch
analysierbaren Form in einer anderen Beschreibungssprache wie
RDF anzubieten.
Beispiele dazu aus anderen Bereichen dieses Projektes:
Kaktus und Maus,
Frosch-Haiku (in zwei Sprachen
verfügbar: de, en).
Oft tritt hinter title
, desc
und metadata
des Elementes
svg
ein weiteres Element auf, dessen Inhalt nicht direkt dargestellt wird, das ist das Element
defs
- das dient dazu, Inhalte aufzunehmen, die meist später verwendet oder
referenziert werden, also gewissermaßen ein Vorratsbehälter für Objekte, die man
später noch brauchen wird.
Ein einfaches Beispiel für SVG tiny 1.1 mit dem Element metadata
:
Metainformationen in SVG.
Ein Beispiel für SVG tiny 1.1 mit dem Element metadata
mit
RDF und Dublin Core und XHTML innerhalb von desc
:
Metainformationen aus anderen Namensräumen
in SVG.
SVG tiny 1.2 bietet einige weitere neue Attribute, um Metainformationen bei jedem
Element angeben zu können. Dies ist wichtig, weil SVG besonders für
Elemente mit Textinhalt kaum etwas zur Kennzeichnung der semantischen Bedeutung bietet.
Dafür sollen title
und desc
keine Elemente in anderen
Namensräumen mehr enthalten. Das führt dazu, daß insbesondere strukturierte
Beschreibungen innerhalb von metadata
notiert werden müssen.
Der Ansatz für Metainformationen von
Version 1.1 wären Angaben mit RDF im Element metadata
wie
oben im Beispiel angegeben.
In SVG tiny 1.2 gibt es eine einfachere, alternative Methode, die keine Elemente aus
einem anderen Namensraum erfordert. Zum einen gibt es das Attribut role
,
mit dem die inhaltliche Bedeutung eines Elementes angegeben werden kann. Das erfolgt über die
Angabe von vordefinierten oder einer
CURIE einer
Spezifikation der gewünschten Bedeutung, zum Beispiel
role
= "tooltip", um die Funktionalität einer
Nutzerhilfe zu kennzeichnen. Das Attribut beschreibt also, um was es sich handelt, nicht unbedingt,
wie dies technisch erreicht wird (bei so einer Nutzerhilfe ist es gebräuchlich, daß diese sichtbar
wird, wenn man mit einem Zeigergerät wie einer Maus über das jeweilige Element fährt).
Es gibt auch Attribute, die die gesamte Subjekt-Prädikat-Objekt-Struktur von RDF
bereitstellt, diese wurden von RDFa
übernommen.
Beispiel zur Verwendung von Elementen aus anderen Namensräumen und von einigen
Attributen aus RDFa in SVG
tiny 1.2 und dem Element metadata
:
Metainformationen in SVG tiny 1.2.
Beispiel Rechtecke
(Quelltext zu Rechtecken).
Die Attribute x
und y
des
rect
-Elementes geben die Koordinaten des Eckpunktes links oben an,
height
und width
Höhe und Breite.
rx
und ry
stehen jeweils für
die Radien abgerundeter Ecken.
Mit der Eigenschaft fill
wird eine
Form generell mit einer Farbe gefüllt, es sei denn, man gibt
fill
="none" an. Die Eigenschaft
stroke
ist der Malstift oder der Rahmen einer Form, der
hat auch eine Farbe und eine Dicke. Daneben kann mit den beiden Eigenschaften auch noch ein
Maldienst (englisch: paint server) angegeben werden, etwa
ein Farbverlauf oder Muster. Mit der Angabe von inherit wird die Angabe des
Elternelementes verwendet.
Ferner kann das Schlüsselwort currentColor
angegeben werden. Damit wird eine Farbe verwendet, die mit der Eigenschaft
color
festgelegt wurde.
SVG tiny 1.2 bietet dazu einem speziellen Maldienst solidColor
,
mit dem eine Farbe festgelegt und immer wieder referenziert werden soll. Das ist ganz hilfreich,
wenn man verschieden Objekten, die irgendwo in beliebiger Reihenfolge zwischen anderen
Objekten stehen, die gleiche Farbe zuweisen will, man aber mehr als eine Gruppe von solchen
Objekten hat, also currentColor allein nicht ausreicht. In SVG 1.1
ist dazu ein ander Maldienst, ein Farbverlauf oder ein Muster zu referenzieren, was man dann
einfarbig ausfallen lassen kann.
Attribute sind generell spezifisch für das jeweilige Element, während Eigenschaften für praktisch alle Elemente angegeben werden können. Eigenschaften werden entweder wie andere Attribute als sogenannte Präsentationsattribute angegeben oder als CSS-Eigenschaften in der dafür typischen Syntax, die später noch anhand eines Beispiels erläutert werden wird. In SVG tiny (1.1, 1.2) gibt es nur Präsentationsattribute und keine CSS-Eigenschaften.
Wie in dem Beispiel beim Rechteck links unten deutlich zu sehen ist, wird solch ein Rahmen mittig auf die Kante der Form gelegt, denn alle Rechtecke bei dem Beispiel haben gleiche Höhe und Breite.
Die Beispiele rechts
zeigen Beispiele zur Eigenschaft opacity
,
Opazität, Teiltransparenz, diese kann man für die
Gesamtfigur, aber auch für fill
und
stroke
einzeln angeben und ist in SVG tiny 1.1
nicht verfügbar, in tiny 1.2 schon für fill
und
stroke
, für opacity
nur für
andere Bilder. Der Wert liegt
jeweils zwischen 0 und 1 für transparent beziehungsweise
undurchsichtig, Zwischenwerte lassen entsprechend den Hintergrund teilweise durchscheinen.
Bei den Farbangaben gibt es die Möglichkeiten der von (X)HTML und CSS bereits bekannten Notationen.
Was passiert, wenn ein Element übersteht, kann unten rechts beobachtet
werden. Das hängt von den genauen Umständen ab. Man
kann das mit der Eigenschaft overflow
für das
svg
-Element und ein paar andere Elemente beeinflussen (nicht in SVG tiny).
Die Werte entsprechen weitgehend denen bei CSS.
Mittels der Eigenschaften visibility
und
display
kann übrigens erreicht werden, daß Objekte gar nicht
angezeigt werden, analog zu den entsprechenden CSS-Eigenschaften.
Was zudem noch an dem Beispiel zu erkennen ist: Oft sind Graphikelemente leer und werden dann auch so gekennzeichnet. Enthalten sie jedoch andere Elemente oder sonstigen Inhalt, so werden sie danach mit einer Endmarkierung abgeschlossen.
Details zu abgerundeten Ecken und den Regeln, die darauf anzuwenden sind, wenn der Autor problematische Angaben macht, sind folgender Datei anhand von Beispielen zu entnehmen: Rechtecke mit abgerundeten Ecken (Quelltext zu Rechtecke mit abgerundeten Ecken).
Rechtecke mit nicht gesetzten Attributen
(Quelltext zu Rechtecke mit nicht gesetzten Attributen).
In SVG 1.2 sind die Attribute
x
, y
,
height
und width
optional, in SVG 1.1 nur x
und y
.
Sofern nicht angegeben, ist der jeweilige Wert 0.
Negative Werte für height
und width
sind nicht unterstützte Werte und werden ignoriert, als ob das Attribut nicht angegeben wäre.
Ist height
oder width
0, so wird das
Rechteck nicht angezeigt.
Die korrekte Anzeige besteht aus drei magenta Rechtecken mit
schwarzem Rand auf gelbem Hintergrund.
Der Kreis circle
ist eigentlich ein Spezialfall der Ellipse
ellipse
, es also nicht ganz
klar, weswegen dafür ein extra-Element geschaffen wurde. Schade ist
auch, daß die Hauptachsen der Ellipsen immer in x- und y-Richtung
liegen und nur der Mittelpunkt und nicht auch alternativ die Brennpunkte
oder andere Charakterisierungen genutzt werden können.
Die Attribute
cx
und cy
geben also jeweils den Mittelpunkt an, r
beziehungsweise
rx
und ry
geben entprechend die halben Hauptachsenlängen an.
Die Ausrichtung der Ellipse kann allerdings mit dem noch zu besprechenden
Transformationsattribut erfolgen.
Beispiel Ellipse und Kreis (Quelltext zu Ellipse und Kreis).
cx
und cy
müssen nicht gesetzt werden,
in SVG 1.1 die Radien hingegen schon und auch nicht kleiner als null, in SVG 1.2 hingegen
sind auch die Radien optional, negative Radien werden effektiv ignoriert:
Nicht gesetzte oder falsche Attributwerte für Ellipse und Kreis
(Quelltext zu nicht gesetzten oder falschen Attributwerten für Ellipse und Kreis).
Korrekte Darstellung sind vier große gelbe Kreise
mit sich teilweise überdeckendem rosa Rand auf
dunkelgrünem Hintergrund. In jedem Kreis ist
jeweils eine gelborange Ellipse mit rosa Rand.
Rote Kreise oder Ellipsen werden nicht dargestellt.
Da viele Programme derzeit (2009) Probleme mit der korrekten Darstellung haben, wenn unsinnige Radien angegeben werden,
ist es offenbar besser, dies einfach nicht zu tun ;o) Nicht gesetzte cx
und cy
sind allerdings unproblematisch. Das adobe-plugin und die Geckos stellen kompletten
Unsinn dar, Opera machmal gar nichts, in der 9.50-Version nach einiger Zeit oder nach Betrachtung eines anderes Fensters
oder einer anderen Arbeitsfläche dann doch das richtige Ergebnis. Batik/Squiggle gibt eine Fehlermeldung aus und
verzichtet komplett auf die Anzeige. Bis auf die Hintergrundfarbe bekommt KSVG1 es manchmal richtig hin, manchmal
wird auf die Anzeige der gelborangen Ellipsen ebenfalls verzichtet (warum?). Die Fehlermeldung von Batik/Squiggle und
eine Randnotiz von KSVG1 sind allerdings die einzigen Indizien von den Programmen dafür, daß mit den
negativen Radien etwas nicht stimmen könnte.
Eine weitere Grundform sind Linien line
, die Attribute
x1
, y1
bezeichnen den Startpunkt,
x2
, y2
den Endpunkt, alle Attribute
sind optional.
Ansonsten können dem folgenden Beispiel noch einige Feinheiten über
stroke
-Eigenschaften
angegeben werden. Da stroke
auch bei anderen
Figuren auftaucht, sind diese dort
natürlich ebenfalls anwendbar.
Extra für das adobe-plugin mag es sinnvoll sein, fill
für Linien explizit auf none zu setzen.
Beispiel Linien (Quelltext zu Linien).
Mit der Eigenschaft stroke-dasharray
kann ein Linienmuster wie eine gestrichelte Linie
angegeben werden, mit Kommata separiert jeweils die Länge eines gezeichneten Stückes
und eines nicht gezeichneten Stückes. Mittels stroke-dashoffset
kann ein Startwert vorgegeben werden. Das Problem bei den bisherigen Spezifikationen 1.0 und 1.1 ist, daß
das Zusammenspiel mit den noch folgenden stroke
-Eigenschaften und
allgemein die genaue Interpretation nicht spezifiziert ist, was zur Folge hat, daß sich Autoren darauf
einstellen müssen, daß es
bei verschiedenen Darstellungsprogrammen zu unterschiedlichen Anzeigen kommen wird.
stroke-linecap
steht für die Form der
Linienenden - round für rund, wobei der Radius nach außen
hinzugefügt die halbe Liniendicke ist, bei square wird die halbe Liniendicke
an die Enden angefügt, bei butt passiert das nicht, in den beiden letzteren Fällen erhält
man ein eckiges Linienende. Obgleich das mit keinem Wort in den Spezifikationen erwähnt wird - im Gegenteil
eigentlich - werden die entsprechenden Linienenden auch auf die Strichel von
stroke-dasharray
angewandt, was oft zu recht blödsinnigen
Effekten führt. Diese zu vermeiden, verlangt vom Autor dann oft auch größeres Geschick.
Beispiel Linien mit teilweise nicht gesetzten Attributen
(Quelltext zu Linien mit teilweise nicht gesetzten Attributen).
Die Attribute x1
, y1
,
x2
, y2
sind optional.
Sofern nicht anders gesetzt, werden sie als 0 angenommen.
Ist die Länge der Linie 0, so wird im Falle von stroke-linecap
round ein Kreis mit dem Durchmesser von stroke-width
gemalt, im Falle von stroke-linecap
square ein Quadrat
der Seitenlänge von stroke-width
.
Die korrekte Anzeige ist ein blaues Kreuz auf gelbem Grund,
in der Mitte des Kreuzes ist noch ein blauer Kreis, dazu links
oben ein kleiner blauer Kreis und rechts unten ein kleines
blaues Quadrat.
Rot bedeutet eine falsche Anzeige, denn rote Objekte werden
entweder von blauen verdeckt oder nicht angezeigt.
Eine nahezu korrekte Anzeige liefert zum Beispiel Batik/Squiggle bis auf die fehlende Hintergrundfarbe.
Opera bis mindestens Version 9, die Geckos und das adobe-plugin sind falsch hinsichtlich der
punktförmigen Linien, KSVG teilweise falsch.
Als kleine Anwendung von stroke-dasharray
zusammen mit dem Element
circle
sei noch kurz erläutert, wie diese verwendet werden können, um ohne
große Rechnerei Kreisdiagramme zu malen. Bei einem Kreisdiagramm oder Tortendiagramm entspricht
die Fläche eines Kreissegmentes jeweils einem Anteil. Alle Anteile addieren sich zu hundert
Prozent (oder weniger, dann fehlt ein Segment). Die Fläche eines Kreissegmentes ist wiederum
proportional zum aufspannenden Winkel und auch zur Bogenlänge des Segmentes. Dies ermöglicht
ein einfaches Malen solcher Segmente ohne große Rechnerei.
Zu dem Zwecke sollte nur bekannt sein, wie der Zusammenhang zwischen Umfang u und Radius r
bei einem Kreis ist: u = 2 π r
Soll bei einem Kreisdiagramm ein Segment einfach in Prozent angegeben werden, gilt u = 100,
also r
= 50/π ≈ 15.9155.
Damit der Strich den Kreis genau abdeckt, gilt: stroke-width
=
2 r
= 100//π ≈ 31.8310
stroke-dasharray
beginnt bei einem Kreis am äußersten rechten Punkt
im lokalen Koordinatensystem und schreitet nach unten fort (fehlerhaft etwa im adobe-plugin).
Soll das Kreissegment an anderer Stelle beginnen, beginnt
das Muster von stroke-dasharray
mit 0, gefolgt von einer
entsprechend langen Lücke, gefolgt von der Segmentlänge, gefolgt von einem hinreichend großen
Wert, zum Beispiel 100.
Beispiel Tortendiagramm handgemalt (Quelltext zum handgemalten Tortendiagramm).
Um Unsauberkeiten von Darstellungsprogrammen zu verdecken, kann es hilfreich sein, Ränder zu setzen, dazu wird hier ein hinreichend großer Kreis als Hintergrund gesetzt und ein paar Linien als Ränder für die Kreissegmente. Im leichten Vorgriff auf das Kapitel Transformationen werden die Linien hier mit einer Drehung in die richtige Position gebracht. Um den Drehwinkel zu bestimmen, ist der Prozentwert mit 3.6 zu multiplizieren, etwas schwieriger im Kopf zu rechnen, denn leider können Drehungen nicht in Prozent oder Anteilen einer kompletten Drehung angegeben werden.
Beispiel Tortendiagramm mit Rand handgemalt (Quelltext zum handgemalten Tortendiagramm mit Rand).
Anzumerken ist noch, daß einige Unkundige für solche Tortendiagramme auch gerne Ellipsen verwenden, zum Beispiel um einen perspektivischen Eindruck zu erwecken. Allerdings ist bei einer Ellipse die Fläche nicht mehr proportional zum Winkel oder zur Bogenlänge. Außerdem sind Bogenlänge und Fläche eines Ellipsensegmentes nicht mehr einfach zu berechnen. Folglich sollten nur Kreise und keine Ellipsen verwendet werden. Auch nicht flächentreue Transformationen (mit Ausnahme von Skalierungen, wenn diese für jede Richtung gleich sind) führen zu einem falschen Eindruck, was bedeutet, daß die Fläche keinen Rückschluß mehr auf den Anteil zuläßt wie bei der Verwendung von Ellipsen, daher sind solche Darstellungen entweder komplett sinnfrei oder gezielt manipulativ, um einen falschen Eindruck über einen Sachverhalt zu erwecken. Werden einem solche falschen Diagramme vorgesetzt, kann es sich lohnen über die Kompetenz oder die Absichten des Autors nachzudenken.
Ganz ähnlich funktionieren die Linienzüge polyline
,
die Punkte werden mit dem Attribut points
als Liste angegeben.
In SVG 1.1 ist das Attribut erforderlich mit einer positiven geraden Anzahl von Zahlen.
In SVG 1.2 ist es optional, ein nicht angegebenes Attribut, eine ungerade Anzahl von
Zahlen oder ein leeres Attribut führen zu keiner Anzeige.
Ansonsten sind auch hier noch einige Feinheiten über
stroke
-Eigenschaften
angegeben worden:
Beispiel Polylinien oder Linienzug (Quelltext zu Polylinien oder Linienzug).
Beispiel Polylinien oder Linienzug - zu vermeidende Problemfälle
(Quelltext zu Polylinien oder Linienzug - zu vermeidende Problemfälle).
Die korrekte Darstellung ist ein blauer Kreis oben rechts und ein
blaues Quadrat unten (rechts) auf gelbem Grund.
Rot bedeutet eine falsche Anzeige, denn rote Objekte werden
entweder von blauen verdeckt oder nicht angezeigt.
Es ist (mir) kein Darstellungsprogramm bekannt, welches das Beispiel korrekt anzeigen täte.
Einmal abgesehen von den anzuzeigenden Beispielen der Länge 0 sind folglich die problematischen
Notationen zu vermeiden.
Bei Polygonen polygon
wird der Linienzug nur geschlossen, die Punkte werden auch
mit dem Attribut points
als Liste angegeben.
Ansonsten sind auch hier noch einige Feinheiten über
stroke
-Eigenschaften angegeben worden.
Die Eigenschaft stroke-linejoin
gibt an, wie Linien an den
Ecken zusammengefügt werden - round mit einer abgerundeten Ecke, Radius
halbe Liniendicke, bevel mit einer
symmetrisierten Abschlußkante im Abstand von einer halben Liniendicke und miter
für das Verlängern der Außenkanten, bis sie sich treffen. Treffen sie
sich nie oder ist der Winkel sehr klein, kann das zu sehr langen Formen führen,
mittels der Eigenschaft stroke-miterlimit
kann ein
Maximalwert vorgegeben werden. Der Wert ist größer als 1 und
gibt die maximale Verlängerung relativ zur Liniendicke an.
Es gibt dann auch noch spezielle Füllregeln mit der
Eigenschaft fill-rule
, falls
das Polygon gefüllt werden soll und sich seine Ränder an
bestimmten Punkten schneiden und so mehrere Flächen entstehen.
Beispiel Polygone (Quelltext zu Polygonen).
Beispiel Polygone - zu vermeidende Problemfälle
(Quelltext zu Polygone - zu vermeidende Problemfälle).
Die korrekte Darstellung ist ein blauer Kreis oben rechts und
(unten) links und ein blaues Quadrat unten (rechts) auf gelbem Grund.
Rot bedeutet eine falsche Anzeige, denn rote Objekte werden
entweder von blauen verdeckt oder nicht angezeigt.
Es ist (mir) kein Darstellungsprogramm bekannt, welches das Beispiel korrekt anzeigen täte.
Einmal abgesehen von den anzuzeigenden Beispielen der Länge 0 sind folglich die problematischen
Notationen zu vermeiden.
Sollen regelmäßige oder zufällig erstellte Polygone gezeichnet werden, macht es natürlich keinen Spaß, die Punkte alle per Hand auszurechnen. Da kommt PHP gerade recht:
regelmäßige Polygone mit PHP und SVG (Quelltext zu den Polygonen mit PHP und SVG).
Und weil es so schön ist, hier noch ein Polygon-Generator, die Parameter sind als GET-Parameter in der URI zu übergeben, einfach mal experimentieren, was wofür gut ist: Polygon-Generator
Oft werden Elemente wiederholt verschoben, gedreht oder skaliert angezeigt. Der oder die variierten Attribute oder Eigenschaften
der einzelnen Elemente hängen dann in der Regel über einen funktionalen Ausdruck zusammen.
Das wird dann auch Schar genannt. Der einfachste Zusammenhang ist wohl der affine. Ist P(0) ein Vektor von Startparametern und P(n) ein Vektor von Endparametern,
wobei n eine ganze Zahl ist und n+1 Elemente i = 0 bis n angezeigt werden sollen, so ergibt sich für eine affine Schar mit
u = i/n:
P(i) = P(n) u + (1 - u) P(0)
In einer Verallgemeinerung kann auch u eine Funktion von i/n sein, welche von 0 bis 1 geht für i von 0 bis n.
Die obige Darstellung entspricht übrigens einer Bézierkurve erster Ordnung, andere Ordnungen und andere
funktionale Zusammenhänge sind natürlich auch nutzbar. SVG stellt dafür keine
gesonderte Funktion zur Verfügung, daher kann das einfach mit PHP ausgerechnet werden -
eignet sich übrigens auch, um die Farbe von n+1 Objekten von Objekt zu Objekt nach einem
regelmäßigen Schema zu variieren.
Linienscharen mit
PHP und SVG
(Quelltext zu
den Linienscharen mit PHP und SVG).
Linienscharen mit quadratischer Scharfunktion
(Quelltext zu
den Linienscharen mit quadratischer Scharfunktion).
Linienscharen mit kubischer Scharfunktion
(Quelltext zu
den Linienscharen mit kubischer Scharfunktion).
Durch Gruppenbildung könnte man noch einiges eleganter machen, dazu kommen wir im nächsten Abschnitt.
Mittels des g
-Elements können Objekte zu einer Gruppierung zusammengefaßt
werden, etwa um dieser Gruppierung gemeinsame Eigenschaften oder Beschreibungen zuzuordnen.
Eine Gruppierung kann auch der Strukturierung dienen, wenn eine Gruppe von Objekten eben ein neues
Objekt repräsentiert, welches als eigene Identität vom Rest abgegrenzt werden soll.
Sofern es sich nicht um spezifische Attribute handelt, sondern um optionale Eigenschaften, kann so ganz praktisch
zum Beispiel einer Gruppe von Objekten eine kollektive Farbauswahl zum Füllen oder für den
Rand zugeordnet werden.
Beispiel für eine Gruppierung
(Quelltext zur Gruppierung)
Dieses dient vor allem dazu, die Dateigröße durch Einsparung redundanter Informationen zu
verkleinern. Mehr zu Gruppierungen gibt es dann im Abschnitt Transformationen.
Zu dekorativen Zwecken ist in SVG 1.1 auch CSS einsetzbar. Alternativ ist auch XSL möglich, worauf ich hier nicht eingehen werde. Es gibt sogar für SVG zahlreiche weitere Attribute, die vom Namen her identisch mit den CSS-Eigenschaften sind. Welche Attribute es genau gibt, ist in der Spezifikation im einzelnen aufgelistet und hier nur teilweise vorgestellt. Gibt es sowohl Angaben zur Eigenschaft als auch zum Attribut, so hat die CSS-Angabe Vorrang, ähnlich wie das bei HTML mit CSS der Fall ist. Hinsichtlich der Selektoren, Pseudoformate etc ist CSS 2.0 die für SVG 1.1 relevante Version, man kann also nicht erwarten, daß Modifikationen oder Selektoren aus den Versionen 2.1 oder 3 interpretiert werden.
Von XHTML ist ja schon die Aufgabenteilung bekannt,
daß XHTML den Inhalt gemäß seiner Funktion auszeichnet,
während CSS für Dekoration, Design und Layout zuständig
ist. Während es bei XHTML-Dokumenten relativ einfach ist, zwischen
Funktion und Dekoration zu unterscheiden, ist das bei den meist inhaltsleeren
SVG-Elementen deutlich schwieriger, teilweise etwas Geschmackssache.
Jedenfalls soll CSS nicht
die Funktion des Dokumentes beeinträchtigen. Das Dokument sollte
also zunächst ohne CSS auf eine sinnvolle Funktion getestet werden,
bevor es an die Dekoration mit CSS geht. Kritisch ist diese Forderung vor
allem, weil die meisten Elemente ohne Farbangaben die Farbe schwarz
haben - was ein mit CSS farbig gemachtes Bild bei einer Anzeige ohne
CSS schnell sinnlos machen kann. Dies ist relevant, weil der Standard
SVG tiny kein CSS vorsieht. Allenfalls interpretiert
etwa Opera 8 die SVG-Attribute in CSS-Notation
noch in der Direktformatierung bis zum ersten auftretenden Problem mit CSS.
Ähnliches gilt übrigens für KSVG1 im
Konqueror.
Damit sind die Probleme nicht ausgestanden, zumindest was die
Zugänglichkeit für den Nutzer anbelangt. Während es
in XHTML einfach und sinnvoll ist, als Autor komplett auf die ohnehin veralteten
Präsentationsattribute zu verzichten, ist dies bei SVG kaum sinnvoll
möglich. Da die direkt im Dokument befindlichen Präsentationsattribute
auch laut der CSS-Spezifikation in CSS-Eigenschaften konvertiert
werden, die formal direkt am Beginn der CSS-Kaskade des Autorenstils stehen,
haben sie niedrigere Priorität als Autorenstilvorlagen, aber höhrere Priorität als eine
gegebenenfalls vorhandene Stilvorlage des Nutzers, somit hat der Nutzer keine einfache
Chance, die Zugänglichkeit eines Dokumentes für seine Zwecke zu
verbessern. Dies funktioniert etwa, wenn das Dokument lokal auf dem eigenen
Rechner abgespeichert wird und die Autorenstilvorlage ersetzt oder ergänzt wird.
Für den Autor wiederum ist CSS nur von begrenztem Nutzen, da er vermutlich
bei den meisten Anwendungen nicht sehr viel als rein dekorativ einstufen wird und
somit ohnehin die Präsentationsattribute vorziehen wird.
Schauen wir uns trotzdem einmal Beispiele an:
Beispiele für CSS in SVG
(Quelltext zu CSS in SVG)
- man achte vor allem auf die XML-konforme Einbindung der externen
CSS-Dateien über XML-Verarbeitungsanweisungen
in der zweiten und dritten Zeile. Wird darin ein title
-Attribut
angegeben und bei einem alternate
="yes", so kann
wie bei XHTML+CSS im Darstellungsprogramm zum
alternativen Stil gewechselt werden. Um die Zugänglichkeit des Dokumentes bei der
Verwendung von CSS auch für Nutzer von Darstellungsprogrammen
aufrecht zu erhalten, die eigentlich nur SVG tiny abdecken, empfiehlt sich dann
entweder global um alle Elemente oder doch um die von CSS betroffenen das
noch zu besprechende g
-Element zu ziehen und für dieses
etwa fill
="none"
stroke
="#000"
stroke-width
="1" anzugeben.
Neben den XML-Verarbeitungsanweisungen kann bei nicht alternativen
Stilvorlagen auch die @import
-Regel von CSS
verwenden, um externe Stilvorlagen einzubinden:
@import von CSS in SVG
(Quelltext zu @import von CSS in SVG)
Hilfreich sind bei CSS insbesondere die reichhaltigen Möglichkeiten, mit Selektoren
Elemente auszuwählen. Dazu kann das Attribut class
(und auch andere Attribute) verwendet werden, um bestimmte Klassen von Elementen
auszuwählen. Letzteres ist besonders hilfreich, wenn Elemente alternierend mit
Eigenschaften ausgezeichnet werden sollen, diese aber auch leicht wieder änderbar
sein sollen. Siehe etwa folgendes Beispiel:
Klassen und CSS
(Klassen und CSS)
Bei dem Beispiel ist es nun einfach möglich, die Farben der verschiedenen Klassen zu wechseln.
In SVG tiny 1.1 bleibt einem eigentlich nur übrig, in diesem Falle die
Eigenschaften fill
alle einzeln zu modifizieren. Bei SVG tiny 1.2
bietet es sich hingegen an, einfach vier verschiedene Maldienste solidColor
zu definieren und
statt der Farbangaben zu referenzieren. Bei SVG 1.1 kann ähnliches mit einem
einfarbigen Farbverlauf oder Muster erreicht werden. Einen weiteren Ausweg bietet natürlich
PHP - da sind derartige Änderungen natürlich auch kein Problem, was
allerdings keine Lösung ist, wenn statische Dateien gefordert sind.
Der Vorteil der Maldienste ist jedenfalls, daß diese selbst und damit auch die Farben oder auch
Transparenzen der Klassen auf einmal deklarativ animiert werden können. Die Animation bezieht
sich immer auf einzelne Eigenschaften oder Attribute von einzelnen Elementen, nicht auf ganze Klassen.
Werden die Eigenschaften nicht vererbt oder eben referenziert, so sind sie nicht für eine Animation
einer ganzen Klasse von Objekten erreichbar. Für CSS 3 ist eine eigene Art von
Animation geplant, die allerdings deutlich einfacher und von der Anwendung her beschränkter ist
als die von SVG, die allerdings den Vorteil hat, daß man damit eben über
Selektoren beliebige Klassen oder Sammlungen von Elementen gleichzeitig ansprechen kann.
Ähnlich wie in XHTML steht auch in SVG ein
a
-Element für
Verweise zur Verfügung. Das Verweisziel wird mit dem Attribut
href
angegeben.
Mehr noch als in XHTML
obliegt es dem Autor, Verweise so zu gestalten, daß der Nutzer erkennt, daß
es sich um einen Verweis handelt. Bei folgendem Beispiel ist das jeweils durch blaue
Ränder angedeutet in Anlehnung an die blauen Verweise in XHTML.
Außerdem ist ein title
-Attribut angegeben,
obgleich das wohl derzeit nur von einigen Darstellungsprogrammen sinnvoll interpretiert wird
(etwa von Opera 9 oder den Geckos) - was zumindest bei Verweisen dringend und sinnvoll ist, ebenso
wie eine Darstellung des title
-Elementes als
Kindelement (kann Opera 9 auch in vielen Fällen), was die Qualität von
Darstellungsprogrammen sehr verbessert und solche Programme endgültig internet-tauglich
macht. Solche Verweise werden letztlich auf das XML-Format
xlink zurückgeführt, weswegen dieses auch als Namensraum
(xmlns)
mit anzugeben ist.
Beispiel für ein Bild mit einigen Verweisen
(Quelltext zum Bild mit einigen Verweisen).
Dargestellte Elemente können einen Verweis tragen. Umschließt das a
-Element
mehrere Elemente, so gilt der Verweis für alle. So weit ich das gesehen habe, ist in der Spezifikation
nicht eindeutig festgelegt, was passiert, wenn sich Elemente überlappen, die verschiedene Verweise tragen.
Plausibel ist nach dem Modell der Zeichenreihenfolge, daß im Überlappungsbereich der Verweis des zuletzt
im Dokument erwähnten Elementes beim Aktivieren zur Ausführung kommt. Gemäß
Dokumenttypdefinition ist es auch zulässig, anders als in XHTML,
daß ein a
-Element weitere a
-Elemente enthält.
Wie das Darstellungsprogramm damit umzugehen hat, ist im Text der Spezifikation nicht beschrieben.
Eindeutig festgelegt ist nur, daß zu einem a
-Element genau ein verweisendes
Element gehört und genau ein Verweisziel. Plausibel ist auch hier, daß bei
Überlappungen wieder die letzte Angabe ausgeführt werden soll.
Das sollte so lange so sein, wie nicht display
auf none
gesetzt wird oder visibility
auf hidden.
Die Fähigkeiten der Darstellungsprogramme sind oft noch recht
unterschiedlich. Dies kann jeweils mit dem switch
-Element
abgefragt werden. Mittels eines Attributes wird eine Zeichenfolge angegeben,
die Anforderungen an die Fähigkeiten des Darstellungsprogrammes
stellt. Sind diese nicht gegeben, wird statt des Elementes mit dem Attribut das
folgende innerhalb des switch
-Elementes angezeigt.
Sollen mehrere Elemente ausgeführt werden, so sollten diese dann
mit einem g
-Element umschlossen werden, bei dem dann das Attribut
zur Abfrage angegeben wird. Es können mehrere Alternativen hintereinander
abgefragt werden.
Zur Verfügung stehen die Attribute
requiredFeatures
, requiredExtensions
und systemLanguage
.
Auswahl 1
(Quelltext zur
Auswahl 1) - hier wird eine fiktive Erweiterung gefordert, die kein
Darstellungsprogramm kennen kann - statt einiger Kreise sollte gelb auf
rotem Untergrund ein Kommentar erscheinen, daß die Erweiterung
nicht verfügbar ist.
Auswahl 2
(Quelltext zur
Auswahl 2) - hier werden einige Eigenschaften oder Elemente von SVG
abgefragt - einige mögen verfügbar sein, einige nicht.
Auch die Systemsprache wird abgefragt.
Zumindest bei Opera 8 ist es so, daß dieser sich etwas weniger zutraut
als er wirklich kann - wenn man die Angaben verwendet, ist man also
eher auf der sicheren Seite, mag aber sein, daß einem dabei einige
Fähigkeiten entgehen. Bei Mozilla/Gecko sieht es nach einer
realistischen Selbsteinschätzung aus.
KSVG behauptet hingegen selbstsicher, alles zu
können, was aber sicher falsch ist. Er entlarvt sich auch als frecher
Lügner, denn er behauptet auch, Eigenschaften zu unterstützen, die
gerade frei erfunden wurden. Und das adobe-plugin (aktuelle
Linux-Version 3.01) ist der Tiefstapler schlechthin - es behauptet gar nichts
zu können, was aber auch daran liegen kann, daß das adobe-plugin
nach eigenem Bekunden SVG 1.1 noch nicht kennt. Auch hier sind von den
Anbietern noch deutlich mehr Ehrlichkeit und Präzision gefragt, damit das
Format wirklich alltagstauglich für das internet wird. Zwar gibt es in
der Version 1.1 schon deutlich mehr abfragbare Eigenschaften, wenn man sich
die Fähigkeiten der Darstellungsprogramme so ansieht, wünscht man
sich als Autor aber deutlich mehr Details, um dem Nutzer solch lückenhafter
Darstellungsprogramme besser beistehen zu können. An den Beispielen (X)HTML
und CSS haben wir ja gelernt, daß es einige Jahre dauern kann, bis
die meisten Lücken geschlossen sind.
Ein Haken bei requiredFeatures
ist jedenfalls, daß mit
jeder neuen Versison von SVG auch neue Zeichenketten dafür herauskommen,
die alte Programme gar nicht kennen können, selbst wenn sie die gegebenenfalls unveränderte
Funktionalität durchaus bereitstellen können.
SVG tiny 1.2 stellt ferner zwei weitere Attribute bereits, diese sind
requiredFormats
und requiredFonts
.
Mit ersterem können Inhaltstypen (ehemals MIME genannt) abgefragt
werden, damit können dann sehr effektiv Alternativen in verschiedenen Formaten
bereitgestellt werden. Etwa ist die Interpretation des Formates image/gif in SVG
optional, image/png nicht, weshalb man da per switch
eine Auswahl
angeben kann. Interessanter ist das noch für Audio- und Videoformate, weil es da die Interpretation
aller Formate optional ist.
requiredFonts
kann verwendet werden, wenn es darauf ankommt,
bestimmte Schriftarten zu verwenden und sofern nicht verfügbar, gezielt Alternativen anzubieten.
So weit erst mal zu einigen Grundformen - weiteres wird in den anderen Menüabschnitten ergänzt.
Hier sind einige einfache Beispiele für Scharen von Grundtypen von
SVG wie Linien, Kreise, Ellipsen, Rechtecke. Allerdings wird bei wenigen Attributen
wie transform
bereits etwas vorgegriffen:
SVG mit PHP: Linien
SVG mit PHP: Kreise
SVG mit PHP: Kreise 2
SVG mit PHP: Ellipsen 1
SVG mit PHP: Ellipsen 2
SVG mit PHP: Ellipsen 3
SVG mit PHP: Rechtecke
Mittels der GET-Parameter x für die Breite, y für die Höhe,
deren Maßeinheit m (mm, cm, %, px)
und einem freien Parameter n (meist korreliert mit der Anzahl der Objekte in einer Schar) kann das
Bild beeinflußt werden. Andere Parameter werden zufällig bestimmt.
Die gleichen Bilder mit einem anderen Parameter n:
SVG mit PHP: Linien
SVG mit PHP: Kreise
SVG mit PHP: Kreise 2
SVG mit PHP: Ellipsen 1
SVG mit PHP: Ellipsen 2
SVG mit PHP: Ellipsen 3
SVG mit PHP: Rechtecke
Als eine größere praktische Anwendung habe ich in meiner Photogalerie einen Stil realisiert, bei dem die eigentlichen Galerien (die nur wenig Text enthalten) mit SVG + CSS dargestellt werden. Als Alternative gibt es auch Stile, die XHTML+CSS oder nur XHTML verwenden: Photogalerie.