Als Werkzeug zur Konvertierung des Buches wurde Microsofts FrontPage (Version 1.1, Evaluation Copy) eingesetzt. FrontPage verfügt über einen WYSIWYG-Editor zur Erstellung und Bearbeitung von HTML-Seiten und über einen "Explorer", mit dem komplette Hypertext-Netze verwaltet werden können. Der FrontPage-Editor ist in der Lage, Dateien im Rich-Text-Format (RTF) zu importieren und als HTML-Dateien zu speichern.
Das Werk von Werner Brecht lag im "MS Word für Windows"-Format vor und wurde zunächst mit Word als RTF-Datei exportiert und in FrontPage importiert. Bei diesem Vorgehen läßt sich ein Verlust von Formatierungsinformationen nicht verhindern. So gehen u.a. Hoch- und Tiefstellungen verloren. Außerdem werden logische Formatierungen - wie Überschriften und Aufzählungen - durch harte Formatierungen ersetzt. Insbesondere werden vorformatierte Passagen wie Programmlistings ohne multiple Leerzeichen oder Tabulatoren dargestellt.
Der aktuelle HTML-Standard ist nicht in der Lage, mathematische Sonderzeichen darzustellen. Diese Zeichen wurden als Grafiken im GIF-Format importiert. Auf die Darstellung ganzer mathematischer Ausdrücke wurde verzichtet. Einerseits verbessert sich dadurch die Wartbarkeit - Grafiken sind wiederverwendbar und das Netz wird übersichtlicher -, andererseits wird die Ladezeit für einzelne Seiten gesenkt. Die Sonderzeichengrafiken können nicht mit der Veränderung der Schriftgröße im Browser skaliert werden. Die Größe der Grafiken wurde allerdings so gewählt, daß bei Schriftgrößen aus einem angemessenen Intervall eine ansprechende Optik gewährleistet bleibt. Für jedes auf diese Art eingebundene Sonderzeichen wurde eine sinnvolle alternative Text-Repräsentation festgelegt, damit der Buchtext auch für Benutzer verständlich ist, die keine Grafiken darstellen können oder wollen.
1. Probleme mit HTML
Natürlich können nicht alle Formatierungen, die in Word möglich sind, in HTML dargestellt werden. Es wurde allerdings versucht, Formatierungen weitgehend zu simulieren. So wurden beispielsweise Tabellen, die im Original nur teilweise mit Gitternetzlinien versehen waren, als verschachtelte Tabellen realisiert, da in HTML eine Tabelle nur ganz oder gar nicht mit einem Gitternetz dargestellt werden kann (siehe die Tabelle am Ende von Kapitel 4.2 oder am Anfang von Kapitel 5.2).
Hoch- und Tiefstellungen sind in HTML nur in einer Ebene möglich. Es mußten aber Formeln mit Indizes in Exponenten dargestellt werden. Bei diesen Formeln mußte auf die Tiefstellung der Indizes verzichtet werden: Variablenname und Index stehen in einer Ebene.
Referenzen auf HTML-Seiten oder Bookmarks müssen eindeutig sein. Im Register wird aber häufig auf verschiedene Seiten verwiesen. Um multiple Verweise zu ermöglichen, wurde das Register erweitert: Einträge der Form
Array (Reihung), 121, 123
wurden ersetzt durch Verweise wie
Array (Reihung)
wobei die Links (unterstrichen) auf entsprechende Stellen im jeweiligen Kapitel verweisen.
Die Aufteilung des gesamten Dokumentes in einzelne Word-Dokumente wurde unverändert in die HTML-Konvertierung übernommen. Das führte zu HTML-Seiten sehr unterschiedlicher Länge. Aus Gründen der Übersichtlichkeit hätte es sich vielleicht angeboten, sehr lange Kapitel noch einmal zu untergliedern.
Sonderzeichen in Links stellen ein Problem dar: Üblicherweise werden Links in blauer Farbe und unterstrichen dargestellt. Diese Darstellung ist aber nicht eindeutig festgelegt, sie kann vom Benutzer im Web-Browser festgelegt werden. Die entsprechende Formatierung erfaßt allerding natürlich nur reinen Text und keine eingebundenen Grafiken. Wie oben bereits erwähnt, mußten Sonderzeichen aber als GIF-Grafiken eingebunden werden. Sonderzeichen lassen sich also nur schwerlich in Links integrieren. Wir haben es vorgezogen, in Links vorkommende Sonderzeichen auszuschreiben.
2. Probleme mit MS FrontPage
Die Entwicklungsumgebung MS FrontPage scheint noch nicht komplett ausgereift zu sein. Während der Konvertierung des Buches arbeiteten wir recht intensiv mit diesem Tool und haben einige, teilweise schwer reproduzierbare, Fehler und Systemabstürze festgestellt, z.B.:
· Im FrontPage-Explorer werden ständig sämtliche Dateien des Web angezeigt. Diese Anzeige wurde scheinbar ohne Grund teilweise auf einige wenige Dateien reduziert. In diesen Fällen mußte die Anzeige durch eine explizite Refresh-Operation aktualisiert werden.
· Wird eine komplette Zeile als Bookmark markiert, hängt der FrontPage-Editor an die Zeile ein Freizeichen (Whitespace) an. Das hat den unangenehmen Effekt, daß das angehängte Whitespace mit zum Bookmark gehört, also auch im entsprechenden Link enthalten sein muß, damit dieser funktionieren kann. Das stellt eine potentielle Fehlerquelle dar, die das Verweisen auf Bookmarks erschwert.
· Die Undo-Funktion des FrontPage-Editors macht teilweise nicht nur die letzte Operation rückgängig, sondern versetzt das System in den Zustand direkt nach der letzten Speicherung. Dabei gehen natürlich mehr oder weniger viele Arbeitsschritte unwiederbringlich verloren.
Besonders ärgerlich sind einige Unzulänglichkeiten des FrontPage-Editors, die konzeptueller Natur sind und die Arbeit deutlich erschweren:
· Die Werkzeugleiste des Editors läßt sich nicht anpassen, Makros lassen sich nicht aufzeichnen. Da die Operationen "Hochstellen" und "Tiefstellen" nicht in der Standard-Werkzeugleiste enthalten sind, mußte für eine einzige Hoch- oder Tiefstellung jeweils der Eintrag "Eigenschaften" aus dem Kontextmenü des selektierten Zeichens gewählt werden. In diesem Kontextmenü wurde die Formatierung "superskript" bzw. "subskript" ausgewählt, der Dialog mußte mit der Return-Taste oder durch Klick auf "OK" beendet werden.
· Zwischen zwei HTML-Tabellen läßt sich mit dem FrontPage-Editor nichts einfügen. Das liegt lediglich daran, daß es keine Möglichkeit gibt, den Cursor zwischen zwei Tabellen zu positionieren. Hier wäre eine einfache Tastenkombination wünschenswert, die direkt nach einer Tabelle einen Absatz einfügt.
· Der FrontPage-Editor unterstützt nicht die Skalierung von eingebundenen Grafiken, obwohl das in HTML durchaus möglich ist.
Im Buchtext werden zahlreiche namhafte Mathematiker und andere Wissenschaftler erwähnt. Es empfiehlt sich, im Internet nach Web-Servern zu recherchieren, auf denen Informationen über die jeweiligen Personen angeboten werden. Indem dann bei der Nennung einer solchen Persönlichkeit auf ein entsprechendes Web-Angebot verwiesen wird, wird der Horizont des Einzelprojektes erweitert; es findet eine stärkere Integration in das Medium "World Wide Web" statt. Da sich das Internet im ständigen Wandel befindet, empfehlen wir, nur "institutionalisierte" Links zu wählen, also Verweise auf Seiten z.B. von Universitäten, bei denen eine übermäßig schnelle "Veraltung" des Links nicht absehbar ist.
Ansatzweise haben wir diese Vorgehensweise bei einigen Persönlichkeiten bereits realisiert. So wird z.B. auf die Online-Version eines Buches über Alan Turing verwiesen. Die "externen Links" sind auf einer HTML-Seite namens extlinks.htm zusammengesaßt. Diese Seite ermöglicht es dem Web-Administrator, ohne große Probleme zu überprüfen, ob die referenzierten Links überhaupt noch existieren. Zur Durchführung dieses Tests könnte man auch eine Java-Applikation entwicklen, die die einzelnen Links einfach "durchprobiert" und einen Link als "broken" (veraltet) markiert, wenn innerhalb einer gewissen Zeitschranke keine Verbindung zum Web-Server aufgebaut werden kann.
Jeweils am Kopf und Fuß jedes Kapitels sind kleine Bitmuster-Grafiken als Navigationsschaltflächen eingebunden. Diese Positionierung der Schaltflächen hat den Nachteil, daß die Schaltflächen aus dem "Innerern" einer HTML-Seite nicht direkt erreicht werden können: Der Benutzer muß zunächst an den Anfang oder ans Ende einer Seite springen, um sie benutzen zu können. Sinnvoller erscheint uns hier die Entwicklung einer sogenannten Frame-Struktur, einer Aufteilung des Browser-Fensters in autonome Bereiche. In einem Bereich könnten dauerhaft die Schaltflächen dargestellt werden, während in einem zweiten, größeren Bereich der eigentliche Seiteninhalt dargestellt wird. Durch die Positionierung der Schaltflächen in einem selbständigen Frame wären sie dann ständig erreichbar.
Problematisch ist hier aber die Tatsache, daß die Schaltflächen kontextsensitiv wirken, also nicht auf allen Seiten dieselbe Wirkung haben. Um z.B. zum nächsten Kapitel springen zu können, kommt es natürlich darauf an, in welchem Kapitel man sich gerade befindet. In HTML können die Sprungziele von Links allerdings nicht berechnet werden, sie müssen konkret spezifiziert werden. So müsste also für jedes Kapitel (also für jede HTML-Seite) eine neue Frame-Struktur mit Schaltflächen nur für dieses Kapitel angelegt werden. Ein solches redundantes Vorgehen ist aber nicht Sinn und Zweck der Verwendung von Frames.
Die Lösung dieses Problems scheint uns als Java-Applet einfach realisierbar zu sein: Der Frame enthält ein Java-Applet, das lediglich die Navigationsschaltflächen darstellt und verwaltet (für den Benutzer also völlig transparent ist). Das Applet liest die Gliederung des gesamten Buches aus einer Datenstruktur aus und kann somit im Dokument navigieren: Es "weiß" ständig, wo es sich gerade befindet und kann somit zu jedem Zeitpunkt Aussagen wie „Springe zum nächsten "Unterkapitel" oder "Springe zum nächsten Hauptkapitel" korrekt interpretieren und entsprechende Sprungziele berechnen. Mit größerem Aufwand ließe sich das Buch durch Java-Applets auch interaktiv gestalten: Denkbar sind hier Applets zur Simulation von Turing-Maschinen oder als geschützte Umgebungen zur Simulation von Computerviren.
Stand: 12.12.96
* Dieses Buch wurde am Lehrstuhl Informatik 5 der RTWH Aachen bearbeitet.