XML » SVG Presenter - Carto:net

XML » SVG PRESENTER | STRUKTURIERTE MULTIMEDIA-PRÄSENTATION IM WEB 144
Angabe, welches Attribut wie animiert werden soll, genügt. Im direkten Vergleich mit dem Frame-basierten
Flash-Ansatz wirkt diese Herangehensweise daher deutlich „sauberer“ – die einzelnen Animationen und ihre
Verknüpfungen lassen sich quasi direkt dem SVG-Quellcode entnehmen:
Durch die zeitbasierte Animation ist eine wesentlich einfachere Erstellung von SVG-„Filmen“ möglich –
außerdem sind die Dateien dadurch sehr platzsparend. Der Nachteil ist jedoch die erhöhte Rechenleitung
auf der Clientseite.
[Kunz00]
Obgleich Flash, wie im Rahmen unserer Analyse des SWF-Formates [s.4.5.3.1] besprochen, von seinem
Grundprinzip her primär Animationsbasiert ist und die SWF-Dateistruktur daher in erster Linie die sowohl
kompakte als performant darstellbare [vgl. Katz00] 1 Speicherung linearer Animationen ermöglicht, sehen
die SVG-Experten Andreas Neumann, Peter Sykora und Andréas Winter [vgl. NeWi00, NSW02] daher insbesondere
die Animationskomponente im Rahmen von SVG „deutlich eleganter“ gelöst als beim Flash-
Pendant:
Animationen setzt SVG zusammen mit SMIL etwas eleganter um. SMIL-Filmchen stützen sich auf feste
Zeitvorgaben, während Flash auf Frames aufbaut, womit die Wiedergabedauer stark von der Rechenleistung
des Clients abhängt. Flash kann zwar die wichtigsten Grafikeigenschaften animieren, SVG gewährt
dem Nutzer aber mehr Spielraum, da es auf Wunsch jedes beliebige Attribut zum Leben erweckt – sogar
mit wählbarer Beschleunigung.
[NSW02:220]
5.4.2.6 Do it yourself: Skripten mit ECMAScript
Auch die „Scriptability“ des SVG-Formates erweist nach genauerer Betrachtung als dem proprietären Flash-
Konkurrenten weitaus überlegen: So sind im Rahmen des Flash-Authoring-Tools zwar weitgehende Programmier-
und Scripting-Möglichkeiten mithilfe der Flash-eigenen Skriptsprachen FlashScript und Action-
Script durchaus gegeben – da beide Sprachen jedoch, wenn auch der JavaScript-Syntax entlehnt [vgl.
Star01:11], nicht-standardisierte „Erfindungen“ Macromedias darstellen, erscheint ihre Anwendung jedoch
nicht ganz unproblematisch, da nicht nur die Eigenheiten der Programmiersprache von Grund auf neu gelernt
werden müssen, sondern die Skript-Elemente überdies mit den JavaScript-Codebereichen der HTML-
Umbebung inkompatibel sind.
Die Anwendung der standardisierten und in Form ihres Vorgängers JavaScript überaus bekannten und geläufigen
„Programmier“-Sprache ECMAScript [ECMA97] im Rahmen von SVG stellt an dieser Stelle daher
nicht nur den deutlich konsequenteren und aus Nutzersicht auch komfortableren Ansatz dar, sondern ermöglicht
überdies den programmatischen Zugriff auf sämtliche Elemente und Objekteigenschaften des
SVG-Dateibaumes selber, sowie, da sämtliche Komponenten über dieselbe Script Engine verbunden sind,
darüber hinaus auch ihrer HTML- und Browserumgebung.
Aufgrund der ausgesprochenen „Mächtigkeit“ insbesondere der neuen, objektorientierten Ausprägungen
der ECMAScript-Sprache [s.6.5.1] stehen dem Programmierer von Präsentationssystemen somit schier unbegrenzte
Möglichkeiten zur Verfügung: Neben einfachen SVG-Objektmanipulationen über die DOM-
Schnittstelle [s.5.1] und somit maus-sensitiven Roll-Overs wie bereits aus HTML bekannt, ist die Realisierung
umfangreicher Frameworks wie etwa einer eigenen Animations-Engine [s.6.5.2.1] oder der clientseitigen
Konvertierung separater XML-Strukturen [s.6.5.1] auf recht komfortablem Wege möglich. Darüber
hinaus bietet sich – nicht zuletzt, um dem ohnehin im Rahmen der rechenintensiven Viewer-Anwendung
stark belasteten Clientrechner zusätzliche „Arbeit“ zu ersparen – im Rahmen von SVG die Möglichkeit an,
1 „[SWF represents] a nice balance between compactness of representation and speed of rendering” [Katz00]