Offensichtlich kapiere ich es nicht, und formuliere es mal "entschaerft", indem ich den Beitrag auf eine ominoese Zukunft (war) beziehe, in der nichts verstanden wurde ("in"), in der irgendwelche Unternehmen ganz paradiesisch schon nahezu ausnahmslos Benutzer und Standards beruecksichtigt haben (Vorteile wurden [...] ausgespielt, um echten Mehrwert zu bieten), obwohl zeitgleich aber kaum jemand mehr (technische) Skills hatte (Mühe darauf verwendet), und dann alle nochmal degeneriert sein muessen (nur damit der Online-Besucher ebenfalls bedient wird).

Die beschriebene Zukunft wird noch "interessanter": Es scheint keinen "Speichern"-Dialog mehr zu geben (Problematik, dass der Besucher [...] HTML-Dokuments [...] nur unter größeren Mühen lokal konservieren kann), ebensowenig, wie es noch "Standalone"-HTML-Dokumente gibt (denn im Gegensatz dazu besteht [ein PDF] nur aus einer einzigen Datei), PDFs verfuegen auf einmal ueber CSS-Unterstuetzung (denn PDF sei einfacher online zu behalten, auch wenn das Design [...] der Firmenwebsite sich verändert), HTML kann ueber CSS hingegen aber offensichtlich nicht mehr formatiert werden, CSS kennt und beherrscht wiederum ueberhaupt keiner mehr (Designprobleme wie mit CSS), Barrierefreiheit ist ueberall implizit (schnell als PDF "gedruckt"), und WYSIWYG-Editoren wurden mittlerweile verboten ([für HTML-Unkundige] leicht zu erstellen).

Logischerweise könnte man HTML-Webseiten dann doch eigentlich demnächst komplett abschaffen. Ja. Gottseidank ist das heute alles nicht so: Richtig angewandt ist HTML cool, richtig angewandt ist CSS cool, und richtig angewandt ist PDF cool.

PDFs lassen sich auch einfacher durchsuchen, denn man kann das ganze Paket an Seiten durchsuchen und nicht nur die einzelne Seite. Und "Barierefrei" bekommt man sie ja eigentlich auch. Screenreader haben keine wirklichen Probleme damit und Vergrößerung funktioniert wunderprächtig.

Ein Nachteil wäre vielleicht die Größe, aber diese Argument wird immer kleiner je mehr DSL-Zugänge es gibt.

Solange Lynx keine PDFs anzeigen kann, werden wir wohl noch HTML-Seiten brauchen ;-)

Ich denke, dass die mittlerweile exzessive Verwendung von PDFs mehr Nach- als Vorteile mit sich bringt:

• PDF-Viewer lassen sich IMHO nicht so komfortabel wie moderne Browser bedienen, z.B. fehlen Lesezeichen, die Google-Suche, …
• Gibt es Screenreader für PDfs, die auch mit Links umgehen können? Webseiten scheinen aktuell noch barrierefreundlicher zu sein.
• PDFs sind zwar sehr schön fürs Drucklayout, aber ich möchte farbenfrohe Online-Layouts, als PDF umgesetzt, nicht unbedingt ausdrucken wollen. Es gibt Unterschiede zwischen Bildschirm- und Papierdarstellung, die sich nur schwer egalisieren lassen.
• Praktisch jede Textverarbeitung kann von Haus aus HTML-Dokumente erstellen, der PDF-Export ist allerdings momentan noch nicht selbstverständlich.
• Die Navigationsmöglichkeiten innerhalb eines PDFs sind in vielen, wenn nicht gar den meisten Fällen, äußerst eingeschränkt im Vergleich zu dem, was praktisch jede HTML-Datei bietet.

Wir wollen hier allerdings einen entscheidenden Vorteil nicht ausblenden: Es gibt deutlich weniger Sicherheitslücken in Software zur Betrachtung von PDF-Dateien als in Webbrowsern, wobei durch die eingeschränkten Scripting-Möglichkeiten ein weiterer Sicherheitszugewinn verbucht werden kann.

Generell lässt sich außerdem feststellen, dass die größten Probleme allerdings beim Zusammenspiel zwischen PDF und HTML auftreten: Links innerhalb der PDF-Datei werden im Browser geöffnet, während in HTML verlinkte PDFs bei mangelndem Plugin erst heruntergeladen werden müssen und anschließend manuell mit dem PDF-Viewer betrachtet werden können. Meine Lösung des angesprochenen Problems ist deshalb so simpel wie einleuchtend:
Die PDf-Viewer der Zukunft sollten genauso intuitiv wie Webbrowser funktionieren. Das Problem der PDF-Erstellung wird sich zukünftig wohl immer seltener ergeben, da immer mehr Büroprogramme dieses Format „kennen“. Zusätzlich müssen Druckertinte und Papier (wieder) deutlich günstiger zu haben sein, um endlich diese doppelte Arbeit für ein separates Papierlayout zu sparen.

Praktisch jede Textverarbeitung kann von Haus aus HTML-Dokumente erstellen, der PDF-Export ist allerdings momentan noch nicht selbstverständlich.

Wobei hier je nach Programm die Frage ist, ob man das Ergebnis noch als HTML bezeichnen kann.

