Anforderungen an einen kartographischen Viewer für ... - Carto:net

3 Technologien
Auch serverseitig können mit vielen verschiedenen technologischen Möglichkeiten Klassen oder
Skripte programmiert werden, die SVG Code schreiben. Besonders beliebt sind Servlets um SVG
Dateien zu erzeugen. Auch ASP Seiten mit eingebundenem SVG erfreuen sich großem Zuspruch.
3.2.4.4.3 Toolkits
Ein Toolkit ist eine Sammlung von Anwendungen. Diese umfassen programmierte Bibliotheken
zum Erstellen, Weiterverarbeiten und Betrachten von SVG Dokumenten (vgl. auch Kapitel
3.2.4.5.3). SVG Toolkits sind in einer Programmiersprache geschrieben, meist in Java.
Besonders populär ist der Batik SVG Toolkit des Apache Projekts (vgl. APACHE 2002b), ein
anderer ist der CSIRO SVG Toolkit (vgl. CSRIO 2002). Der Vorteil liegt in der plattformübergreifenden
Einsetzbarkeit. Jedes Betriebssystem, dass das Java Runtime Environment
installiert hat, kann diese Klassen nutzen. Sie können deswegen eine Serverimplementierung aber
auch eine Clientimplementierung unterstützen.
Hinweis: Die Bitmaps in Abbildung 6 "Visuelle Variablen in Abhängigkeit der Implantation" sind mit dem Batik-
Rasterizer erstellt worden (vgl. Kapitel 2.2.3.2).
3.2.4.5 SVG Viewer
SVG Viewer sind Anwendungen, die SVG darstellen können. Sie müssen SVG gemäß der
Spezifikation implementieren und sollten weiter Features, wie beispielsweise DOM oder CSS
unterstützen. Gegenwärtig dienen vor allem Plug-In's dazu, SVG darzustellen. Doch auch über den
Einsatz native Browserunterstützung und eigenen Vieweranwendungen sollte nachgedacht werden.
Hinweis: Großes Manko des SVG Standards sind mangelnde Viewerimplementierungen, denen vor allem
Scriptingmöglichkeiten fehlen. Im Folgenden werden verschiedene Viewer Implementierungen diskutiert.
3.2.4.5.1 Plug-In Lösung
Browser Plug-In's dienen dazu, einem Browser zu erweitern, damit zusätzliche Dateiformate
gerendert werden können. Der am weiten verbreiteteste für SVG, ist der Adobe SVG Viewer (zur
Zeit in Version 3 vorliegend; vgl. ADOBE 2002). Weiter ist seit Kurzem auch ein Preview des
Corel SVG Viewer Plug-In's erhältlich (vgl. COREL 2002), der dem ASV 3 sehr ähnelt.
Probleme diesbezüglich sind leicht auszumachen, da der Webentwickler nicht davon ausgehen
kann, dass der Client diesen installiert hat. Man kann sich zwar programmiertechnischer Art mit
Abfrage Statements behelfen, die den Client auf entsprechende Plug-In's untersuchen. Doch kann
dieser Weg nicht als Lösung angesehen werden, einen Standard zu verbreiten. Auch eine eventuelle
Installation kann nur als Zwischenschritt zur Etablierung eines Webstandards gesehen werden.
Oftmals sind Administratorenrechte oder Spezialwissen notwendig, um das Plug-In einzurichten.
Viele Produkte der Firma Adobe (z.B. Acrobat Reader 5) installieren den ASV3 vom Anwender
unbemerkt mit (vgl. SVG-WIKI 2002, Adobe SVGViewerdistribution). Diese Tatsache trägt zwar
zu einer größeren Verbreitung bei, doch sie ist nicht "im Sinne eines Webstandards". Zudem
erlauben viele Systemadministratoren nicht, Plug-In's zu installieren. Die Praxis zeigt, dass sie ein
Sicherheitsrisiko darstellen. Beispielsweise kann obwohl Scripting durch Browsereinstellungen
nicht zugelassen wird, ein Plug-In Scriptinginterpreter Scripte ausführen. Lösen kann die fehlende
Plug-In Akzeptanz eingeschränkt nur einfache Handhabung, wie Installation, kurze
Downloadzeiten zur Installation und plattformübergreifende Verbreitung. Optimalen Zustand
können aber nur native Browserimplementierungen erzielen (vgl. nächstes Kapitel).
Hinweis: Bei Windows kann über die COM Schnittstelle auf ASV3 Objekte aus jeder Applikation zugreifen. Dieser
Möglichkeit bedient sich beispielsweise der Vorschaumodus von Jasc Webdraw.
63