RTB Nord – P5.1: „Online-Dokumente“

Transcription

Abschlußbericht
Abschlußbericht
Version 1.0, 4. April 1997
Regionales Rechenzentrum für Niedersachsen (RRZN) /
Lehrgebiet Rechnernetze und Verteilte Systeme (RVS)
Prof. Dr.-Ing. Helmut Pralle
Universität Hannover
1
2
3
4
5
6
Inhalt
Bezeichnung des Projektes
Beschreibung des Projektes
2.1 Motivation
2.2 Projektziel
Durchführung des Projektes
3.1 Personal
3.2 Investitionen
3.3 Aufträge
3.4 Studien- und Diplomarbeiten
3.5 Vorträge, Veröffentlichungen, DFN-Arbeitskreis
3.6 Video-Konferenzen
3.7 Nutzung existierender Basisdienste und Software-Tools
Ergebnisse des Projektes
4.1 Methoden und Werkzeuge
4.1.1 PaperMaker
4.1.2 DocShow
4.1.3 Integration relationaler Datenbanken ins WWW
4.2 Anwendungsszenarien
4.2.1 Elektronisierte Tageszeitung: Neue Hannoversche Presse
4.2.2 Elektronische Zeitschrift mit Mehrwertdiensten: DFN-Mitteilungen
4.2.3 Abbildungen wertvoller Unikate: Virtuelle Galerie Kö 24, Codex Madrid I
4.2.4 Virtuelle 3D-Welten: Stadtspaziergang Hannover
4.3 Studien
Zusammenfassung und Ausblick
Anhang
Zur Diskrepanz der Auflösung verschiedener Präsentationsmedien
Urheberrechtliche Probleme im Internet
2
2
2
3
4
4
4
5
5
6
6
7
8
8
8
14
20
21
21
26
32
33
35
36
37
Das Vorhaben wurde aus Mitteln des Bundesministeriums für Bildung, Wissenschaft, Forschung und
Technologie (BMBF) durch den Verein zur Förderung eines Deutschen Forschungsnetzes e. V. (DFNVerein) finanziert.
1
Abschlußbericht
1
Projekttitel:
Online-Dokumente
Kurztitel:
RTB Nord – P5.1
Ansprechpartner:
Stephan Olbrich
Regionales Rechenzentrum für Niedersachsen (RRZN)/
Lehrgebiet Rechnernetze und Verteilte Systeme (RVS),
Universität Hannover (Leiter: Prof. Dr.-Ing. Helmut Pralle)
Teilnehmende Einrichtungen: RRZN/RVS, Universität Hannover
2
2.1
Kooperationen:
Deutsches Klimarechenzentrum (DKRZ), Hamburg
Springer-Verlag, Heidelberg
Verein zur Förderung eines Deutschen Forschungsnetzes e. V. (DFN), Berlin
Verlagsgesellschaft Madsack (VGM), Hannover
Projektlaufzeit:
27 Monate (01.10.1994 – 31.12.1996)
Motivation
Weite Bereiche der heutigen Gesellschaft stützen sich auf die Grundprinzipien Konkurrenz und
Kooperation, welche besonders für marktwirtschaftliche Prozesse, aber auch im Wissenschaftsbereich,
relevant sind. Als notwendige Basis hierfür wird die ausreichende Verfügbarkeit aktueller Informationen sowie komfortabler Kommunikationssysteme angesehen. Ursprünglich aus dem Wissenschaftsbereich sind Infrastruktur und Werkzeuge entstanden, welche geeignet sind, derartige Anforderungen
mit Hilfe verteilter elektronischer Informationssysteme zu erfüllen.
Dazu stehen auf den jeweils betroffenen Schichten verschiedene Ausprägungen für eine breite Nutzung bereit:
•
•
•
•
Netz-Infrastruktur: Internet, Deutsches Wissenschaftsnetz und weitere Provider
Protokolle: IP (Internet Protocol) bzw. aufsetzende, z. B. TCP/UDP
Dienste: z. B. WWW-Server für verteilte Multimedia-Informationssysteme
Anwendungen: z. B. WWW-Browser
Das einfache, aber komfortable generische Konzept, die breite Verfügbarkeit sowie die stark zunehmende Verbreitung des World Wide Web (WWW) haben bereits bei Antragstellung des Projekts die
strategische Bedeutung WWW-basierter multimedialer Informationssysteme erkennen lassen. Diese
auf Internet-Standards aufbauende Technologie wurde daher als wesentliche Grundlage für die Erörterung der offensichtlich vorliegenden vielfältigen Probleme des Online-Publishings betrachtet. Diese
betreffen beispielsweise Aspekte
•
•
•
•
•
technischer,
organisatorischer,
rechtlicher,
ökonomischer und
gestalterischer
Art.
Voraussetzung für eine qualitativ hochwertige Präsentation entfernt gespeicherter Multimedia-Dokumente ist jedoch aufgrund relativ hoher Datenvolumina und der Forderung möglichst kurzer Reaktionszeiten eine breitbandige Netzinfrastruktur. Daher wurde die Erprobung einer derartige Anwendung
im Weitverkehrsbereich erst durch den Aufbau der Regionalen Testbeds im DFN (RTBs) bzw. dem
letztlich daraus entstehenden Breitband-Wissenschaftsnetz (B-WiN) möglich.
2
Abschlußbericht
2.2
Projektziel
Mit dem Projekt sollte ein Beitrag zum Zugang und zur Gestaltung von Informationsangeboten in
Breitbandnetzen – i. w. für den Wissenschaftsbereich – geleistet werden. Um dieses globale Ziel aus
technischer Sicht zu erreichen, mußten pilothafte Szenarien entwickelt und in entsprechenden exemplarischen Anwendungen erprobt werden. Aufgrund der bei Projektplanung vorliegenden Aussagen
der Verlage, das Layout dürfe bei einer Online-Präsentation nicht verändert werden, wurde besonderer
Wert auf die Berücksichtigung des „Buch-Paradigmas“ gelegt.
Die Behandlung von Fragestellungen nicht-technischer Art war mittels separater Studien beabsichtigt.
Im einzelnen handelte es sich um die folgenden Bereiche:
• Exemplarische Anwendungen
– „Elektronisierte“ Tageszeitung: Neue Hannoversche Presse,
in Kooperation mit der Verlagsgesellschaft Madsack (Hannover)
– Elektronische Zeitschriften: DFN-Mitteilungen,
in Kooperation mit dem DFN-Verein (Berlin);
wissenschaftliche Zeitschriften, in Kooperation
mit dem Springer-Verlag (Heidelberg)
– Online-Präsentation von Unikat-Abbildungen:
Virtuelle Galerie Kö 24, in Kooperation mit dem
Galeristen Robert Simon (Hannover) sowie der
Fachhochschule Hannover, Fachbereich Kunst und Design;
Leonardo da Vinci, Codex Madrid I, in Kooperation
mit der Technischen Informationsbibliothek (TIB, Universität Hannover)
Virtueller Stadtrundgang durch Hannover, in Kooperation
mit dem Fotografen Hassan Mahramzadeh (Hannover)
• (Weiter-)Entwicklung von Werkzeugen, um in den o. g. Anwendungen eingesetzt zu werden
– DocShow: Client/Server-System zur Betrachtung
von Rasterbildern und virtuellen 3D-Objekten
– PaperMaker: Automatische Aufbereitung von Dokumenten im PostScript- bzw. PDF-Format in WWW- bzw. DocShow-orientierten Seitenaufbau
– Integration relationaler Datenbanken ins WWW
• Studien
– Urheberrechtliche Probleme im Internet
– Diskrepanz der Bildauflösung verschiedener Präsentationsmedien
– Internet-Dienste für den kommerziellen Einsatz
– Anwendung des SGML-Standards im WWW-Kontext
• Gewinn an Erkenntnissen und Erfahrungen auf den Gebieten
– Prozeßketten zur Verarbeitung und Online-Bereitstellung multimedialer Objekte
– Integration relationaler Datenbanken ins WWW
– Mehrwertdienste für WWW-basierte Dokumente
– Anwendungsgesichtspunkte zur Gestaltung virtueller Welten im Internet
3
Abschlußbericht
3
3.1
Personal
An dem Projekt waren die folgenden Personen beteiligt:
• Projektleitung
– Prof. Dr.-Ing. Helmut Pralle
• Wissenschaftliche Mitarbeiter
– Dipl.-Ing. Alexander von Berg
– Dipl.-Ing. Bernd Böker
– Dipl.-Ing. Christian Grimm
– Dipl.-Ing. Lutz Grüneberg
– Dipl.-Ing. Steffen Heinze
– Dr.-Ing. Fritz Hüsemann
– Dipl.-Ing. Stephan Olbrich (Projektleitung)
– Dipl.-Math. Gerd Schramme
• Designerin
– Dipl.-Des. (FH) Yvonne Scherzer
• Wissenschaftliche Hilfskräfte
– Arndt Grutke
– Christoph Nocula
3.2
Investitionen
Zur Durchführung des Projektes wurden die folgenden Investitionen getätigt:
Hardware
1. WWW- und Datenbank-Server (UNIX): Silicon Graphics (SGI) Challenge L, 2 Prozessoren 200
MHz R4400, ATM-Interface, 512 MB Hauptspeicher, 2 GB Systemdisk, CDROM- und DATLaufwerke, 12 x 9 GB Festplattenerweiterung, Varsity Development Software.
2. Arbeitsplatzrechner (UNIX-Workstation): Silicon Graphics (SGI) Indy 133 MHz R4600, 24bitGraphik, 20“-Farbmonitor, 64 MB Hauptspeicher, 1 GB Systemdisk, Varsity Development Software.
3. Scan-Arbeitsplatz (PowerMac): Apple PowerPC 7500/100, 20“-Farbmonitor, 72 MB Hauptspeicher, 500 MB Systemdisk, 4 GB Festplattenerweiterung, Kleinbild-Diascanner Nikon Supercoolscan LS 1000 incl. Feeder.
Software
1. Adobe Illustrator und Photoshop für SGI IRIX und Apple PowerMac
2. Adobe Acrobat für Apple PowerMac
3. QuarkXPress für Apple PowerMac
4. Softimage für SGI IRIX
5. ORACLE-Datenbank für SGI IRIX
6. Rogue Wave DBTOOLS.H++ Datenbank-Klassenbibliothek für SGI IRIX
4
Abschlußbericht
3.3
Aufträge
1. Herr Dipl.-Ing. Hassan Mahramzadeh (Hannover) wurde beauftragt, Kunstobjekte aus dem Privatbesitz des Galeristen Robert Simon (Hannover) zu photographieren.
2. Firma Gauditz (Hannover) wurde beauftragt, im Mittelformat (60mm x 70mm) vorliegende Diapositive auf einem Trommelscanner einzuscannen.
3. Frau Maja Leuchtenberger (Berlin) wurde beauftragt, ein Einstiegslayout für die Präsentation
auf der CeBIT 1995 zu entwerfen.
4. Frau Dipl.-Des. Yvonne Scherzer (Hannover) wurde beauftragt, Oberflächenentwürfe zur
Gestaltung von WWW-Einstiegsseiten zu erstellen.
5. Herr Dr. Andreas Wiebe (Hannover) wurde beauftragt, die Studie „Urheberrechtliche Probleme
im Internet“ – ein unveröffentlichtes Manuskript des Vortrags auf der Sitzung des DFN-Arbeitskreises „Informationsdienste“ am 22.04.1996 in Berlin – zu erstellen.
3.4
Studien- und Diplomarbeiten
Im Rahmen des Projektes wurde eine Reihe von Studien- und Diplomarbeiten angefertigt:
• Studienarbeiten
– Grutke, A.: „Kö 24 – Eine Virtuelle Galerie“, Fachhochschule Hannover, Fachbereich
Kunst und Design, 1996.
(http://www.rtb-nord.uni-hannover.de/onlinedokumente/projekte/T-StudieKoe24.html)
– Leonhardt, C.: „Datenbank-basierte Mehrwertdienste im Online-Publishing“, RRZN/RVS,
1996.
(http://www.rvs.uni-hannover.de/arbeiten/studien/sa-cleonhardt.html)
– Nebel, M.: „Diskussion eines Konzepts zur Online-Bereitstellung von Dokumenten“,
RRZN/RVS, 1995.
(http://www.rvs.uni-hannover.de/arbeiten/studien/sa-mnebel.html)
– Wolpers, M.: „Aufbereitung von SGML-Dokumenten für das Online-Publishing“, RRZN/
RVS, 1995.
(http://www.rvs.uni-hannover.de/arbeiten/studien/sa-mwolpers.html)
– Schütte, L.: „Kommerzielle Dienste und elektronisches Geld: Eine aktuelle Übersicht“,
RRZN/RVS, 1995.
(http://www.rvs.uni-hannover.de/arbeiten/studien/sa-lschuette.html)
• Diplomarbeiten
– Gsuck, T.: „Online Publishing: Modellierung und Bewertung von Konzepten für die Bereitstellung von hypermedialen Dokumenten“, RRZN/RVS, 1995.
(http://www.rvs.uni-hannover.de/arbeiten/diplom/da-tgsuck.html)
– Schütte, L.: „Modellierung eines Multimedia-Document Delivery Systems“, RRZN/RVS,
1996.
(http://www.rvs.uni-hannover.de/arbeiten/diplom/da-lschuette.html)
5
Abschlußbericht
3.5
Vorträge, Veröffentlichungen, DFN-Arbeitskreis
Teilergebnisse des Projekts wurden wie folgt präsentiert:
Vorträge
• Olbrich, S.: P5.1-Zwischenberichte auf den RTB-Nord-Treffen.
• Olbrich, S.: „RTB Nord: P5.1 – Onlinedokumente“, 1. Treffen des DFN-Arbeitskreises Informationsdienste im Rahmen des HDN-Symposiums, 06.12.1995, Berlin.
(http://www.rtb-nord.uni-hannover.de/veroeffentlichungen/HDN-Symposium.html)
• Olbrich, S.: „Virtuelle Welten im Internet“, CeBIT 1996,
„Treffpunkt 22 – Wirtschaft trifft Forschung“, 19.03.1996.
(http://www.rtb-nord.uni-hannover.de/veroeffentlichungen/CeBIT96.html)
• Pralle, H.: „Aspekte des elektronischen Publizierens – Network Publishing“,
9. DFN-Fachtagung über Rechnernetze, 1995, Bad Honnef.
Veröffentlichungen
• Olbrich, S., Pralle, H., Grüneberg, L.: „Anforderungen an eine Client/Server-Konfiguration für
das ‚Online-Publishing‘“,
Tagungsband zur 3. GI/ITG-Fachtagung „Arbeitsplatz-Rechensysteme“, Mai 1995, Hannover.
(http://www.rtb-nord.uni-hannover.de/onlinedokumente/articles/APS95/)
• Olbrich, S., Pralle, H.: „Multimedia-Dokumente – Online-Dokumente im RTB Nord“,
DFN-Mitteilungen 39, November 1995.
(http://www.rtb-nord.uni-hannover.de/dfn/mitteilungen/html/heft41/S9/S9.html)
• Scherzer, Y.: „Virtuelle Welten – Navigation in virtuellen Räumen“,
DFN-Mitteilungen 41, Juni 1996.
(http://www.rtb-nord.uni-hannover.de/dfn/mitteilungen/html/heft39/A2/A2.html)
CeBIT 1995
• RRZN/RVS-Präsentation auf dem Gemeinschaftsstand der Niedersächsischen Hochschulen:
„Online-Dokumente“.
CeBIT 1996
• RRZN/RVS-Präsentation auf den Ständen des DFN-Vereins und des BMBF:
– „Online-Publikation von Zeitungen und Zeitschriften im Internet“
(Neue Hannoversche Presse, DFN-Mitteilungen, etc.)
– „Virtuelle Welten im Internet“
(Galerie Kö24, Stadtspaziergang Hannover, etc., incl. Vortrag)
– „Upload und Abfrage von attributierten Bilddaten“
(Ablage auf einem WWW-Server mittels ORACLE-Datenbank –
erste Schritte auf dem Weg zu einer Agentur für Multimedia-Dienste im Internet)
DFN-Arbeitskreis
• Das Sprecheramt des am 06.12.1995 in Berlin initiierten DFN-Arbeitskreises „Informationsdienste“ wurde von einem Projektmitarbeiter übernommen.
3.6
Video-Konferenzen
In Zusammenarbeit mit dem RTB-Nord-Projekt P6 „Multimediale Zusammenarbeit in der Klimaforschung“ wurden ca. alle zwei Wochen Videokonferenzen auf der Basis der MBONE-Werkzeuge
durchgeführt, um die Kooperation mit dem RTB-Projektpartner DKRZ zu fördern.
6
Abschlußbericht
3.7
Nutzung existierender Basisdienste und Software-Tools
Es wurden u. a. folgende Komponenten eingesetzt:
• Basisdienste
– FTP-Client/Server
– WWW-Clients: Netscape Navigator, Microsoft Explorer und Mosaic
– WWW-Server: NCSA-httpd und Apache-httpd, incl. PHP/FI-Modul
• Public-Domain-Software (zuletzt verwendete Version)
– Aladdin Ghostscript (4.03)
– ImageMagick (3.7.2)
– Netpbm-Tools (1mar1994)
– Independent JPEG Group‘s JPEG-Software (6)
– Sam Leffler‘s TIFF-Tools (3.4beta018)
– Mapedit (2.24)
• Kommerzielle Software
– Adobe: Photoshop, Illustrator, Acrobat
– ORACLE-Datenbank
– QuarkXPress
– Rogue Wave DBTOOLS.H++; generische Klassenbibliothek als Interface zu ORACLE
– Silicon Graphics WebSpaceAuthor; VRML-Modellierer und -Konverter
– Softimage; Modellierungs- und Renderingsoftware
• RRZN/RVS-Entwicklungen
– PaperMaker (siehe Kap. 4.1.1)
– DocShow/DocServ (siehe Kap. 4.1.2)
– ORACLE-Interface für PHP/FI als Apache-Modul (siehe Kap. 4.1.3)
7
Abschlußbericht
4
4.1
4.1.1
Methoden und Werkzeuge
PaperMaker
Ein interaktives Werkzeug zur Erzeugung von WWW-Präsentationen
aus PostScript- und PDF-Dateien
4.1.1.1 Einleitung
PaperMaker ist ein System zur Generierung von HTML-Präsentationen aus Postscript- und PDFDateien. Das Postscript- oder PDF-Dokument wird von PaperMaker seitenweise in Rasterbilder
umgewandelt. Diese Rasterbilder werden einzeln auf HTML-Seiten zusammen mit Schaltflächen zur
Navigation dargestellt. Die Steuerung übernimmt ein CGI-Skript, das von PaperMaker automatisch
erzeugt wird. Der Betrachter dieser Präsentation kann sich Seite für Seite durch das Dokument klicken
oder gezielt eine Seite auswählen. Die Rasterbilder sind mit sensitiven Flächen belegt, so daß auch
direktes Anklicken der Seitenränder ein Umblättern bewirkt. Die Auflösung und die Größe der Rasterbilder können vom Benutzer gewählt werden.
PaperMaker ist ein Produkt der Arbeiten zum Projekt P5.1 „Online-Dokumente“ des RTB Nord1. Ein
Arbeitspunkt dieses Projekts ist die Untersuchung und Entwicklung von Produktionsketten zur automatischen Erzeugung von Hyper-Dokumenten. Der Umwandlung von Postscript- und PDF- in HyperDokumente kommt hierbei besondere Bedeutung zu, da diese beiden Formate weit verbreitet sind.
4.1.1.2 Motivation, Vor- und Nachteile
Die Darstellung von Dokumentseiten als Rasterbilder ist für Online-Archive als Ergänzung zur Hypertext-/Hypermedia-Version sinnvoll, um das Erscheinungsbild der Druckausgabe zu präsentieren. Den
gleichen Zweck können Postscript- und PDF-Versionen der Druckausgabe erfüllen, doch die Rasterbild-Variante hat einige Vorteile, weshalb Raster- und Vektorformate gemeinsam angeboten werden
sollten.
So ist bei Darstellung einer Postscript-Seite am Bildschirm ohnehin eine Rasterung notwendig. Diese
kann also schon vorher erfolgen. Ein Rasterbild kann in der Regel auf jedem Zielsystem dargestellt
werden, während ein Postscript-Interpreter nicht immer zur Verfügung steht. Zusätzlich sind bei Postscript noch die Schriften erforderlich. Diese müssen entweder mitgeliefert werden oder auf jedem
Zielsystem vorhanden sein. Daher können Rasterbilder erheblich schneller zur Anzeige gebracht werden. Wichtig für das Echtzeitverhalten der Präsentation ist, daß beim Blättern eine Obergrenze der
Reaktionszeit eingehalten wird. Dies ist bei Postscript und PDF nicht der Fall, da der Zeitbedarf für
die Rasterung vom Inhalt der Seite abhängig ist. Rasterbilder mit derselben Pixelgröße und Farbtiefe
dagegen können immer innerhalb einer festen maximalen Zeitspanne auf dem Bildschirm angezeigt
werden. Die Nachteile der Rasterdarstellung sind allerdings, daß die Seiten nicht skalierbar sind und
daß die Textinformationen und damit die Möglichkeit, nach Begriffen zu suchen, verloren gehen.
Tabelle 1 faßt die Vor- und Nachteile zusammen.
Eigenschaft
PS
PDF
Rasterbild
Zeitbedarf für Bildaufbau
hoch/nicht konstant
geringa/nicht konstant
gering/konstant
Verbreitung von Software
zur Bildschirmdarstellung
gering
gering
hoch
Tabelle 1: Vor- und Nachteile unterschiedlicher Formate
1. URL: http://www.rtb-nord.uni-hannover.de/
8
Abschlußbericht
Eigenschaft
PS
PDF
Rasterbild
Bild skalierbar
ja
ja
nein
Textsuche möglich
nein
ja
nein
Hyper-Links
nein
ja
bedingtb
Tabelle 1: Vor- und Nachteile unterschiedlicher Formate
a.bei hohem Textanteil, bzw. bei auflösungsreduzierten Bildern
b.bei Darstellung in HTML-Dokumenten durch Imagemaps realisierbar
4.1.1.3 Anforderungen
Ziel ist die Erstellung von Online-Dokumenten. Die Rasterbilder stehen also nicht für sich, sondern
bilden ein Dokument. Das Online-Dokument soll der Druckausgabe qualitativ möglichst nahekommen, um beim Benutzer eine hohe Akzeptanz zu erreichen. Die entstehende Präsentation muß aus diesem Grund ähnliche Eigenschaften aufweisen wie ein herkömmliches gedrucktes Dokument. Diese
Eigenschaften betreffen sowohl Inhalt und Darstellung der Präsentation, als auch die Funktionalität
und die Bedienung. Die Forderung nach identischen Inhalten ist am leichtesten zu erfüllen. Eine äquivalente Darstellung der Seiten auf dem Bildschirm bedingt eine hinreichend hohe Auflösung bei der
Rasterung zur Vermeidung von Aliasing-Effekten (siehe „Zwischenprodukt Echtfarb-PPM / Antialiasing“ auf Seite 12). Zu den wichtigsten funktionalen Eigenschaften gehören die Möglichkeiten, seitenweise in Echtzeit zu blättern und zu einer bestimmten Seite sowie zum Anfang, bzw. Ende des
Dokuments zu springen. Die Summe dieser aller Anforderungen läßt sich unter dem Begriff „BuchParadigma“ zusammenfassen1.
4.1.1.4 Systemarchitektur
PaperMaker besteht aus einem WWW-Interface, das auf HTML-Forms basiert, und zwei Skripten.
Das CGI-Skript papermaker.cgi steuert den Gesamtablauf, interpretiert die Form-Befehle und berechnet Anfangswerte. Das Skript pdfps2html nimmt die eigentliche Umwandlung der Eingangsdaten vor
und generiert das Steuerskript paper.cgi für die Präsentation, siehe Bild 1. Für jede Seite des Eingangsdokuments werden je eine TIFF- und zwei GIF-Dateien, eine im Originalformat, eine im IconFormat, erzeugt. Die TIFF-Dateien können mittels des Image-Viewers DocShow betrachtet werden.
Die GIF-Dateien im Originalformat werden für die HTML-Präsentation verwendet, die GIF-Dateien
im Icon-Format für die Seitenübersicht.
Zusätzlich zu den Skripten sind verschiedene externe Programme notwendig, z. B. ein PostscriptInterpreter und Bildverarbeitungsprogramme zur Konvertierung und Skalierung der Bilddaten. Die
gesamte Verarbeitung findet auf dem WWW-Server statt. Es ist nicht möglich, Postscript-Dateien auf
entfernten Rechnern zu bearbeiten. Die Bedienung von PaperMaker ist jedoch durch das WWW-Interface von beliebigen Rechnern aus möglich. Da mit PaperMaker ein Zugriff auf das lokale Dateisystem
des Web-Servers möglich ist, ist die Benutzung durch ein Paßwort geschützt.
4.1.1.5 Implementierung und eingesetzte Software
Bei den Skripten handelt es sich um Shell-Skripte. Zur Konvertierung und Bearbeitung der Bilddateien
werden folgende Programme eingesetzt:
•
•
•
•
Aladdin Ghostscript (Version 3.33 bis Version 4.03) mit Postscript-Schriften (Type1)
ImageMagick-Tools (Version 3.6.5): convert, identify
Netpbm-Tools (Version 1mar1994): pnmscale
Mapedit
1. RTB Nord Projekt P5.1 „Online-Dokumente“ – Feinspezifikation, Version 3.3,
Prof. Dr.-Ing. H. Pralle, Universität Hannover, Juli 1994.
9
Abschlußbericht
papermaker.cgi
PDF/PS-Datei
ruft auf
ruft auf
ruft auf
paper.cgi
pdfps2html
page.*.icon.gif
erzeugt
page.*.gif
Browser
page.*.tiff
HTML-Präsentation
Bild 1: Systemarchitektur von PaperMaker
4.1.1.6 Betrieb
PaperMaker wird über ein WWW-Interface gesteuert. Nach Aufruf der URL erscheint ein Dialog mit
einem File-Browser. Im erstem Schritt ist eine Postscript- oder PDF-Datei auszuwählen. Vor der Verarbeitung des gesamten Dokuments kann durch Drücken der Preview-Taste eine Vorschau der ersten
Seite erzeugt werden. Anhand des Ergebnisses können Feineinstellungen der Auflösung und des
Overscans vorgenommen werden (Standardwerte sind 95 dpi und zweifacher Overscan).
Im Setup-Dialog (Bild 2) können folgende Parameter vor der Verarbeitung eingestellt werden:
•
•
•
•
•
•
•
•
•
•
•
Zielverzeichnis für die fertige HTML-Präsentation
Titel der fertigen HTML-Präsentation (HTML-Tag <TITLE>)
Anzahl der Seiten
Index-/Inhaltsverzeichnis-Seite
Bounding-Box
Auflösung
Overscan
Skalierung
Orientierung (Portrait oder Landscape)
Drehung um 180 Grad
optionale Erzeugung von TIFF-Dateien
Während der Verarbeitung werden in regelmäßigen Abständen Zwischenergebnisse angezeigt, d. h.
die Icon-Version jeder konvertierten Seite wird dargestellt. So können Fehler bei der Konvertierung
frühzeitig erkannt werden.
Nach erfolgreicher Bearbeitung kann die erzeugte Präsentation über paper.cgi mit einem Web-Browser angesehen werden. Bild 3 zeigt exemplarisch eine Seite einer solchen Präsentation. Links oben und
rechts unten sind Schaltflächen zur Navigation angeordnet.
Die Seiten erhalten zunächst mit Hilfe von Client-Side-Maps sensitive Bereiche zum seitenweisen
Blättern und zum Springen auf die Inhaltsverzeichnisseite. Auf der Inhaltsverzeichnisseite können mit
dem Programm mapedit zusätzliche sensitive Bereiche für die Einträge des Inhaltsverzeichnisses
10
Abschlußbericht
Bild 2: Setup-Dialog von PaperMaker
Bild 3: Hyper-Dokument, erstellt mit PaperMaker
angelegt werden, so daß ein direktes Verzweigen zu allen Kapiteln möglich wird. Dieser Arbeitsschritt
läßt sich bisher nicht automatisieren, ist aber auch nicht für jedes Dokument erforderlich.
4.1.1.7 Erfahrungen bei der Postscript/Raster-Konvertierung
Interpreter
Als Postscript-Interpreter kommt Aladdin Ghostscript zum Einsatz. Die aktuelle Version ist 4.03.
Ghostscript wurde nach Vergleichen mit anderen Interpretern (z. B. Freedom of Press, Impressario)
ausgewählt, da Ghostscript folgende Vorteile aufweist:
11
Abschlußbericht
• Unterstützung aller Plattformen
• Freie Verfügbarkeit im Quelltext
• Offene Programmier- und Datei-Schnittstellen für Erweiterungen (z. B. für Fonts und AusgabeTreiber)
• Stabilität und Funktionalität
• Verarbeitung von PDF (ab Version 3.33)
• Erzeugung von PDF (ab Version 4.00)
Als Nachteil fiel bei Ghostscript zunächst die schlechte Schriftqualität auf. Dieser Nachteil ist jedoch
durch ausschließliche Verwendung von Type1-Schriften (Postscript, ASCII und binär) vollständig zu
beheben, so daß einer Nutzung von Ghostscript nichts im Wege steht. Mittlerweile werden auch
Type1-Schriften zur freien Verwendung mitgeliefert.
Zwischenprodukt Echtfarb-PPM / Antialiasing
Die Wahl der Auflösung des gerasterten Bildes ist abhängig von der Auflösung des Bildschirms. Heute
übliche 20-Zoll-Bildschirme haben eine Auflösung von ca. 95 dpi. Für eine Darstellung in Originalgröße muß das Bild also mit 95 dpi gerastert werden. Bild 4 (links) zeigt jedoch, daß bei einfacher
Rasterung mit Ghostscript, insbesondere bei Text, Treppenstufen entstehen. Bild 5 (oben) macht deutlich, daß durch diesen Effekt gerade kleine Schriften unlesbar werden. Um dies zu verhindern, wurde
ein mehrstufiges Rasterverfahren mit Overscan gewählt.
95 dpi, kein Overscan
95 dpi, 2-facher O.S.
Bild 4: Auswirkung des Overscans, vergrößerte Darstellungm (24-pt-Schrift)
Ghostscript erzeugt zunächst mit dem Ausgabe-Device ppmraw eine PPM-Datei mit mehrfacher Auflösung entsprechend dem Overscan-Faktor. Dieses Bild wird mit pnmscale wieder auf die gewünschte
Auflösung reduziert. Dabei wird der Farbwert eines neuen Bildpunkts entsprechend dem Gesamtfarbwert der ursprünglichen Bildpunkte gewählt. Bei zweifachem Overscan (entspricht doppelter Auflösung in x- und in y-Richtung) stehen pnmscale also für jeden neuen Bildpunkt vier ursprüngliche
Bildpunkte zur Verfügung (bei dreifachem Overscan 9), aus denen der Farbwert berechnet wird.
Dadurch wird die Darstellungsqualität erheblich verbessert, wie Bild 4 (Mitte und rechts) vergrößert
und Bild 5 (Mitte und unten) zeigen.
Dieses Verfahren bringt jedoch den Nachteil mit sich, daß große Schriften und gerade (senkrechte und
waagerechte) Linien und Kanten unscharf wirken. Ein weiterer Nachteil ist der höhere Zeitaufwand
für die Konvertierung.
Das nach diesen beiden Schritten entstandene Bild ist ein PPM-Bild mit 24 bit Farbtiefe. Aus diesem
PPM-Bild werden nun mit Hilfe des ImageMagick-Tools convert Bilder im TIFF- und GIF-Format
erzeugt.
4.1.1.8 Erfahrungen bei der PDF/Raster-Konvertierung
Grundsätzlich besteht im Ablauf der Konvertierung von PDF-Dateien in Rasterbilder kein Unterschied
zur Konvertierung von Postscript-Dateien. Ghostscript verarbeitet ab der Version 3.33 auch PDFDateien. Zu beachten ist bei PDF-Dateien, daß die Qualität der eingebundenen Bilder in der Regel
geringer ist, da bei der PDF-Erzeugung Bilddaten bereits in der Auflösung reduziert werden können
(z. B. Default bei Adobe Acrobat Distiller).
12
Abschlußbericht
95 dpi, kein Overscan
Bild 5: Auswirkung des Overscans, Schriften in Originalgröße
4.1.1.9 Bewertung
Die Postscript/Raster-Konvertierung und anschließende Generierung von Hyper-Dokumenten ist zu
einem hohen Grad automatisierbar. Lediglich zu Beginn sind bei Bedarf Parameter einzustellen bzw.
anzupassen. Das Ergebnis ist ein Verzeichnis mit Dateien, das ohne Änderungen in einen Web-Server
integriert werden kann. Die entstehenden Hyper-Dokumente sind nach dem „Buch-Paradigma“ aufgebaut. Es kann seitenweise vor und zurück geblättert werden, es kann zu einer bestimmten Seite
gesprungen werden, es gibt eine Seitenübersicht, und eine beliebige Seite kann als Inhaltsverzeichnisseite deklariert werden. Die Verwendung von sensitiven Bereichen auf den Seiten zum Blättern ist eine
wichtige Maßnahme, um dem Benutzer die Navigation im Hyper-Dokument zu erleichtern.
Wegen der fehlenden Textsuchmöglichkeit in den Rasterbildern ist diese Art von Hyper-Dokumenten
nur zu empfehlen, wenn der Textanteil im Dokument nicht zu hoch ist. Besonders für Vortragsfolien
ist dieses Verfahren sehr geeignet, da hier in der Regel ein geringer Text- und eine hoher Bildanteil
vorhanden ist. Auf dem Web-Server des RTB Nord sind einige Beispiele für Hyper-Dokumente, die
mit PaperMaker erzeugt wurden, abrufbar:
• http://www.rtb-nord.uni-hannover.de/veroeffentlichungen/CeBIT96.html
• http://www.rtb-nord.uni-hannover.de/veroeffentlichungen/HDN-Symposium.html
13
Abschlußbericht
4.1.2
DocShow
Ein effizientes Client/Server-System
zur Betrachtung von Rasterbildern und 3D-Objekten
4.1.2.1 Einleitung
Das aus den Komponenten DocShow, DocServ und DocMess bestehendende Programmpaket wurde
ursprünglich vom RRZN/RVS entwickelt, um einen anwendungsnahen Benchmark für breitbandige
Netze bereitzustellen. Es handelt sich dabei um ein Client/Server-System, welches auf Client-Seite
(DocShow) ein Nutzer-Interface zur Betrachtung von Rasterbildern bzw. 3D-Objekten anbietet, deren
Repräsentationen auf Server-Seite (DocServ) gespeichert sind. Eine Instrumentierung gestattet die
Messung verschiedener Leistungsparameter, die über das Meß-Interface DocMess angezeigt und abgespeichert werden können.
Vor Projektbeginn wurde die Software auf einer Silicon-Graphics-Workstation unter dem IRIXBetriebssystem mit X11/Motif-Oberfläche – optional mit Nutzung der IrisGL-Graphikschnittstelle –
als Prototyp mit Rasterbild-Funktionalität entwickelt.
4.1.2.2 Weiterentwicklung
Im Rahmen des Projektes wurde dieser Prototyp auf mehrere weitere UNIX-Plattformen portiert – HP/
UX, Linux, Solaris und SunOS, jeweils in verschiedenen Versionen – sowie an die in der Praxis auftretenden Anforderungen angepaßt. Dabei wurden bekannte Fehler behoben sowie Verbesserungen in
bezug auf Leistungsfähigkeit und Funktionalität durchgeführt. Zu letzteren gehören:
• Unterstützung weiterer Rasterbild-Dateiformate und Codierungsvarianten
– SEQ-Format aus dem AVS-Animator: „None“, „Runlength“, „Color Cell“ Compression.
– PBMPLUS-Formate: PBM (Bitmap), PGM (Graymap), PPM (Pixmap).
– TIFF-Formate, incl. LZW- (mit Predictor-Codierung) und JPEG-Kompression auf der Basis
der frei verfügbaren Bibliotheken „Sam Leffler‘s TIFF-Tools“ (Version 3.4beta018) und
„Independent JPEG Group‘s JPEG-Software“ (Version 6).
• Verbesserungen an der Nutzer-Oberfläche
– Vermeidung von Blockierungssituationen, z. B. während längerer Transfer-Phasen durch
Nutzung entsprechender X11/Xt-Schnittstellen zur Unterstützung von kooperativem Multitasking in der Applikation.
– Unterstützung des OpenGL-APIs, um eine breitere Plattform für die effizienten RasterbildAnzeige- bzw. die 3D-Rendering-Funktionen (s. u.) zu ermöglichen.
– Animations- bzw. „Blättern“-Funktion mittels entsprechender Buttons.
– „Save As“-Funktionen für Session-Liste als spezielle Scriptdatei und Einzelbilder als TIFF.
– Wahlmöglichkeiten zur Gestaltung der Oberfläche.
– Weitere Optionen bezüglich der Verwendung verschiendener Graphik-Schnittstellen (z. B.
X11 vs. IrisGL/OpenGL, Visuals: Pseudocolor/Truecolor, Dithering-Einstellungen) und
Zeitkonstanten für den progressiven Bildaufbau bzw. die Anzeige des Transfer-Fortschritts.
– Zusätzliche Kommandozeilen-Optionen.
• Optimierungsarbeiten
– Verbesserung des Interfaces zum WWW-Browser (z. B. Netscape): es wird jetzt nicht mehr
für jedes Dokument ein neuer DocShow-Prozeß gestartet, sondern die DocShow-Dokument-Adresse an ein bereits laufendes DocShow übergeben, welches dann seine SessionListe entsprechend erweitert und das angeforderte Dokument öffnet und zur Anzeige bringt.
– Erhöhung des Durchsatzes bei bestimmten Dateiformaten.
– Implementierung eines Cache mit LRU-Charakteristik.
– Implementierung einer Prefetch-Strategie, d. h. gemäß einer Vorhersage über die voraussichtlich als nächstes vom Benutzer angefragte Seite fordert DocShow diese optional spekulativ bereits im Hintergrund von DocServ an und überträgt diese in einen entsprechenden
Pufferbereich.
14
Abschlußbericht
• Erste Ansätze zur Unterstützung von 3D-Präsentationsmethoden
– Definition eines Dateiformats zur Codierung virtueller 3D-Szenen, das – im Gegensatz zum
Internet-Standard „Virtual Reality Modeling Language“ (VRML) – auf eine effiziente Verarbeitung und hohen Komfort im Kontext relativ hoher Bitraten und Leistungsfähigkeit der
Endgeräte ausgelegt ist.
– Konverter zur Generierung des o. g. Formats aus dem Viewperf1-Mesh-Format sowie einer
Teilmenge des Wavefront-OBJ-Formats.
– Effiziente Rendering-Funktion für Display-Listen gemäß o. g. Format.
– Unterstützung des Scene-Antialiasing mittels Multisampling zur Erzielung einer besseren
Bildqualität auf Maschinen, die dies unterstützen – z. B. Silicon Graphics Reality Engine2.
– DocShow-Navigationsfunktion für 3D-Szenen des o. g. Formats, die sowohl über eine
Maus, als auch mittels SpaceBall – bzw. kompatibler Geräte – bedient werden kann.
– „Stereo-View“-Funktionalität, d. h. 3D-Präsentation von Bildpaaren – z. B. aus je zwei
Photographien oder durch zwei Sichten auf eine virtuelle 3D-Szene (s. o.) – durch quasisimultane Darstellung auf Bildschirm oder Projektionssystem und Separierung mittels LCDShutterbrille. Die Implementierung dieser Funktionalität wurde zunächst auf der Basis von
IrisGL auf Silicon-Graphics-Workstations vorgenommen.
4.1.2.3 Anwendungen
Innerhalb des Projektes wurden mehrere Anwendungen von DocShow erprobt, und zwar aus den folgenden Bereichen:
• Präsentation einer Tageszeitung
– Neuen Hannoverschen Presse (siehe Kap. 4.2.1)
• Präsentation einer Zeitschrift
– DFN-Mitteilungen (siehe Kap. 4.2.2)
• Abbildungen wertvoller Unikate
– Leonardo da Vinci: „Codex Madrid I“ (siehe Kap. 4.2.3)
– Virtuelle Galerie: „Galerie Simon“2 bzw. „Kö 24“ (siehe Anhang)
Die jeweils aktuelle Version von DocShow/DocServ/DocMess wurde in Form von Binaries über den
RTB-Nord-WWW-Server mit Hilfe eines auszufüllenden Formulars3 verteilt.
4.1.2.4 Leistungsmessungen im lokalen Netz und im B-WiN
Mit DocShow/DocServ/DocMess (Version 1.37) wurden zwischen verschiedenen Client- und ServerMaschinen Leistungsmessungen durchgeführt. Die verwendeteten Rechner und an den Clients getesteten Graphikschnittstellen waren
(A) atmgate.dkrz.de (FDDI-Interface, DKRZ)
Sun Sparc 10, Solaris 2.5
(B) rtb-www.rrzn.uni-hannover.de (ATM-Interface, RRZN/RVS)
SGI Challenge L (2xR4400, 200 MHz), IRIX 6.2
(C) rtb-video.rrzn.uni-hannover.de (ATM-Interface, RRZN/RVS)
Sun Sparc 20/612, Solaris 2.4, 8bit-X-Display
(D) sgi210o.rrzn.uni-hannover.de (Ethernet-Interface, RRZN/RVS)
SGI Indigo2 Extreme (R4000, 100 MHz), IRIX 5.3, 24bit-GL-/8bit-X-Display
(E) atlantis-atm.rvs.uni-hannover.de (ATM-Interface, RRZN/RVS)
SGI Indigo2 Extreme (R4000, 100 MHz), IRIX 5.3, 24bit-GL-/8bit-X-Display
(F) onyx-atm.rrzn.uni-hannover.de (ATM-Interface, RRZN/RVS)
SGI Onyx Reality Engine2 (2xR4400, 200 MHz), IRIX 5.3, 24bit-GL-/8bit-X-Display
1. Viewperf ist ein OpenGL-Performance-Benchmark (siehe http://www.specbench.org/gpc/opc.static/).
Für Leistungsmessungen werden 3D-Szenen aus typischen Anwendungen verwendet, die dazu in sogenannten „Viewsets“ u. a. in einem speziellen Triangle-Mesh-Format codiert bereitgestellt werden.
2. Siehe auch http://cebit95.rvs.uni-hannover.de/galerie_simon/
3. http://www.rtb-nord.uni-hannover.de/onlinedokumente/dist/docshow/
15
Abschlußbericht
Als Bildmaterial wurden mehrere Rasterbilder verwendet, die durch Scannen mit einem 400-dpiFlachbettscanner HP Deskscan II cx an einer SGI Indigo2 aus einem Facsimile-Druck von Leonardo
da Vincis „Codex Madrid I“ erzeugt wurden (siehe auch Kap. 4.2.3). Bei den im folgenden dargestellten Messungen wurde die Ausgangsdatei 11(Kettenarten).tiff verwendet.
Diese wurde mit Hilfe der Rasterbild-Konvertierer aus netpbm-1mar1994 (pnmscale, pnmtotiff,
ppmtopgm, pgmtopbm) und tiff-v3.4beta018 (tiffcp) auf 72 dpi (898x612 Pixel) skaliert und in verschiedene Zielformate konvertiert. In Bild 6 und Tabelle 2 sind Abbildungen und Eigenschaften der
verwendeten TIFF-Dateien dargestellt.
Bild 6: Abbildungen der verwendeten TIFF-Bilddateien
Nr.
Farbtiefe
[bit/pixel]
Dateigröße
[bytes]
Transfervolumen
[bytes]
Kompression
Rows/Strip
G4
72
20418
20199
G4
612 (d. h. 1 Strip)
20071
19862
3
–
72
69446
69228
4
–
612 (d. h. 1 Strip)
69373
69164
5
JPEG
16
96336
95466
JPEG
612 (d. h. 1 Strip)
94580
93718
7
–
3
1650584
1650360
8
–
612 (d. h. 1 Strip)
1648951
1648736
1
2
1
6
24
Tabelle 2: Eigenschaften der verwendeten TIFF-Bilddateien
DocShow wurde für die Messungen wie folgt konfiguriert: ExposeInterval=2500, UpdatePageNumber=No, DisplayStatus=No, DoubleBuffer=No, XImageInterface=Socket, Dithering=Yes, GL-TrueColor-Depth=32 bit (ABGR), Gamma=1.0 auf SGI- bzw. Gamma=1.7 auf Sun-Plattformen. Es
wurden Messungen in den Server-Client-Kombinationen A-C, A-D, A-E, A-F, B-C, B-D, B-E und BF durchgeführt.
In Tabelle 3 sind einige typische Ergebnisse für A-F und B-F aufgeführt, die unter günstigen Bedingungen – bzgl. des Netzverkehrs und der Last auf den beteiligten Rechnern – erzielt wurden.
16
Abschlußbericht
Client
Server
Sequ.
Convert
Farbtiefe
Typ
[bit/pixel]
Startup
[s]
Transport
[s]
[Mbps]
Decode, Convert
[s]
[Mbps]
1
0.010
0.076
2.12
2
0.010
0.052
1.94
3
0.009
0.042
13.00
4
0.011
0.045
12.39
5
0.012
0.646
1.18
6
0.014
0.648
1.16
7
0.010
0.834
15.82
A
8
0.010
0.942
14.00
(atmgate,
DKRZ)
1
0.011
0.016
9.81
0.063
2.57
2
0.010
0.015
10.53
0.062
2.54
3
0.010
0.041
13.38
0.005
118.26
4
0.009
0.040
13.71
0.005
119.45
5
0.013
0.059
12.91
0.665
1.15
6
0.012
0.051
14.82
0.660
1.14
7
0.010
0.823
16.12
0.155
85.16
8
0.010
0.822
16.05
0.150
87.82
1
0.003
0.068
2.39
2
0.003
0.069
2.32
3
0.003
0.013
43.43
4
0.003
0.016
33.64
5
0.003
0.651
1.18
6
0.003
0.638
1.18
7
0.003
0.272
48.61
8
0.003
0.288
45.73
1
0.003
0.005
30.02
0.061
2.67
2
0.003
0.005
35.17
0.062
2.57
3
0.003
0.010
55.38
0.003
206.65
4
0.003
0.011
50.27
0.003
207.78
5
0.003
0.019
40.17
0.625
1.22
6
0.003
0.014
54.11
0.616
1.22
7
0.003
0.220
59.94
0.097
120.72
8
0.003
0.184
71.74
0.111
119.11
1
nein
24
Entfällt,da
Decodierung
und Konvertierung während
des Transfers
durchgeführt
wird.
1
Display
GL [s]
0.056
0.019
0.056
ja
24
F
(onyx-atm,
RRZN/
RVS)
0.019
1
nein
24
B
(rtb-www,
RRZN/
RVS)
Entfällt,da
Decodierung
und Konvertierung während
des Transfers
durchgeführt
wird.
1
0.056
0.019
0.056
ja
24
0.019
Tabelle 3: Einige DocShow/DocServ-Meßergebnisse für die Verkehrsbeziehungen A-F und B-F
Das Minimum für komprimierte/unkomprimierte bzw. 1bit/24bit-Darstellungen ist grau hinterlegt
17
Abschlußbericht
Diskussion der Meßergebnisse
Zunächst kann festgestellt werden, daß Abhängigkeiten bestehen zwischen der „Sequential Convert“Funktionalität, bei der erst nach der Übertragung sämtlicher „Strips“ die Konvertierung durchgeführt
wird, und der Stripanzahl, d. h. der Aufteilung des jeweiligen Bildes in Blöcke. Bilder mit mehreren
Strips werden mit ausgeschaltetem „Sequential Convert“ in der Regel effizienter übertragen und dargestellt, da jeweils während einer Dekodierungs- und Konvertierungsphase bereits die nächsten Daten
übertragen und über Betriebssystem-interne Puffer beim nächsten read-Systemcall relativ schnell
bereitgestellt werden können. Dies konnte bei entsprechenden Tests über Ethernet-Strecken noch deutlicher gezeigt werden.
Weiterhin wird auf die im Vergleich zur Echtfarb-Darstellung relativ langsame Bitmap-Darstellung im
RGB-Modus der GL hingewiesen. Die Anzeige von Bitmaps in X-Windows ist – insbesondere für
Pseudocolor-Visuals – schneller, dagegen sind RGB-Displays über die GL-Schnittstelle wesentlich
schneller als über X-Windows. Daher sind hier nur die GL-basierten Werte aufgeführt.
Tabelle 4 stellt für die verwendeten Formate jeweils die minimalen Gesamtzeiten, d. h. Summe aus
Startup, Transport, Decodierung und Konvertierung in die Bildschirmdarstellung (hier: ABGR-PixelAnordnung), dar.
Kompressionsmethode
RRZN – RRZN (B-F)
DKRZ – RRZN (A-F)
1 bit/pixel
24 bit/pixel
1 bit/pixel
24 bit/pixel
FAX/G4 bzw. JPEG
0.069
0.633
0.062
0.658
unkomprimiert
0.016
0.275
0.051
0.844
Tabelle 4: Minimale Gesamtzeiten (Transport, Decode, Convert) aus Tabelle 3 (in Sekunden)
Minimum je Spalte: grau hinterlegt
Aus dem hier betrachteten Szenario – relativ hohe verfügbare Bitraten, Dekompression in Software –
läßt sich schließen, daß der Einsatz von Kompressionsverfahren ab einer bestimmten Übertragungsdatenrate nicht mehr vorteilhaft ist. Zur Ermittlung dieser Grenzrate r G wird vom Ansatz ausgegangen,
daß sich die jeweilige gesamte Zeitdauer
T S ergibt aus der Summe aus Transportzeit und Decodier-
und Konvertier-Zeit (da Startup- und Display-Zeiten jeweils konstant sind):
TS = TT + TD
i
i
bzw. mit dem Datenvolumen
N i , der Transferrate r T und der Decodierrate r Di
Ni Ni
T S = ------ + -------- mit i=0 (ohne Kompression) bzw. i=1 (mit Kompression).
rT rD
i
i
Ni
TD
i
Ni
r D = ---------TD
i
i
Ohne Kompression: i=0
Mit Kompression (JPEG): i=1
1.650.360 Bytes
95.466 Bytes
0,097 s
0,616 s
120,72 Mbit/s
1,22 Mbit/s
Tabelle 5: Charakteristische Konstanten für das verwendete Farb-Rasterbild
18
Abschlußbericht
Aus den vorangegangen Tabellen ergeben sich für den vorliegenden Datensatz und dem hier verwendeten Client-Rechner die in Tabelle 5 aufgeführten charakteristischen Konstanten. Der Zusammenhang zwischen Transferrate r T und Gesamtzeit T S und dieser Randbedingung ist in Bild 7
i
graphisch dargestellt.
0.5
Kompressionsverfahren
JPEG-Kompression
ohne Kompression
Gesamtzeit TS [s] ->
0.4
0.3
0.2
0.1
0.0
0
10
20
30
40
50
Transferrate rT [Mbps] ->
Bild 7: Gesamtzeit (Transport, Decodierung, Konvertierung) in Abhängigkeit von der Transferrate
Die Grenzrate r G , also der Schnittpunkte der beiden Kurven in Bild 7, kann durch den Ansatz
T S = T S als r T bzw. r T ermittelt werden.
0
1
0
1
Durch Gleichungsumformung ergibt sich:
N0 – N1
r G = --------------------------N1 N0
---------- – ---------r
rD
1 D0
N0
bzw. mit dem Kompressionsfaktor k = ------- :
N1
k–1
r G = --------------------------- .
k
1
---------- – ---------rD
rD
0
1
Mit den Werten aus Tabelle 5 beträgt die Grenzrate im vorliegenden Szenario:
rG = 24,1 Mbit/s.
Da diese Rate im lokalen Netz (B-F) überschritten wurde, konnten für Farbbilder ohne Kompression
kürzere Reaktionszeiten erzielt werden. Dagegen wurde bei der Kommunikation im Weitverkehrsnetz
(A-F) durch den Einsatz der JPEG-Kompression ein besseres Reaktionsverhalten festgestellt.
Für Bilevel-Bilder ergibt sich aufgrund anderer Charakteristika (Kompressionsfaktor, Dekodier- und
Konvertier-Raten) eine niedrigere Grenzrate, so daß auch im Fall der Kommunikationsbeziehung A-F
die unkomprimierte Version, z. B. zum „Blättern“ in einem mehrseitigen Rasterbild-Dokument, vorzuziehen ist.
19
Abschlußbericht
4.1.3
Integration relationaler Datenbanken ins WWW
Zur Integration einer relationalen Datenbank (hier: Oracle) ins WWW wurden drei verschiedene Wege
erprobt.
1. Die einfachste Möglichkeit besteht darin, ein Shell-Skript als CGI-Programm aufzurufen, welches mit SQL-Befehlen (sqlplus) den Datenbank-Zugriff ausführt und das Ergebnis als HTMLSeite darstellt. Diese Methode hat jedoch die Nachteile, daß bei komplexen Abfragen das Skript
unübersichtlich wird und daß die Performance niedrig ist, da für jeden Zugriff eine neue Verbindung zur Datenbank aufgebaut werden muß.
2. Die zweite Möglichkeit ist die Nutzung eines speziell erstellten CGI-Programms zum Datenbank-Zugriff. Hier wurde ein C++-Programm geschrieben, das mit Hilfe der Klassenbibliothek
DB-Tools.h++ von der Firma RogueWave spezielle Datenbankzugriffe durchführt. Die Verwendung einer objektorientierten Programmiersprache bringt vor allem bei komplexen Anfragen
deutliche Vorteile in bezug auf Übersichtlichtkeit und Flexibilität der Lösung. Allerdings ist die
Performance nicht wesentlich besser als bei der sqlplus-basierten Lösung, da auch hier für jeden
Zugriff eine Verbindung zur Datenbank aufgebaut werden muß.
3. Bei der dritten Lösung wurde dieses Problem vermieden. Die Anbindung der Datenbank erfolgt
nicht durch ein CGI-Programm, sondern durch ein Modul, das in den Web-Server integriert
wird. Der Web-Server Apache bietet diese Möglichkeit an.
Der zuletzt genannte Ansatz wurde für die Anwendungen
• Mehrwertdienste für DFN-Mitteilungen (siehe Kap. 4.2.2)
• Bilddatenbank „Leonardo da Vinci – Codex Madrid I“ (siehe Kap. 4.2.3)
• Umfrage zur Akzeptanz der im Projekt erarbeiteten Anwendungen1
implementiert. Als Basis für das Modul wurde die freiverfügbare Software PHP/FI2 verwendet. Dabei
handelt es sich um einen Interpreter der Skript-Sprache PHP, die in HTML eingebettet und serverseitig
abgearbeitet wird, um damit die Gestaltung dynamischer WWW-Seiten zu ermöglichen. Die Ausgabe
eines solchen Skripts ist wiederum eine HTML-Seite, die an den Browser geschickt wird. PHP/FI verfügt über Befehle zum Zugriff auf Postgres- und MSQL-Datenbanken. Diese Befehle wurden für den
Zugriff auf Oracle-Datenbanken mit Hilfe der Klassenbibliothek DB-Tools.h++ angepaßt und erweitert, so daß eine Verbindung zur Datenbank nach der Anfrage offengehalten und bei der nächsten
Anfrage wiederverwendet wird. Dadurch können unnötige Performance-Einbußen vermieden werden.
Damit ergibt sich das in Bild 8 dargestellte Software-Architektur-Modell.
Apache WWW-Server
PHP/FI
RVS Glue Code
DBTools.h++
Oracle RDBMS
Bild 8: Software-Architektur-Modell der ORACLE-Datenbank-Integration
Die Skriptsprache PHP bietet nicht die Flexibilität einer höheren Programmiersprache, ist jedoch für
kleine und mittlere Projekte ausreichend. Das so implementierte System hat sich als außerordentlich
flexibel und stabil erwiesen. Neben der einfachen Nutzbarkeit dieser Datenbankanbindung ist vor
allem die hohe Performance hervorzuheben.
1. Siehe http://www.rtb-nord.uni-hannover.de/onlinedokumente/projekte/umfrage/
2. Siehe http://www.vex.net/php/
20
Abschlußbericht
4.2
Anwendungsszenarien
Technologie-Studien –
Prototypische exemplarische Anwendungen zur Demonstration von Methoden zur
Online-Publikation multimedialer Objekte
4.2.1
Elektronisierte Tageszeitung: Neue Hannoversche Presse
Aufgabenstellung
Der Projektplan sah die Zusammenarbeit mit einem lokalen Zeitungsverlag zur Bereitstellung von
Postscript-Ausgaben einer aktuellen Tageszeitung vor. Auf der Basis dieser Postscript-Daten sollte im
weiteren Verlauf eine Hypermedia-Version dieser Tageszeitung analog zu den DFN-Mitteilungen entwickelt werden.
Ausgangsposition
Eine Zusammenarbeit kam mit der hannoverschen Verlagsgesellschaft Madsack (VGM) zustande. Es
wurde vereinbart, täglich die aktuelle Ausgabe der Neuen Presse im WWW zu präsentieren. Als Basis
konnte der Verlag die Zeitung im PDF-Format zur Verfügung stellen. Um die PDF-Daten ins RRZN/
RVS zu übertragen, wurde im RRZN/RVS ein Apple-Macintosh-Rechner mit Leonardo-SP-Karte und
Filerouter- sowie FTP-Server-Software installiert. Auf diesen wurde jede Nacht die aktuelle Ausgabe
der Neuen Presse per ISDN übertragen. Die PDF-Daten wurden mit Hilfe der zur Postscript/RasterKonvertierung erarbeiteten Verfahren (PaperMaker) in Hyper-Dokumente umgewandelt und auf dem
Web-Server des RTB Nord ausgestellt.
Für eine weitergehende Konvertierung, etwa in reine HTML/Text-Daten, erwiesen sich die PDF-Daten
als ungeeignet, da sie lediglich Layout-, aber keine Strukturinformationen enthielten, die eine Automatisierung ermöglicht hätten. Wegen des unverhältnismäßig hohen Personalaufwands, der für eine
solche Konvertierung notwendig gewesen wäre, wurde darauf verzichtet.
Zeitlicher Überblick
Die regelmäßige Übertragung der Neuen Presse an das RRZN/RVS begann am 26. September 1995
und endete am 3. Juli 1996. Bis zum 29. Februar 1996 wurden die Seiten der Neuen Presse täglich in
zwei PDF-Dateien übertragen, vom 1. bis 6. März als Einzeldateien im PDF-Format und vom 7. März
bis 3. Juli als Einzeldateien im EPS-Format. Am 3. Juli 1996 wurde die Übertragung vom Verlag Madsack aus innerbetrieblichen Gründen eingestellt.
Angebotene Datenformate
Innerhalb dieser Zeitspanne wurde die Neue Presse in vier Formaten angeboten. Die Rasterbilder der
Seiten wurden im TIFF- und im GIF-Format erzeugt. Die GIF-Dateien wurden für die HTML-Präsentation (PaperMaker) verwendet, die TIFF-Dateien wurden mit dem im Rahmen des Projekts entwikkelten Browser DocShow dargestellt.
Zusätzlich zu den rasterbildbasierten Hyper-Dokumenten wurde die Neue Presse auch im Postscriptund PDF-Format zur Verfügung gestellt. Da die Umwandlung von Postscript in PDF bis heute nicht
automatisch (im Batch-Betrieb) durchgeführt werden kann, sind nicht alle Formate für jeden Tag
erzeugt worden. Insbesondere nach dem 7. März 1996 wurden für längere Zeit nur die Rasterformate
angeboten.
Produktionskette
Die Produktionskette für eine Ausgabe der Neuen Presse bestand aus folgenden Schritten:
1. Transport der PDF/PS-Dateien per Filerouter-Software über ISDN auf den Apple-Rechner im
RRZN/RVS
21
Abschlußbericht
Bild 9: Rasterbild-Version der Neuen Presse
Bild 10: DocShow-Version der Neuen Presse
22
Abschlußbericht
Bild 11: PDF-Version der Neuen Presse
2. Transport der PDF/PS-Dateien per FTP auf den Web-Server des RTB Nord
3. Erzeugung der Rasterbilder im TIFF- und GIF-Format und des Skripts paper.cgi (analog zu
Papermaker)
4. Erzeugung der Setup-Dateien für die DocShow-Präsentation des Neuen Presse
5. Eintragen der Links auf die neue Ausgabe im Web-Server
Die Produktionskette für die Erstellung der Rasterbild-Version ließ sich auf RRZN/RVS-Seite vollständig automatisieren. Probleme ergaben sich dadurch, daß auf Seiten des Verlags einige Male die
Datei-Namen der PDF-Dateien geändert wurden, ohne daß dies angekündigt wurde. Desweiteren wurden im späteren Verlauf des Projekts statt der PDF-Daten EPS-Daten geliefert. Die Produktionskette
ließ sich aber ohne Schwierigkeiten anpassen.
Datenvolumen und Verarbeitungszeit
Das Datenvolumen einer Tagesausgabe der NP betrug im PDF-Format ca. 2,5 - 4 MByte, im Postscript-Format, d.h. nach dem 7. März 1996, ca. 35 - 50 MByte. Das geringere Volumen der PDFDateien ist dadurch begründet, daß Bilder im PDF-Format in der Regel in der Auflösung reduziert und
zusätzlich JPEG- oder LZW-komprimiert werden. Die entstandenen Rasterbilder haben pro Seite eine
Größe von ca. 700 kByte - 6 MByte im TIFF-Format und ca. 200 kByte - 1,5 MByte im GIF-Format.
Eine graphische Darstellung der Datenvolumina zeigen Bild 12 und Bild 13.
Die Transferzeit der Daten vom Verlag zum Web-Server im RRZN/RVS wurde im wesentlichen durch
die Übertragungszeit auf der ISDN-Strecke bestimmt. Bei einer Brutto-Datentransferrate von 128 kBit
(Kanalbündelung) auf der ISDN-Strecke ist die Übertragungszeit auf der Ethernet-Verbindung zwischen Apple-Rechner und Web-Server vernachlässigbar. Bei einer angenommenen Netto-Datenrate
von 85% und einem mittleren Datenvolumen von 3,3 MByte ergibt sich eine Übertragungszeit von
248 Sekunden, also etwa 4 Minuten.
Dagegen ist die Verarbeitungszeit der Daten erheblich größer. In Tabelle 6 ist der Zeitbedarf der vier
wichtigsten Verarbeitungsschritte am Beispiel einer Ausgabe daufgeführt. Diese vier Schritte sind die
23
Abschlußbericht
Eingangsdatenvolumen pro Seite (PDF und EPS)
6. 3. 96
2.5
Datenformat
PDF
EPS
Größe [in MB]
2.0
Marken
1.5
1.0
0.5
0.0
Okt
Nov
Dez
Jan
Feb
Mar
Apr
Mai
Jun
Zeitraum (27. Sept. 1995 - 3. Juli 1996)
Bild 12: Eingangsdatenvolumina der Neuen Presse pro Seite (PDF und EPS)
Ausgangsdatenvolumen pro Seite (TIFF und GIF)
6. 3. 96
3.0
Datenformat
TIFF
GIF
2.5
Größe [in MB]
Marken
2.0
1.5
1.0
0.5
0.0
Okt
Nov
Dez
Jan
Feb
Mar
Apr
Mai
Jun
Zeitraum (27. Sept. 1995 - 3. Juli 1996)
Bild 13: Ausgangsdatenvolumina der Neuen Presse pro Seite (TIFF und GIF)
Rasterung der PDF/PS-Daten, die Skalierung auf die gewünschte Auflösung mit Antialiasing, die
Konvertierung ins TIFF-Format und die Konvertierung ins GIF-Format. Gegenüber dem Zeitbedarf
dieser vier Schritte ist die restliche Verarbeitungszeit vernachlässigbar. Die Zahlen zeigen, daß die Zeit
für die Skalierung mit pnmscale unabhängig vom Bildinhalt konstant ist, während die übrigen drei
Schritte eine starke Abhängigkeit vom Bildinhalt aufweisen. Genaue Voraussagen für den Zeitbedarf
einer derartigen Produktionskette lassen sich also nicht treffen. Die Zeiten schwanken mit der Anzahl
24
Abschlußbericht
Seite
Rasterung
Skalierung
TIFF
GIF
Gesamt
01
19,46
30,22
14,28
31,37
95,33
02
13,82
30,24
29,29
05,33
78,68
03
10,18
30,23
13,59
33,38
87,38
04
08,39
30,15
19,85
04,98
63,37
05
13,50
30,16
15,55
38,87
98,08
06
08,06
30,15
17,83
04,85
60,89
07
11,47
30,19
27,83
06,09
75,58
08
11,55
30,11
13,59
27,42
82,67
10
17,02
30,11
13,80
30,40
91,33
11
06,54
30,29
13,27
04,29
54,39
12
12,23
30,18
15,21
23,35
80,97
13
36,25
30,12
25,27
05,09
96,73
14
23,98
30,12
12,33
19,44
85,87
15
12,92
30,50
14,81
34,86
93,09
16
11,41
30,34
21,59
05,40
68,74
17
15,94
30,24
13,38
25,59
85,15
18
09,06
30,26
22,12
04,67
66,11
19
08,68
30,23
09,70
13,18
61,79
20
05,37
30,12
11,40
04,00
50,89
24
06,21
30,15
13,81
04,11
54,28
26
06,20
30,11
11,91
04,09
52,31
28
16,44
30,11
16,80
43,70
107,05
Ges.
284,68
664,33
367,21
374,46
1690,68
Tabelle 6: Verarbeitungszeit einer Ausgabe der NP (alle Werte in Sekunden)
der Seiten einer Ausgabe, mit der Anzahl der Größe und dem Inhalt der Bilder auf der Seite. Der
Gesamtzeitbedarf für die hier bespielhaft betrachtete Ausgabe liegt bei 39 Minuten und 27 Sekunden.
Bewertung
Die Produktionskette zur Erzeugung der Online-Versionen arbeitete über einen langen Zeitraum
zufriedenstellend. Fehlfunktionen traten nur auf, wenn die Eingangsdaten nicht korrekt waren. Das
Ergebnis der Produktionskette ist aber als elektronische Tageszeitung nur bedingt sinnvoll. Die Zeitungsseiten im Rasterformat sind selbst auf 20-Zoll-Bildschirmen nur schwer lesbar, obwohl die Seiten hier bereits in Originalgröße angezeigt werden. Bei geringerer Bildschirmgröße als
1280 * 1024 Pixel wird der betrachtete Ausschnitt der Seite immer kleiner, so daß mehr gescrollt werden muß. Eine akzeptable Ganzseitendarstellung einer Tageszeitung ist mit den heute üblichen Moni-
25
Abschlußbericht
toren nicht möglich. Der größte Nachteil der Rasterbild-Versionen sind die fehlenden
Strukturinformationen. Dadurch sind Mehrwertdienste wie Suchfunktionen, Nachrichten-Archive,
usw. nicht realisierbar. Diese Mehrwertdienste sind aber gerade die Stärke der interaktiven, elektronischen Medien im Vergleich zu herkömmlichen Medien. Eine sinnvolle Hypertext-Version kann nur
mit Hilfe von Strukturinformationen zu jedem Artikel erstellt werden. Diese Strukturinformationen
müßten vom Verlag als Eingangsdaten für die Produktionskette mitgeliefert werden.
Zu beachten ist hier, daß von Seiten des Verlags die Bedingung gestellt wurde, daß die Zeitung im
WWW ausschließlich als originalgetreues Abbild der Druckausgabe erscheinen müsse. Diese Forderung stand einer sinnvolleren Gestaltung der Online-Version als Hyper-Dokument im Weg. Wünschenswert wäre eine Hyper-Media-Version der Zeitung auf HTML-Basis mit Mehrwertdiensten
ergänzt um eine Originaldarstellung der Druckausgabe. Mittlerweile hat im Verlag in diesem Punkt ein
Umdenken eingesetzt. Seit dem 28. August 1996 bietet der Verlag einen eigenen Online-Informationsdienst1 im WWW an, der auch Nachrichten im Hypertext-Format mit Suchfunktionen enthält.
Eine Möglichkeit, originalgetreue Darstellung und Mehrwertdienste zu vereinen, bietet das neuere
Datenformat PDF. Mit Hilfe des PDF-Browsers Acrobat Reader können PDF-Dokumente am Bildschirm betrachtet und dabei beliebig skaliert werden. Es kann nach Zeichenketten gesucht werden und
es können Links in den Text eingefügt werden, so daß auch PDF-Hyper-Dokumente möglich sind.
Leider sind Software-Werkzeuge zur Erzeugung und Bearbeitung von PDF-Dokumenten erst seit kurzer Zeit auf dem Markt und noch nicht für alle Plattformen verfügbar. Im Rahmen des Projekts standen die Werkzeuge Acrobat PDF-Writer und Acrobat Distiller auf dem Apple PowerMac zur
Verfügung. Mit diesen ist jedoch keine Batch-Verarbeitung möglich, so daß nach dem 6. März 1996
nur noch für wenige Ausgaben zu Testzwecken PDF-Versionen der Neuen Presse erstellt werden
konnten. Dennoch bietet die PDF-Version der Neuen Presse die meisten Vorteile gegenüber der Postscript- und den Rasterbild-Versionen. Die Rasterung von PDF-Dokumenten am Bildschirm mit dem
Acrobat Reader erfolgt wesentlich schneller als die von Postscript-Dokumenten. Der Acrobat Reader
ist frei verfügbar für die meisten Plattformen und auch als Plug-In für Netscape vorhanden.
4.2.2
Elektronische Zeitschrift mit Mehrwertdiensten: DFN-Mitteilungen
4.2.2.1 Aufgabenstellung
Der Projektplan sah die automatische Erstellung elektronischer Versionen der DFN-Mitteilungen vor,
zunächst im Postscript-Format, dann als rasterbildbasierte Versionen (PaperMaker: siehe Kap. 4.1.1,
DocShow: siehe Kap. 4.1.2), später als reines HTML-Dokument. Die HTML-Version war durch
Mehrwertdienste (Hyper-Links, Suchfunktionen) zu erweitern.
4.2.2.2 Ausgangsposition
Die DFN-Mitteilungen werden mit Hilfe des Desktop-Publishing-Systems QuarkXPress auf einem
Apple-Macintosh-Rechner beim DFN-Verein gesetzt. Eine Ausgabe umfaßt eine QuarkXPress-Datei
für die Titelseite, eine für die übrigen Seiten und die Dateien für die Bilder. Die Bilder liegen im TIFFoder im EPS-Format vor.
Der Transport der Daten vom DFN-Verein zum RRZN/RVS erfolgte per Wechselfestplatte auf dem
Postweg.
4.2.2.3 Zeitlicher Überblick
Die DFN-Mitteilungen erscheinen dreimal jährlich im März, im Juni und im November. Es wurden die
Ausgaben der Jahrgänge 1994–1996 bearbeitet, von Heft 34 bis Heft 42. Hypertext-Versionen im
HTML-Format wurden für alle diese Ausgaben bis auf Heft 34 erzeugt. Für die Jahrgänge 1995 und
1996 sind auch die Mehrwertdienste verfügbar, wobei diese rückwirkend für die älteren Ausgaben
erstellt wurden. 1996 wurden ebenfalls rückwirkend für alle 9 Ausgaben PDF-Versionen erstellt.
1. MOL - Madsack On Line, http://www.niedersachsen.com/
26
Abschlußbericht
4.2.2.4 Angebotene Datenformate
Die DFN-Mitteilungen werden in fünf Versionen angeboten:
1. Postscript-Version
2. PDF-Version
3. Rasterbild-Version (PaperMaker)
4. DocShow-Version
5. HTML-Version
Bild 14 zeigt die HTML-Version, Bild 15 die Rasterbild-Version eines Artikels.
Bild 14: HTML-Version der DFN-Mitteilungen
4.2.2.5 Mehrwertdienste
Die Mehrwertdienste wurden im Rahmen einer Studienarbeit [LEON] entwickelt. Sie basieren auf
einer Oracle-Datenbank, in der Metainformationen zu den Artikeln der DFN-Mitteilungen gespeichert
werden. Die Speicherung der Metainformationen erfolgt im Anschluß an die Erzeugung der HTMLVersion. Die Metainformationen umfassen für jeden Artikel die Ausgabe, in der er steht, die Überschrift, die Rubrik, den Autor samt Zusatzinformationen, die Bilder und den gesamten unformatierten
Text für die Volltextsuche. Als Mehrwertdienste werden neben der Volltextsuche (Bild 16) ein flexible
spezifische Suche, eine Autorenübersicht, eine nach Rubriken geordnete Artikelübersicht und eine
Statistik angeboten. Bild 17 zeigt das Ergebnis einer Anfrage nach dem Begriff „Multimedia“ in den
Überschriften der Artikel.
4.2.2.6 Produktionskette
Die Produktionskette für die DFN-Mitteilungen besteht aus zwei unabhängigen Teilen, der Erzeugung
der HTML-Version einerseits und der Erzeugung der übrigen Versionen andererseits. Bild 18 stellt die
Produktionskette schematisch dar.
Zunächst wird aus den QuarkXPress-Dateien eine Postscript-Datei der DFN-Mitteilungen generiert.
Dazu werden die Titelseite und die übrigen Seiten zusammengefügt und mit einem Postscript-Drukkertreiber in eine Datei gedruckt.
27
Abschlußbericht
Bild 15: Rasterbild-Version der DFN-Mitteilungen
Bild 16: Volltextsuche in den DFN-Mitteilungen
28
Abschlußbericht
Bild 17: Ergebnis einer Abfrage nach dem Begriff „Multimedia“
Die Postscript-Version enthält alle Seiten mit Bildern in hoher Qualität und dient im wesentlichen als
Quelle für die übrigen Formate. So wird daraus mit dem Adobe Acrobat Distiller eine PDF-Version
erzeugt, in der die Bilder auf 72 dpi reduziert und LZW-codiert sind. Mit Hilfe der Postscript/RasterKonvertierung (siehe PaperMaker) werden aus der Postscript-Datei ebenfalls die Rasterbild-Version
und die TIFF-Dateien für die DocShow-Version gewonnen. Dazu dient eine leicht modifizierte Version des PaperMaker-Skripts pdfps2html. Die so entstandenen vier Versionen können einfach in den
Web-Server integriert werden.
Der Ablauf für die HTML-Version ist aufwendiger. Als Quelle dient hier nicht die Postscript-Datei,
sondern die QuarkXPress-Datei. Das Verfahren wurde im Rahmen einer Studienarbeit [NEBEL] entwickelt. Es basiert auf einem am MIT entwickelten Konverter qt2www von QuarkXPress nach HTML.
Dieser wurde erweitert und den speziellen Bedürfnissen für die DFN-Mitteilungen angepaßt. Das
Ergebnis der Konvertierung ist ein einfacher Verzeichnisbaum mit einem Verzeichnis für jeden Artikel, das die HTML- und die Bilddateien enthält. Die Bilder, die zunächst im TIFF oder EPS-Format
vorliegen, werden im Laufe der Konvertierung mit den in PaperMaker eingesetzten Verfahren in GIF-
29
Abschlußbericht
QuarkXPress
qt2www, gs, convert, pnmscale
Druckertreiber
PS
Acrobat
Distiller
PDF
HTML
&
TIFF,GIF
pdfps2html
TIFF
&
GIF
Bild 18: Produktionskette der DFN-Mitteilungen
Bilder umgewandelt. Es wird sowohl eine Version in Originalgröße erzeugt, als auch eine verkleinerte
Version der Bilder. Die verkleinerte Version wird auf der HTML-Seite sofort angezeigt, die Version in
Originalgröße ist über einen Hyper-Link erreichbar.
Mit Hilfe eines SED-Skripts werden alle URLs in den Artikeln in Hyper-Links umgewandelt, ebenso
erhalten alle EMail-Adressen den HTML-Tag <MAILTO>.
Ein weiteres Skript fügt HTML-Tags für Server-Side-Includes ein, durch die ein einheitliches Layout,
z. B. Hintergrund, und eine Fußleiste mit Hyper-Links zu den Mehrwertdiensten erzeugt werden.
Im letzten Schritt werden die Metadaten zu den Artikeln aus den HTML-Dateien extrahiert und in der
Datenbank gespeichert. Dazu dienen die im Rahmen der Studienarbeit [LEON] zu den Mehrwertdiensten entwickelten Programme dfngen und dfndb. Die Umwandlung erfolgt in zwei Stufen, da sich
nicht in jedem Fall die Strukturinformationen aus den HTML-Dateien gewinnen lassen. Zum Beispiel
ist keine automatische Trennung von Vor- und Nachnamen und Nameszusätzen eines Autors möglich.
Daher parst zunächst das Programm dfngen die HTML-Dateien und schreibt die Metadaten strukturiert in eine Textdatei. Diese wird von Hand überprüft und gegebenenfalls korrigiert. Das Programm
dfndb liest die geprüfte Textdatei und speichert die Daten in der Datenbank.
4.2.2.7 Datenvolumen und Verarbeitungszeit
Die erzeugten Datenvolumina aller fünf Versionen sind in Tabelle 7 für alle Ausgaben aufgeführt. Für
die Rasterbild- und DocShow-Versionen ist jeweils das Datenvolumen aller GIF- bzw. TIFF-Bilder
angegeben, für die HTML-Version die Summe aller relevanten Dateien, sowohl HTML- wie auch
Bild-Dateien.
Die komplette Bearbeitung einer Ausgabe der DFN-Mitteilungen benötigt in der Regel zwei Mitarbeitertage. Dies ist zurückzuführen auf den hohen interaktiven Bearbeitungsaufwand für die HTML-Version, sowohl vor der eigentlichen Konvertierung als auch in der Nachbearbeitung der HTML-Seiten.
Manuelle Überprüfung und Korrektur ist hier bisher unerläßlich.
4.2.2.8 Bewertung
Projektziel war die automatisierte Erstellung einer „elektronischen Zeitschrift“ aus den QuarkXPressVorlagen der DFN-Mitteilungen. Dieses Ziel ließ sich nur bedingt erreichen. Der zur Verfügung stehende Konverter erfordert zunächst eine interaktive Vorbearbeitung der QuarkXPress-Dateien. Aus
den vorbearbeiteten QuarkXPress-Dateien lassen sich damit automatisch HTML-Dateien und BildDateien erzeugen. Im Anschluß daran ist aber noch eine manuelle Nachbearbeitung erforderlich.
Ebenso erfordert die Generierung der Metadaten für die Datenbank manuelle Korrekturen.
30
Abschlußbericht
Ausgabe
PS
PDF
TIFF
GIF
HTML
34
5.261.305
701.960
3.612.672
2.879.488
0
35
5.811.263
558.958
2.813.952
2.326.528
2.637.824
36
18.843.095
1.057.622
4.931.584
2.908.160
3.919.872
37
16.026.335
866.718
3.780.608
2.420.736
1.748.992
38
30.303.717
1.423.499
5.783.552
2.654.208
6.389.760
39
63.043.053
1.264.529
6.053.888
3.284.992
10.907.648
40
51.161.305
1.501.201
6.926.336
3.362.816
2.834.432
41
62.797.394
7.957.095
6.324.224
2.781.184
3.366.912
42
61.211.374
2.668.185
6.246.400
2.953.216
3.301.376
Tabelle 7: Datenvolumen der DFN-Mitteilungen (in Bytes)
Die Notwendigkeit manueller Eingriffe in die Produktionskette ist in den fehlenden Strukturinformationen in den Eingangsdaten begründet. Die QuarkXPress-Vorlagen enthalten Format-,
d. h. Layoutinformationen, aber kaum verläßliche Informationen zur inhaltlichen Struktur des Dokuments. Die fehlenden Strukturinformationen müssen manuell ergänzt werden.
Dennoch ist das Endprodukt der Produktionskette eine im Sinne der Aufgabenstellung „elektronische
Zeitschrift“ im HTML-Format mit (teils datenbankbasierten) Mehrwertdiensten, wie Hypertext-Links,
Suchfunktionen und Autorenübersicht. Begleitet wird diese Hypertext-Version von vier weiteren Versionen, insbesondere der Postscript- und der PDF-Version als Druckvorlagen. Insofern konnte das Projektziel erreicht werden.
Die Produktionskette konnte im Laufe des Projekts ständig verbessert und vereinfacht werden,
z. B. durch weiterentwickelte Versionen der verwendeten Konvertierungssoftware. Der Umfang der
manuellen Nachbesserungen ließ sich somit reduzieren, wenn auch nicht ganz beseitigen.
Durch die neu erstellte Metadatenbank wurden die Voraussetzungen geschaffen, die HTML-Version
der DFN-Mitteilungen zukünftig komplett datenbankbasiert zu generieren. Dies hätte eine weitere
Reduzierung des manuellen Arbeitsaufwandes zur Folge. Eine derartige Weiterentwicklung der Produktionskette sollte im Rahmen eines Folgeprojekts vorgesehen werden.
Von Seiten des DFN-Vereins und der Benutzer kamen während der Projektlaufzeit positive Kommentare zu der „elektronischen Zeitschrift“. Der DFN-Verein hat ein Interesse an der Fortsetzung der
Zusammenarbeit mit dem RRZN/RVS signalisiert.
4.2.2.9 Literaturhinweise
[LEON]
Claus Leonhardt, „Datenbank-basierte Mehrwertdienste im Online-Publishing“, Studienarbeit am Lehrgebiet Rechnernetze und Verteilte Systeme (RVS), Universität Hannover, 1996
[NEBEL]
Michael Nebel, „Diskussion eines Konzepts zur Online-Bereitstellung von Dokumenten“, Studienarbeit am Lehrgebiet Rechnernetze und Verteilte Systeme (RVS), Universität Hannover, 1995
[WOLPERS] Martin Wolpers, „Aufbereitung von SGML-Dokumenten für das Online-Publishing“,
Studienarbeit am Lehrgebiet Rechnernetze und Verteilte Systeme (RVS), Universität
Hannover, 1996
31
Abschlußbericht
4.2.3
Abbildungen wertvoller Unikate: Virtuelle Galerie Kö 24, Codex Madrid I
Als Beispielanwendungen mit hohem Bandbreitenbedarf wurden Online-Präsentationen von photographischen Abbildungen erarbeitet:
• Virtuelle Galerie Kö 24
• Leonardo da Vinci: Codex Madrid I
Es wurden verschiedene Gesichtspunkte berücksichtigt.
Bei der virtuellen Galerie wurde besonderer Wert auf die hochwertige Gestaltung, d. h. das Oberflächendesign, gelegt. Im Rahmen einer vom Projekt-Team betreuten Studienarbeit (siehe auch Anhang)
an der Fachhochschule Hannover, Fachbereich Kunst und Design, wurden statische WWW-Seiten
erstellt. Dabei wurden zum jeweiligen Zeitpunkt aktuelle HTML-Elemente, wie z. B. Frames und Client-Side-Imagemaps, verwendet. Als Bildmaterial, d. h. Inline-Images, dienten gescannte Dias, welche durch Nachbearbeitung in die letztlich präsentierte Form gebracht wurden.
Vom „Codex Madrid I“, einer historischen Handschrift von Leonardo da Vinci, wurden ebenfalls digitale Bilder durch Scannen erzeugt und diese im WWW, aber auch mit DocShow, präsentiert. Die
WWW-Seiten bieten interaktive Schnittstellen zur Suche mittels Metadaten aus einer ORACLEDatenbank sowie auch zur nachträglichen Attributierung.
Virtuelle Galerie Kö 24
Der hannoversche Galerist Robert Simon besitzt eine private Sammlung von Gemälden und Plastiken
verschiedener Künstler. Eine Auswahl von ca. 20 Exponaten wurden auf Mittelformat-Diafilm
(60 x 70 mm) photographiert und mit einer Auflösung von 1270 dpi auf einem Trommelscanner im
Rahmen eines Fremdauftrages digitalisiert. Die daraus resultierenden TIFF-Bilddateien (je ca.
30 MByte) stellen für den Druck im DIN-A4-Format eine ausreichende Auflösung zur Verfügung. Für
die Bildschirm-Präsentation wurden Dateien mit entsprechend geringerer Auflösung durch Konvertierung der hochauflösenden Bilddaten generiert. Dadurch werden in gewissem Maße auch qualitativ
hochwertige Ausschnittvergrößerungen der Bildschirmdarstellung ermöglicht. Der Zugriff erfolgte zur
CeBIT 1995 in einer relativ einfachen Form über WWW1 und DocShow2, zur CeBIT 1996 über ausgestaltete WWW-Seiten3 (siehe Bild 19).
Bild 19: Ein Beispiel aus der virtuellen „Galerie Kö 24“
1. http://cebit95.rvs.uni-hannover.de/galerie_simon
2. http://cebit95.rvs.uni-hannover.de/galerie_simon/simon.dvs
3. http://www.rtb-nord.uni-hannover.de/onlinedokumente/projekte/T-StudieKoe24.html
32
Abschlußbericht
Leonardo da Vinci: Codex Madrid I
Die Faksimile-Ausgabe (Gesamtauflage: 1500) dieser historischen Handschrift steht in Deutschland
nur an zwei Standorten (unter gewissen Voraussetzungen leihweise) zur Verfügung. Auf einem Flachbettscanner (HP Scanjet II cx) wurden sämtliche 188 Doppelseiten mit einer Auflösung von 400 dpi
digitalisiert. Eine Doppelseite hat ca. DIN-A4-Format, daraus folgt ein Datenvolumen von ca.
50 MByte je Doppelseite im TIFF-RGB-Format, also ca. 10 GByte insgesamt. Wie bei der virtuellen
Galerie (s. o.) wurden dann daraus Bilder mit verschiedenen geringeren Auflösungen und Dateiformaten errechnet und wahlweise über WWW – mit datenbankbasierten Mehrwertdiensten (siehe auch
Kap. 4.1.3), d. h. Retrieval- und Attributierungsfunktionalität (siehe Bild 20) – und DocShow zur Verfügung gestellt1.
Bild 20: Suchergebnis in Leonardo da Vinci‘s „Codex Madrid I“
4.2.4
Virtuelle Welten: Stadtspaziergang Hannover
Der hannoversche Photograph Hassan Mahramzadeh (mehrere Buch-Veröffentlichungen liegen vor)
stellte für das Projekt eine größere Anzahl von Aufnahmen zu Verfügung. Dies sind im wesentlichen
Kleinbild-Dias, z. T. auch Mittelformat-Dias (60 x 70 mm). Es wurde erwogen, gewisse Objekte – wie
z. B. auch die o. g. Kunstobjekte – mit Hilfe der Digitalen Photographie (siehe Bild 21) neu zu erfassen. Aufgrund der hohen Kosten und der bislang noch relativ geringen resultierenden Bildauflösung
wurde dann schließlich eine Entscheidung zu Gunsten der herkömmlichen Verfahrenskette getroffen –
Scannen von herkömmlichen Photographien.
1. http://www.rtb-nord.uni-hannover.de/onlinedokumente/projekte/Leonardo/
33
Abschlußbericht
Zum Scannen einer größeren Anzahl von Kleinbild-Dias wurde aus Projektmitteln ein DiascannerArbeitsplatz beschafft. Um andere Medien (z. B. größere Diaformate) erfassen bzw. höhere Bildqualitäten (z. B. bzgl. der Auflösung) erzielen zu können, wäre ein Trommelscanner erforderlich. Neben
den wesentlich höheren Beschaffungkosten stellt die Bedienung eines solchen Geräts jedoch besondere Anforderungen.
1. Scannen von herkömmlichen Photographien (Dias), z. B.: „Galerie Simon“
Herkömmliche
Kamera
Objekt
Dia
TrommelScanner
BildDatei
Digitale Kamera
2. Digitale Photographie
Bild 21: Scannen von herkömmlichen Photographien vs. Digitale Photographie
Die Photographien wurden in einen gestalteten Gesamtzusammenhang gebracht, um letztlich im
WWW einen „virtuellen Stadtrundgang“ zu ermöglichen (siehe Bild 22).
Bild 22: Einstiegsseite in den „Stadtspaziergang Hannover“
34
Abschlußbericht
Über die damit gebotenen Navigationsmöglichkeiten über textuelle Hyperlinks und Imagemaps hinaus
wurden 3D-Prototypen – z. B. Stadtrundgang, Posterausstellung (RTB Nord) – erstellt, um Erfahrungen in der Modellierung, Konvertierung und Online-Präsentation von virtuellen 3D-Objekten zu
gewinnen (siehe Bild 23).
Dazu wurden Verarbeitungsprozesse auf der Basis mehrerer Werkzeuge – einem professionellen
Modellierungs- und Animationswerkzeug (Softimage), WebSpaceAuthor, mehrerer Konvertierer und
VRML-Viewer – erarbeitet und erprobt.
Bild 23: Hannover als abstraktes virtuelles 3D-Modell (VRML-Viewer)
4.3
Studien
Die Ausarbeitungen der Studien
• „Zur Diskrepanz der Bildauflösung verschiedener Präsentationsmedien“
und
• „Urheberrechtliche Probleme im Internet“
sind im Anhang zu finden. Zu den Themenkomplexen
• „Internet-Dienste für den kommerziellen Einsatz“
und
• „Anwendung des SGML-Standards im WWW-Kontext“
wird auf die von Projekt-Mitarbeitern betreuten Studien- und Diplomarbeiten von L. Schütte und
M. Wolpers (siehe Kap. 3.4) verwiesen.
35
Abschlußbericht
5
Ausgangspunkt des Projekts „Online-Dokumente“ war ein Testszenario für Leistungsmessungen an
Hochleistungs-Kommunikationsnetzen auf der Basis von SDH. Als besondere Anforderung sollte das
“Buch-Paradigma” dienen. Es war beabsichtigt, hochaufgelöste Farbbilder von Buchdruck-Unikaten
in einer Client/Server-Umgebung zu übertragen und das von Wissenschaftlern geschätzte „Blättern“ in
einem elektronischen Buch zu realisieren. Das ursprüngliche Projekt konnte nicht durchgeführt werden, da die Telekom die benötigten SDH-Strecken nicht zur Verfügung stellen konnte. Das Regionale
Testbed Nord des DFN mit seiner leistungsfähigen Infrastruktur konnte jedoch zu einer erweiterten
Zielstellung genutzt werden. Schon bei Antragstellung war klar, daß in dem Projekt eine Reihe technischer, organisatorischer und rechtlicher Probleme zu behandeln war. Aus diesem Grunde war das Projekt in Form einer Studie zur Problematik des elektronischen Publizierens angelegt. Die Ausgangslage
wurde auch im Rahmen einer DFN-Fachtagung umfassend beschrieben1.
In der Projektlaufzeit von zwei Jahren konnte ein deutlicher Fortschritt bei der Problematik des elektronischen Publizierens beobachtet werden. Zu Beginn der Diskussion mit Verlagsunternehmen
bestand wenig Bereitschaft der Verlage, auf ihre gewachsenen Layout- und Formatstrukturen zu verzichten. Aus diesem Grund wurde z. B. die Tageszeitung „Neue Hannoversche Presse“ in unveränderter Form als „elektronisierte“ Zeitung (Rasterbild) angeboten. Inzwischen hat sich generell die
Erkenntnis durchgesetzt, daß in elektronischen Medien spezifische Layout- und Formatstrukturen
benutzt werden müssen. Mehrere Technologiestudien des Projekts haben hier zu einem besseren Verständnis der Mechanismen des elektronischen Publizierens beigetragen. Von großer Bedeutung ist die
gestalterische Aufbereitung elektronischer Dokumente. Hier hat sich der Einsatz einer Fachkraft für
Layout und Design im Projekt als geradezu beispielgebend erwiesen. Es ist mittlerweile völlig klar,
daß das „Elektronische Paradigma“ eigene Gestaltungsnotwendigkeiten besitzt.
Unverändert hart stellt sich die rechtliche Problematik des elektronischen Publizierens dar. Im Projekt
konnten grundlegende Probleme identifiziert werden. Es ist zu hoffen, daß die notwendige Gesetzgebung hier in Kürze Klarheit schafft. Gleichermaflen hart ist die Barriere der derzeit unzureichenden
Bildschirmtechnologie. Hierzu sind im Bericht, Kapitel 6, grundlegende Aussagen enthalten.
Generell hat das Projekt dazu beigetragen, die Produktionsketten des elektronischen Publizierens
transparent zu machen, dies ist u. a. am Beispiel der DFN-Mitteilungen besonders deutlich geworden.
Besonders die sog. „Mehrwertdienste“, d. h. Recherchemöglichkeiten in elektronischen Dokumenten,
bilden einen Schlüssel zu besseren Informationsdiensten im Wissenschaftsbereich. Hier liegen die
eigentlichen Vorteile des Online-Dokuments gegenüber dem klassischen Buch- oder ZeitschriftenParadigma.
Das Projekt „Online-Dokumente“ hat wesentlich zur Bildung von entsprechender Fachkompetenz im
DFN beigetragen. Der vorliegende Bericht weist dies deutlich aus. Die gewonnenen Erkenntnisse sind
u. a. inzwischen auch in weitreichenden Vorhaben, z. B. der „Internet Expo“, und auch kommerziellen Entwicklungen berücksichtigt worden. Die am RRZN/RVS vorhandene Kompetenz soll nun im
Rahmen von Folgeprojekten, besonders der „DFN-Expo“, genutzt werden. Dabei sollen neue Technologien erprobt werden.
1. Pralle, H.: Aspekte des elektronischen Publizierens – Network Publishing –
9. DFN-Fachtagung über Rechnernetze, 1995, Bad Honnef
36

RTB Nord – P5.1: „Online-Dokumente“

Transcription

Similar documents

DSR 6000 HDCI deutsch

WUS Festschrift 2010 - World University Service

Drachen in Märchen, Geschichten und Filmen

Einsatzmöglichkeiten des SAP NetWeaver CE 7.3 für

Terminal Server Sizing Guide

Die Musik des 20. Jahrhundert - Treffpunkt

Musik - in Brunnvalla

Geburtstagsparty - Kultur Aktiv eV

acron helvetia ix immobilien ag

750979 - WEBServer_PL - produktinfo.conrad.com

Weitere Informationen zum Audi 100 5E

EdW muss Phoenix Opfer entschädigen (27