XML » SVG Presenter - Carto:net

XML » SVG PRESENTER | STRUKTURIERTE MULTIMEDIA-PRÄSENTATION IM WEB 98
eine zentrale Rolle im Rahmen des Flash-Formates zukommt. Die (schematische) Darstellung einer beispielhaften
Flash-Datei 1 setzt sich demnach in der Regel wie folgt zusammen:
FWS // File-Header (ist immer die Umkehrung zu 'SWF')
flashVersion 3 fileSize 741 movieWidth 550 movieHeight 400 frameRate 12 count 2
// Beginnen mit 1. Frame:
SetBackgroundColor rgb_hex ffffff // Weisser Hintergrund
DefineShape id 1 // Form Definieren (Daten weggelassen)
PlaceObject shapeId 1 depth 26 matrix // Objekt mit Transf.-Matrix platzieren
[ a_fixed b_fixed] = [00010000 00000000]
[ c_fixed d_fixed] = [00000000 00010000]
[tx_fixed ty_fixed] = [000010a4 00000410]
ShowFrame // 1. Frame anzeigen
PlaceObject shapeId 1 depth 26 matrix // Objekt verschieben (= neu platzieren)
[ a_fixed b_fixed] = [00010000 00000000]
[ c_fixed d_fixed] = [00000000 00010000]
[tx_fixed ty_fixed] = [000012ea 00000690]
ShowFrame // 2. Frame anzeigen: Objekt wird diagonal nach rechts unten verschoben
...
Listing 4.5.3.1.1: „File-Dump“ einer Beispiel-SWF-Datei (Ausschnitt)
Auf Basis dieser Struktur wird überdies auch das grundlegende Prinzip des Flash-Formates deutlich: Im
Gegensatz zu anderen Grafik- und Animationsmodellen können in SWF-Dateien keine „ganzheitlichen Zusammenhänge“
etwa über den Verlauf einer Animation oder logischer Objektgruppen abgebildet werden –
diese werden stets in recht einfache Low-Level-Objekte sowie einzelne Frames einer Animation aufgegliedert.
Dies dient zwar eindeutig einer sehr schnellen Darstellung der Flash-Daten (schließlich muss ein entsprechendes
Anzeigesystem lediglich stets die einzelnen Anweisungen der jeweiligen Frames sequentiell ausführen),
lässt jedoch hinsichtlich des konzeptionellen Grundprinzips der SWF-Struktur den Schluss zu, dass
das Flash-Format an sich aus theoretischer Sicht ein eher „dummes Speicherformat“ darstellt, welches die
Abbildung logischer Zusammenhänge nicht erlaubt.
Aus diesem Ansatz ebenso ersichtlich ist somit auch der eigentliche Verwendungszweck des Formates als
primäres Anzeige- und Exportformat: Da eine Fragmentierung der Animationsdateien im Rahmen einer
Web-Exportfunktion stets „trivial“ ist, die „Zusammensetzung“ (bzw. Rekonstruktion) der einzelnen Flash-
Elemente hingegen erheblich aufwendiger ausfällt, ist das Format zur Darstellung im Web zwar optimal geeignet,
lässt sich jedoch weit weniger komfortabel weiterverarbeiten. Auf die hiermit verbundenen Schwierigkeiten
weisen unter anderem [PMEB01, Prob00a] hin: Aufgrund der Komplexität der Rekonstruktion
korrekter Animationszusammenhänge zog es das Entwicklerteam der Universität Nottingham um Steven
Probets schließlich vor, die Fragmentierung der Animationsdaten schlichterdings beizubehalten und lediglich
mittels JavaScript zu „emulieren“ [vgl. Prob00b,c].
4.5.3.2 Grafikmodell
Weitaus „kniffliger“ erweist sich an dieser Stelle jedoch das Flash und somit auch dem SWF-Format
zugrunde liegende Grafikmodell [vgl. PMEB01]: Da Semantik und Syntax des Flash-eigenen „Vector Paintings“
2 noch der SmartSketch-Generation entstammt und sich somit an „progressive Illustrations-Ansätze
aus den Anfängen der 90er Jahre“ [Dowd00] anlehnt, 3 weicht die Implementierung vektorbasierter Formen
und Stile erheblich von der Gewohnten PostScript-Notation ab: Da die Zeichenmethode des ursprünglich
auf Pen-Computing-Geräte ausgerichteten SmartSketch Formen und Stile bereits während des Zeichnens
1
Anm: Da die Struktur der Datei aufgrund der Binär-Eigenschaft des Formates nicht direkt dargestellt werden kann, behilft man sich an
dieser Stelle etwa eines so genannten „File Dumpers“, der die binären Informationen der einzelnen Tags und ihrer Inhalt „parst“ und in
menschenlesbarer Form ausgibt.
2
vgl. [Dowd00]
3
Anm: Schließlich war das SmartSketch-Prinzip ursprünglich auf Pen-Computing-Plattformen ausgerichtet.