Mit „Google-Suche“ meine ich dieses schöne Textfeld, in meinem Browser oben rechts, in welches ich einen Suchbegriff eingeben kann und mit dem Bestätigen wird dieser Text in einer Suchmaschine meiner Wahl (kann ich selbst einstellen) im Internet gesucht. „Google-Suche“ habe ich als Begriff benutzt, weil standardmäßig und bei den meisten Nutzern dort Google eingestellt ist. Mein PDF-Betrachter kann nur und ausschließlich im aktuellen PDF-Dokument suchen, nicht im Internet, und auch nur dann, wenn der Inhalt als Text und nicht als Grafik vorliegt, was es leider auch gibt.

Meine PDF-Software kann mit "Links" umgehen.

Kann deine PDF-Software den Text denn auch vorlesen und dem Benutzer Links akustisch schmackhaft machen? Weiterhin glaube ich nicht, dass PDF Möglichkeiten bietet, für Grafiken oder andere Multimedia-Inhalte alternativen Text zu definieren.

Meine PDF-Software kann farbige PDF-Dateien auch schwarz/weiß ausdrucken.

Kann deine PDF-Software auch beim Ausdruck auf die Hintergrundverzierung verzichten und Bilder ausblenden sowie Links das Linkziel hintenanstellen? Da scheint CSS doch mächtiger zu sein.

Das Web ist voll von […] PDF-Druckertreibern/Exporteuren/Distillern und sie sind oft schneller und einfacher installiert als die betreffende Textverarbeitung.

Die betreffende Textverarbeitung, meistens M$ Office oder Works, ist allerdings meist schon auf dem Rechner vorinstalliert, ein PDF-Drucker nicht.

Die Navigationsmöglichkeiten innerhalb einer PDF-Datei sind Kapitel, Sprungmarke, Suchfunktion usw. - wo ist der Unterschied zu einer HTML-Datei?

Was passiert, wenn du in einem PDF-Dokument einen externen Link, meinetwegen auch zu einem anderen PDF-Dokument, anklickst? Der PDF-Betrachter öffnet die URL im Standardbrowser, der erkennt, dass es eine PDF-Datei ist und reicht diese an den PDF-Betrachter weiter. Was passiert, wenn du in einem HTML-Dokument einen externen Link anklickst? Der Browser öffnet die URL im gleichen Fenster bzw. Tag.

Übrigens: Wenn es in einer HTML-Datei keine Anker gibt, dann ist die Navigation unmöglich, HTML-Dateien sind also nur so gut wie ihr Programmierer sie ausgestattet hat.

Wenn der Autor einen PDF-Drucker einsetzt, der mit Überschriften und Textmarken nichts anfangen kann, ist die Navigation praktisch auch unmöglich, es sei denn, du kannst auf den Piktogrammen etwas erkennen.

Wer es ernst meint mit seinen Publikationsstrategien, schreibt die Geschäftsberichte in XML und produziert dann daraus nach Bedarf die Print- und Online-Produkte. Oder?

Das glaube ich eher nicht. Vermutlich auch, weil allein die Erstellung einer entsprechenden Infrastruktur ziemlich aufwendig wäre. Diverse Systemgrenzen wären zu überwinden, diverse Entwicklungsstadien der zu erstellenden Publikation zu beachten, die grafische Gestaltung der Printausgabe kann zweifelsohne nicht automatisiert ablaufen, sondern erfordert zwingend Seite für Seite menschliche Intervention.

XML ist in diesem Prozess genauso toll oder schlecht, wie jedes andere Datenformat. Wobei es in einem Geschäftsbericht nur zu einem Drittel um die Zahlen geht. Zum zweiten Drittel geht es um erklärenden und darstellenden Text. Und das letzte Drittel sind Grafik und imagebildende Gestaltung. XML würde sich hier vermutlich hauptsächlich auf den Zahlentransport konzentrieren (für sich genommen schon eine anspruchsvolle Aufgabe), die Textverarbeitung wäre eine zweite anspruchsvolle Aufgabe, und die Gestaltung dürfte mit heute existierenden Programmen einfach mal komplett ohne XML ablaufen, weil die Profiprogramme der Gestalter einfach andere Dateiformate benutzen.

XML als Datenquelle eventuell, da habe ich keine Ahnung, was benutzt wird. Aber damit dürfte der Weg von XML im Erstellungsprozess auch recht schnell wieder enden. :)

Ach ja, die Internet-Suchmaschinen finden übrigens nicht alles, was "da draußen" vorhanden ist, im Gegensatz zur Suche nach PDF-Dateien: Wenn ich sie auf meinen Festplatten nicht gelöscht habe, dann werden sie auch gefunden.

Ah, wie man sieht, hält der Trend, sich "das Internet" sicherheitshalber lokal abspeichern zu wollen, (teilweise) immer noch an.

Klar sind PDF-Downloads schwer im Kommen. Manche Seiten sind von oben bis unten voll davon. Wer aber seine Informationen als PDF einstellt, hat eigentlich nichts davon verstanden, daß es im Hinblick auf das "Sematic Web" ja darauf ankommt, Daten zu strukturieren, um dann auf die Unterstrukturen automatisch zugreifen zu können bzw., dieselben auswerten zu können.

Und das kann man eben mit PDF-Dokumenten nicht so gut wie mit strukturierten x(ht)ml-Dateien. Aber das braucht man wahrscheinlich den meisten, die hier lesen, nicht weiter zu erklären, oder?

P.R.