XML » SVG Presenter - Carto:net

XML » SVG PRESENTER | STRUKTURIERTE MULTIMEDIA-PRÄSENTATION IM WEB 51
derte WWW-Benutzer lediglich eingeschränkt bedienbar, 1 „auch die Größe – und damit die Ladezeit – des
betroffenen Dokuments insgesamt steigt damit“ in immensem Umfang an [Rieh01:55]. Aus diesem Grund
erscheint speziell die Auswahl der im Rahmen des WWW zur Anwendung kommenden Bildformate interessant.
Diese obliegt jedoch, im Gegensatz zur eigentlichen HTML-Spezifikation bei visuellen Tags und Einbettungs-Syntax,
nicht, wie man meinen möchte, den Entwicklern der HTML-Sprache, sondern stets den
Programmierern der jeweiligen Browser-Implementierungen:
Browsers should be afforded flexibility as to which image formats they support… If a browser cannot interpret
a given format, it can do whatever it wants instead.
(Marc Andreessen) 2
Umso überraschender erscheint unter dem Blickwinkel der soeben ausgeführten Überlegungen hinsichtlich
Dateigröße und Ladezeit daher die Tatsache, dass Mosaic-Entwickler Andreessen an dieser Stelle zunächst
völlig unkomprimierten Bildformaten den Vorzug gibt:
XBM and XPM are good [image formats] to support, for example… 3
Dieser Umstand lässt sich jedoch bei näherer Betrachtung der beiden Dateiformate etwas erhellen: So stellen
die von Andreessen angesprochenen (und in der Tat bereits mit der Mosaic 0.10-Auslieferung unterstützten)
Dateiformate X-BitMap (XBM) sowie X-PixMap (XPM) schlicht die seinerzeit in der Unix-Welt
übliche Konvention zur Speicherung von Icons dar. Da aufgrund der starken Unix-Orientierung der akademischen
Welt insbesondere das X-Motif-System in universitären Einrichtungen wie dem CERN und
NCSA weite Verbreitung genoss, lag es daher (auch angesichts der relativ späten Windows-Portierung des
Mosaic-Programms) durchaus nahe, sich dieses Quasi-Standards zur Bildkodierung zu bedienen. Aufgrund
der Tatsache, dass, wie eingangs erwähnt, Bildreferenzen zunächst ohnehin rein wissenschaftlichen Abbildungen
dienen sollten, fiel daher auch anfangs der ausschließlich schwarz-weiße, unkomprimierte Speicheralgorithmus
des Formates nicht weiter ins Gewicht: Der Vorteil, dass sich XBM-Grafiken in reiner Textform
und somit zumindest in der Theorie (wie auch durch die Mosaic-Entwickler angedacht) „inline“, also
statt externer Referenz prinzipiell direkt im HTML-Code abbilden ließen, wog in den Augen Andreessens
die strukturelle Schlichtheit des Formats bei weitem auf. Bei genauerer Betrachtung des XBM-Formats wird
überdies deutlich, dass der Text-Code nicht lediglich einzelne Bilddaten enthält, sondern verblüffenderweise
reinen C-Quelltext darstellt, was die Verwendung des Formates im Kontext weiterer (da primär Cbasierter)
Unix-Programme freilich begünstigt:
#define directory_width 20
#define directory_height 23
static char directory_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xf8, 0x01, 0x00, 0x04, 0x02, 0x00,
0x02, 0x04, 0x00, 0x01, 0xf8, 0x01, 0x01, 0x00, 0x02, 0x01, 0x00, 0x04,
0x01, 0x00, 0x0e, 0x01, 0x00, 0x0d, 0x01, 0x00, 0x0e, 0x01, 0x00, 0x0d,
0x01, 0x00, 0x0e, 0x01, 0x00, 0x0d, 0x01, 0x00, 0x0e, 0x01, 0x00, 0x0d,
0x01, 0x00, 0x0e, 0x55, 0x55, 0x0d, 0xaa, 0xaa, 0x0e, 0xfc, 0xff, 0x07,
0xf8, 0xff, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
Listing und Abb. 3.3.2: Kodierung eines Directory-Icons in XBM, sowie dessen Darstellung
Außerhalb der Unix-basierten Welt, so merkt unter anderem [Mian99] an, ist dieses vielmehr Icon- als
Bildorientierte Format 4 allerdings „äußerst selten anzutreffen“ 5 – obschon es zumindest laut [Blei99] nicht
nur das erste von Web-Browsern unterstützte, sondern überdies angeblic immer noch „das bevorzugte Bit-
1
vgl. [Niel96a]
2
s. hierzu Marc Andreessens “IMG Tag Proposal” im WWW-Talk-Forum vom 25. Februar 1993 (mittlerweile offline)
3
zitiert ebenda.
4
“An XBM file is actually more analogous to an icon file on Windows than to a BMP” [Mian99] p.3
5 “XBM [is] rarely used outside that environment…” [ibid]