XML » SVG Presenter - Carto:net

XML » SVG PRESENTER | STRUKTURIERTE MULTIMEDIA-PRÄSENTATION IM WEB 141
spiel in [Listing, Abb.5.4.2.1] zu entnehmen ist, ist auch das SVG zugrunde liegende Grafikmodell durch
den so genannten „Painter’s Algorithm“ [vgl. Watt02:33] gekennzeichnet: Einzelne grafische Objekte werden
schlichterdings durch deklarativ darauffolgende Elemente überdeckt – ein zusätzlicher „z-Index“, wie
noch in Flash oder HTML benötigt, entfällt. Dieses (im Prinzip ja „logische“) Prinzip „erhellt“ nicht nur die
syntaktische Struktur der SVG-Datei, sondern begünstigt überdies dessen Übertragung: Ähnlich wie beim
„progressiven Rendering“ von HTML-Dateien können SVG-Grafiken so sequentiell „gestreamt“ und direkt
gezeichnet werden, da später folgende Objekte ihre „Vorgänger“ kurzerhand übermalen.
5.4.2.1 Deutlich sauberer als der Vorgänger VML
Im Gegensatz zum direkt an die PostScript-Syntax angelehnten
PGML wird im Rahmen der SVG-
Spezifikation hingegen eine verstärkte Konzentraion auf Cascading Style-Sheets [CSS98] deutlich: Im Gegensatz
zum in dieser Hinsicht recht unlogisch vorgehenden VML-Format [s.5.4.3] vermag SVG an dieser
Stelle jedoch inhaltlich zwischen mittels „direkten“ XML-Attributen realisierten Positionierungs und Größenangaben
(x,y,height,width) und im eher „stilistischen“ Bereich angesiedelten Stilangaben
(fill,stroke…) zu unterscheiden und ermöglicht somit eine deutlich sinnvollere Anwendung des Style-
Sheet-Prinzips. Zwar sind auch im Rahmen von SVG „redundante“ Deklarationen (beispielsweise die Determinierung
eines Füllwerts sowohl als direktes Attribut als auch CSS-Angabe) möglich – wie bereits bei
HTML werden die „direkten“ XML-Attribute in diesem Falle jedoch stets durch deren CSS-Pendants überdeckt,
was auch eine konsequente Anwendung umfassender Style-Sheet-Klassen möglich macht [vgl.
Behm02:55].
Ähnlich wie in VML und Flash lassen sich nun überdies so genannte „Symbole“ definieren, die über ein korrespondierendes
use-Tag mit entsprechenden Transformationseigenschaften beliebig oft innerhalb einer
SVG-Zeichnung zur Anwendung kommen und die Bilddaten über deren Wiederverwendbarkeits-
Eigenschaft so überschaubar und kompakt halten kann. 1 Auch über die so genannten „Rendering-
Eigenschaften“ lassen sich, wie bereits im VML-Vorgänger die grafischen Darstellungseigenschaften (Anti-
Aliasing, Qualitäts- oder Geschwindigkeits-optimierung) präzise regeln.
5.4.2.2 Kontrovers: Die verzweigten Pfade des path-Tags
„Nicht unumstritten“ [vgl. Tard01] erscheint hingegen Umsetzung des zentralen
path-Elements, welches
die Definition beliebiger Linien- und Bézierpfade ermöglicht: Im Gegensatz zum PostScript-Verwandten
PGML-Entwurf, der an dieser Stelle die „saubere“ Einbindung entsprechender Tochterknoten vorsieht
[s.5.2.3], geht SVG an dieser Stelle, ähnlich wie bereits in der VML-Spezifikation „im Grunde völlig unXM-
Lisch vor“ [Behm02:56]: So enthält stets das obligatorische d-Attribut des (im übrigen alleinstehenden) 2 die
einzelnen Pfadknoten samt Kontrollpunkte als einzelne, überdies „unkonventionell“ strukturierte Zeichenkette,
was nicht nur die Lesbarkeit dieser Notation deutlich einschränkt, sondern überdies eine Interpretation
der Pfaddaten über die DOM-Schnittstelle deutlich erschwert: 3
=
Listing 5.4.2.2: Definition eines Dreiecks (�) in SVG mit jeweils absoluten (li.) und relativen Koordinaten (re.).
1
vgl. hierzu [ibid] pp.56-57
2
Anm: Dies heisst, dass der Pfad i.d.R. nicht „umfassend“ ist (…), sondern lediglich einen einzelnen „Marker“ () darstellt.
3
s. hierzu die entsrpechenden Ausführungen von Jon Ferraiolo: “In recognition that path data into a single attribute makes DOM access
difficult…”, aus: XML Developer Mailing List (Thread „ What is wrong with SVG?”) vom 6. März 2000: http://lists.xml.org/archives/xmldev/200003/msg00199.html
[16.2.03]