Die Literaturverwaltungssoftware Citavi bietet seit ihrem letzten Update die Funktion „Website als PDF speichern“ an. Aus der Citavi-Website:
„Viele Webseiten ändern ihren Inhalt oder sind nach einiger Zeit nicht mehr erreichbar. Wäre es da nicht hilfreich, direkt bei der Titelaufnahme in Citavi eine Kopie der Webseite im PDF-Format zu erstellen? Citavi 3.0.12 bietet dieses „Schmankerl“: Werden Webseiten in Citavis Vorschau angezeigt, erstellen Sie per Klick auf den gelben Balken sofort eine PDF-Kopie vom Inhalt der Citavi-Vorschau.“
Ich befürchte, daß Citavi-Benutzern hier eine Funktion empfohlen wird, die keinen zusätzlichen Nutzen hat, sondern vielmehr sogar schaden kann. Dabei geht es um hochinteressante Fragen des zweckmäßigen Zitierens und Archivierens von Webinhalten. Martin de la Iglesia, einer der Autoren dieses Blogs, hat mich darauf aufmerksam gemacht, daß ein solches Thema nicht in 140 Zeichen zu erledigen ist — daher der folgende Beitrag.
Der fragliche Nutzen der PDF-Konvertierung zum Speichern von HTML-Dokumenten
In der Welt der Web-Browser haben sich verschiedene Funktionen zum Speichern von Websites im HTML-Format als De-Facto-Standards etabliert. Die mir bekannten Browser bieten bereits seit vielen Jahren an, jede Seite als HTML-Dokument zu speichern. Zudem bieten sie an, alle in das HTML-Dokument eingebundenen oder zum Anzeigen benötigten Elemente mit herunterzuladen und in einem automatisch erzeugten und verknüpften Ordner abzulegen. Auf diese Weise läßt sich per Mausklick quasi eine lokale Kopie eines Website-Ausschnitts erstellen, die sich offline meistens genau so betrachten läßt wie das Original.
Daneben bieten mittlerweile mehrere Webdienste die Funktion an, beliebige Seiten öffentlich und transparent zu spiegeln — anders als bei einer reinen Offline-Kopie macht dies für Dritte nachvollziehbar, auf welche einstmals abrufbaren Seiten man sich bezieht. Bekannte Dienste dieser Art sind etwa WebCite (Beispiel), Internet Archive Wayback Machine und Diigo (Beispiel).
Warum nun all diese Funktionen und Dienste zum Speichern oder Spiegeln von HTML-Dateien? Ist es nicht umständlich, das originalgetreue Aussehen einer zu zitierenden Website oft erst mittels mehrerer Dateien zu repoduzieren? — Wer gewissenhaft mit seinen Quellen umgeht dürfte sich die Frage kaum ernsthaft stellen: Das getreue Abbild einer digitalen Quelle ist nur dessen unveränderte Kopie, Byte für Byte.
Einzige Ausnahme: Ggf. müssen einige absolute Pfade im HTML-Dokument in relative Pfade umgewandelt werden. Umständlich ist daran nichts, denn die o.g. Browserfunktionen und Webdienste schützen uns ja gerade davor, uns mit den Details zu beschäftigen, mit Dateien zu hantieren o.ä. — Kann es trotzdem sein, daß die getreue Online- oder Offline-Kopie anders dargestellt wird als vom Urheber beabsichtigt? Nicht, soweit der Urheber in standard-getreuem HTML veröffentlicht. Dafür sollten seine Autorenwerkzeuge oder sein Herausgeber sorgen — andernfalls hat er auch schon jenseits der Kopienfrage ein Problem, denn jeder Browser könnte seine Publikation eventuell unterschiedlich abbilden.
Der potentielle Schaden durch PDF-Konvertierung zum Speichern von HTML-Dokumenten
Bis hierhin könnte man sagen:
- Wer es mit dem Zitieren ganz genau nimmt kopiert HTML als HTML.
- Vorausgesetzt, man begnügt sich mit einer — für Dritte nicht nachvollziehbaren — Offline-Kopie, und weiter vorausgesetzt, bei der Umwandlung in PDF wird der Anblick festgehalten, den das HTML-Dokument heute in einem modernen Browser bietet, schadet die Funktion nicht.
Genau letzteres bezweifle ich jedoch. Um mit einer Quelle auf meinem Rechner vernünftig arbeiten zu können, muß ich sie schnell und zuverlässig finden und ebenso schnell und einfach Teile daraus kopieren können.
Beginnen wir mit der Auffindbarkeit der Quelle. Citavi verfügt zwar über eine PDF-Suche — doch was ist, wenn ich damit gerade mal nicht arbeite? Wenn ich z.B. mit der betriebssystem-internen Suche arbeite, da ich gleichzeitig auch noch persönliche E-Mails oder Dokumente durchsuchen will, die von Citavi nicht indexiert werden? PDF für die Stichwortsuche zu indexieren ist generell fehleranfälliger als bei Dokumentformaten, die auf XML basieren. (In der Wikipedia stünde vor diesem Satz „Dieser Artikel oder nachfolgende Abschnitt ist nicht hinreichend mit Belegen ausgestattet“… Sorry, ich mache mich auf die Suche und reiche Belege nach, wenn LeserInnen dieses Blogs dies bezweifeln. Ich bitte ggf. um Kommentierung hier im Blog.)
Und was ist, wenn ich meine Quelle gefunden habe? Jeder, der schon mal versucht hat, größere Mengen an Text oder gar Tabelleninhalte aus einem PDF-Dokument zu kopieren weiß, daß dies kein weiterverarbeitungsfreundliches Format ist. Ein gewöhnlicher Web-Browser bietet zudem beim Betrachten eines HTML-Dokuments nützliche Zusatzfunktionen, die beim Betrachten eines PDFs fehlen.
Allgemeiner formuliert: Es droht Informationsverlust
HTML-Dokumente sind relativ strukturiert und transparent aufgebaut. Eine Konsequenz daraus ist, daß sie sich nach Belieben in viele andere Formate verarbeiten lassen, u.a. in PDF. Für PDF gilt das umgekehrt jedoch nicht. Jedes mal, wenn man ein Dokument aus einem verhältnismäßig strukturierten Format in PDF umwandelt, geht man ein hohes Risiko ein, Informationen unwiederbringlich zu verlieren.
Softwareentwickler haben in den vergangenen Jahren und Jahrzehnten eine Menge Arbeit in die Entwicklung von Anwendungen zur Volltextsuche, Extraktion strukturierter Textelemente etc. aus PDFs gesteckt. Der britische Naturwissenschaftler Duncan Hull hat vor zwei Jahren in einer wunderbaren Vortrags-Folie festgehalten, wie verrückt das ist: Wissenschaftsautoren verarbeiten die Kuh zu einem Hamburger, wollen dann aber die Kuh zurück haben…
Wissenschaftsautoren verlustbehaftete Webarchivierung empfehlen — können oder dürfen wir das?
Die Wissenschaftsöffentlichkeit ist freilich ein komplexes System. Insbesondere Autoren, deren Werke begutachtet oder veröffentlicht werden müssen, können sich nicht immer und ohne weiteres aussuchen, in welchen Formaten dies geschieht.
Bei der Archivierung zwecks persönlicher wissenschaftlicher Weiterverarbeitung ist das ganz anders. Hier kann ich mich für die zweckmäßigste und zugleich nachhaltigste Vorgehensweise entscheiden: HTML-Seiten zu kopieren, statt sie (nur) in PDF konvertiert zu „archivieren“. Mit einem Produkt, daß den Benutzern etwas anderes nahelegt, habe ich schlimme bibliothekarische Bauchschmerzen.
Was nun?
Nach dem oben gesagten mag es überraschend klingen, aber: Gegen eine PDF-Konvertierungsfunktion in einem Literaturverwaltungsprogramm habe ich grundsätzlich nichts einzuwenden. Aus den oben genannten Gründen halte ich es nur für problematisch, wenn die Platzierung und Beschreibung dieser Funktion nahelegt, daß es zweckmäßig oder normal sei, HTML-Dokumente zum Abspeichern und späteren Weiterverarbeiten zunächst in PDF-Dateien zu konvertieren.
Die Entwicklung von Literaturverwaltungsprogrammen hat gerade im Bereich der Webzitierung noch jede Menge Raum für Innovation. Wie wäre es etwa, die Literaturverwaltung im Hintergrund eine zitierbare Webkopie mit WebCite, Wayback oder Diigo (s.o.) anlegen zu lassen, auf die dann im Quellennachweis automatisch ebenfalls verwiesen wird?
Filed under: Daten, Formate & Schnittstellen, Software & Tools, Theorie & Visionen, Citavi, Feature, Geschlossene lokale Systeme, PDF, Website-Konvertierung
Dörte Böhner
Martin de la Iglesia
Lambert Heller
Jana Votteler
Jürgen Plieninger
Liane Haensch
Gastautor/-in
Matti Stöhr
Philipp Zumstein
Literaturverwaltung 
Stimme grundsätzlich zu, aber PDF-Konvertierung ist plattformunabhängig (z.B. Safari .webarchive macht Probleme auf Windowsmaschine), und PDF lässt sich einfach prima ausdrucken (Webseiten bieten in den seltensten Fällen ein entsprechendes Stylesheet). Beim Verschicken möchte man sicher sein, dass Adressat Datei auch öffnen kann, Webarchive müsste man ggf. komprimieren – auch da Problempotential beim Plattformwechsel.
1. Plattformunabhängigkeit – Ich bezweifle, daß man PDF als im engeren Sinne plattformunabhängig bezeichnen kann. Ich lese z.B. gern mal unterwegs mit einem Mobilgerät. Die meisten Websites passen sich automatisch der geringen Anzeigenauflösung an, ein PDF bleibt hingegen wie es ist, d.h. praktisch unlesbar. Vom exakten Kriterium für Plattformunabhängigkeit, d.h. langfristige Archivierbarkeit, mal ganz zu schweigen, die erfüllt derzeit noch fast kein PDF auf freier Wildbahn, übrigens auch nicht die von den meisten Wissenschaftsverlagen (oder Citavi!) produzierten PDFs…
2. Ausdruckbarkeit – Es entspricht zwar nicht meiner Erfahrung (bei druckungeeignetem Stylesheet ist auch die PDF-Ausgabe druckungeeignet), aber meinetwegen. Nur: Dann wandele ich die Website um, wenn ich sie ausdrucken will – und nicht schon von vornherein, nur um sie abzuspeichern.
3. Verschickbarkeit – In unserer web-geprägten Welt ist es am einfachsten und vor allem am wenigsten fehleranfällig, wenn ich Links verschicke. Oder?
1. Mit dem Browser, WebCite, Wayback und Diigo kann ich nicht komfortabel eine lokale Kopie erzeugen und diese innerhalb des Programms (Citavi etc.) nutzen. Und lokale Speicherung ist nun mal eine häufige Anforderung der Nutzer.
2. Außerdem ist es in einigen Fällen (z.B. für die Weiterverarbeitung/Archivierung) einfach praktischer, ein pdf zu haben. Und nicht ein ganzes Bündel von HTML-, CSS- und Javascript-Dateien wie z.B. bei Zotero.
3. Zur Frage „Wissenschaftsautoren verlustbehaftete Webarchivierung empfehlen — können oder dürfen wir das?“: Oh ja! (Wenn das genau den Anforderungen entspricht und solange es keine besseren/praktikablen Lösungen gibt.)
1. Eine lokale, wirklich eigene Kopie will man auch haben – das bestreite ich nicht.
2. Das verstehe ich eben nicht. Diese HTML-, CSS- und Javascript-Dateien habe ich ja im Web auch, und die stören mich nicht, weil ich sie als Dateien gar nicht sehen. Bei meiner lokalen HTML-Kopie auf dem Rechner ist es auch so. Ist das „einfach praktischer“ mehr als eine Suggestion dieses PDF-Dateiformats?
3. Siehe oben: Ich erkenne einfach die Bedarfslücke nicht, die so eine PDF-Konvertierungsfunktion füllt.
Ich spreche jetzt mal für die Anwender, die ich kenne:
1. Immer eine lokale Kopie, in einigen Fällen _auch_ online.
2. Es ist unpraktisch, eine HTML-Kopie zu verschicken. Email und pdf sind die Standard-Tools.
@alofro (vgl. https://twitter.com/#!/alofro/status/52679760844828672) Ich bin ein großer Freund des Screenshots — m.E. ist das aber was ganz anderes, denn Screenshots setze ich redundant ein, um mir oder anderen etwas (visuell) zu zeigen, das ich nicht (nur) verbal zitieren oder beschreiben kann.
Lieber Herr Heller
Vielen Dank für die informierte und konstruktive Kritik an der neuen Citavi-Funktion. Ich gebe Ihnen recht:
– Eine Konvertierung zu PDF führt (wie nahezu jede Konvertierung) zu Informationsverlust. (Das gilt natürlich für jedes Ausgangsformat, ob das PDF nun aus Word, InDesign oder HTML heraus erstellt wird.)
– PDF ist nicht weiterverarbeitungsfreundlich. Wir haben im Citavi PDF-Viewer zwar einigen Aufwand betrieben, um zum Beispiel Zeilenenden von Absatzenden unterscheiden zu können, aber grundsätzlich ist PDF in der Tat ein „Hamburger“.
In diesem Sinne wäre es uns in der Tat lieber, eine lokale HTML-Kopie zu speichern. Wir haben diesen Weg längere Zeit verfolgt, aber leider ohne Erfolg. Entweder lassen sich die entsprechenden Browser-Befehle nicht automatisiert aufrufen, oder sie funktionieren nicht zuverlässig, oder es handelt sich um proprietäre Formate. Unser Wunschkandidat wäre das MHT-Format, das als RFC2557 einigermassen standardisiert ist. Leider gab es damit so viele technische Probleme mit dem Internet Explorer, dass wir darauf verzichten mussten.
Auf Drittanbieter wie die von Ihnen genannten Webcite & Co. zu verweisen, nehmen wir als Anregung gerne entgegen. Als Standardlösung für Alltagsanwender scheinen sie uns nicht geeignet, vor allem weil viele Anwender explizit eine lokale Kopie wünschen. Zudem haben wir Zweifel hinsichtlich der Benutzerfreundlichkeit. Ein weiteres Problem: Die Anwender können innerhalb der Citavi HTML-Vorschau browsen. Ob sich beim Browsen innerhalb einer Site auch die URL ändert, ist dem Webentwickler überlassen, darauf hat Citavi keinen Einfluss. Wir können den genannten Diensten aber nicht das aktuelle HTML schicken, sondern nur die aktuelle URL. (Am Beispiel von google.maps: In der Adresszeile des Browsers steht für jeden Ort der Welt nur „http://maps.google.com“. Wir würden dem Dienst diese URL senden und der Anwender würde damit auf Webcite eine ganz andere Webseite speichern als er in Citavi sieht.) Vergleichbare Probleme ergeben sich bei Seiten, die Frames verwenden oder die passwortgeschützt sind.
Den Ausschlag gegeben haben letztlich Argumente der Einfachheit und Benutzerfreundlichkeit. Es verhält sich wie bei der E-Mail-Signierung und Verschlüsselung: Wir PowerUser wissen, dass jeder Serveradministrator unsere Liebesgrüsse mitlesen kann und dass wir unsere E-Mails signieren bzw. verschlüsseln sollten. Wie viele Alltagsanwender kennen Sie, die das tun? – Ich persönlich nicht einen einzigen. So wie alle E-Mail-Programme den Versand unverschlüsselter E-Mails erlauben, weil es für die Anwender einfach und unkompliziert ist, so bieten wir auch die PDF-Konvertierung an. Nicht als theoretisch beste Lösung, sondern als praktisch von vielen Anwendern gewünschten und gangbaren Weg.
Thomas Schempp
Entwicklungsleiter von Citavi
Lieber Herr Schempp,
vielen Dank für Ihren raschen und aussagekräftigen Kommentar! Daß Sie das Anlegen von HTML-Kopien zunächst favorisiert und erst nach längerer Zeit verworfen haben spricht für Citavi und dessen Entwicklungsprozeß.
Daß viele Websites nicht konsequent REST-URLs verwenden (also in der URL nicht genau codiert wird, was abgerufen wird, wenn man diese URL abruft), ist in der Tat eine Grenze der beschriebenen webbasierten Webzitationsdienste, von zugangsgeschützten Webinhalten einmal ganz zu schweigen.
Und leider kann ich den anderen Punkt, Ihre Probleme mit der Art, wie MHT implementiert wird (oder nicht implementiert wird — daneben gibt es ja anscheinend noch mindestens einen weiteren konkurrierenden Standard), ebenfalls nachvollziehen.
Was bleibt, sind meine Zweifel an der Platzierung und Empfehlung des Konvertierungs-Features in Citavi. Um ihren Vergleich mit der E-Mail-Verschlüsselung aufzugreifen: Am Mailclient meiner Wahl, Mozilla Thunderbird, schätze ich nicht zuletzt, daß die Empfehlung eines komfortablen Verschlüsselungs-Plugins (Engimail) gerade mal einen einzigen Mausklick von der Startseite entfernt ist. (Ich benutze Enigmail seit vielen Jahren praktisch täglich.) Um das Bild, etwas waghalsig, zurück in die Welt der Literaturverwaltung zu übersetzen: Ich würde mir wünschen, daß der Benutzer auch auf die potentiellen Defizite einer solchen Konvertierung zumindest hingewiesen wird. Idealerweise kombiniert mit einer webgerechteren — und dafür nicht immer funktionierenden — Webarchivierungs-Funktion, meinetwegen in einem Menüpunkt versteckt für die „Experten“. Citavis Enigmail, gewissermaßen. 😉
Lambert Heller
Ich bin neu in diesem Segment und habe meine Probleme mit der Nachvollziehbarkeit des „Informationsverlusts“, da auf den in dem Beitrag nicht wirklich eingegangen wird. Es wird zwar geschrieben, dass es einen gibt, aber welche Art der Informationsverluste (abseits der genauen grafischen Darstellung) gibt es? Inhaltliche? Das wäre durchaus fatal.
Ich habe selten das Bedürfnis, Webseiten lokal zu speichern. Kann aber das Argument mit dem Informationsverlust auch nicht recht nachvollziehen. Ich vermute mal, dass die PDF-Konversion auf einer Druckansicht basiert, d.h. damit kann man das sichern, was in dem Moment ausdruckbar war. Damit entspricht doch die lokale Kopie dem, was ich in meiner Zitation festhalte als Datum „zuletzt abgerufen …“.
Die vielen Dateien der HTML-Seite in lokaler Kopie sind auch nur dann nicht sichtbar, solange man die Verwaltung komplett Citavi überlassen würde, alles Eigenhändige muss sich mit dem Sammelsurium rumschlagen.
Auch das mit dem Text Herauskopieren klingt für mich mehr wie ein theoretischer denn wie ein praktischer Einwand. Es mag zwar sein, dass PDF ein „Burger“ ist, aber die Dinge, die da schwierig sind, wie z.B. Spaltenlayout, trifft man ja in der Regel in HTML nicht an.
Hhm, Ihre Einlassung hätte mehr Gewicht, finde ich, wenn Sie sie mit ein paar konkreten Erfahrungen belegt hätten. Beispiel: Zu seligen WindowsXP-Zeiten habe ich zur Desktop-Suche Copernic verwendet. Das hatte aber überhaupt keine Mühe mit den PDF-Dokumenten. Hatten Sie mit derlei schon mal Probleme, oder ist der Hinweis auf die Verarbeitung auch nur Theorie?
Sehr schön. Ich möchte noch zu einer grundsätzlichen Zurückhaltung bei PDFs raten. Z.B. ist es sehr unschön, Teile einer Website (im Original) nur als PDF zur Verfügung zu stellen—so sieht man regelmässig Firmensites, die nur rudimentären Informationen in HTML anbieten und dann benutzerunfreundlich auf PDF-Broschüren linken/hinweisen. Z.B. muss man sich bewusst sein, dass PDF ein Darstellungsformat ist und dass man der größeren Flexibilität halber, wenn möglich, das Fokus auf die Originalformate haben sollte, um PDF wirklich nur zum Anschauen zu benutzen.
(Leider hat die große Verbreitung von Programmen mit einer unsauberen Trennung zwischen Inhalt und Darstellung, etwa MS Word, dazu geführt, dass allzu Viele diese Trennung gar nicht mehr verstehen.)
Vielen Dank für diese wichtige Ergänzung! Daß sich HTML (auch LaTeX u.a.) zur einfachen, transparenten Strukturierung von Inhalten eignet, und daß andere Dokumentformate dazu eben ungeeignet sind, ist der Kern der Sache. Dieses Wissen zu vermitteln ist natürlich wichtiger als meine etwas plumpe Warnung vor PDF oder der PDF-Konvertierung.
Ich möchte nicht als PDF-Apologet missverstanden werden. Aber die hier in den Kommentaren angerissenen Probleme lassen eine solche lokale Archivierung als „kleineres Übel“ erscheinen. Webseiteninhalte und URLs sind instabil, Frames (auch bei Digitalisierungsprojekten) präsenter als man meinen sollte. Wichtig ist auch der Hinweis von michaeleriksson über die weite Verbreitung von Programmen mit unsauberer Trennung von Inhalt und Layout und ihre Folgen. Viel Anlass zu Optimismus gibt es da nicht, zumal proprietäre Formate nach meinem Eindruck wieder auf dem Vormarsch sind (Apps etc.)
Ich versuche den Informationsverlust durch Konvertierung von HTML nach PDF mal an einem Beispiel zu erläutern.
Um das Beisiel nachzuvollziehen werfen Sie bitte einen Blick auf die schöne Übersicht unter http://en.wikipedia.org/wiki/Comparison_of_reference_management_software und klicken Sie dann auf die Wikipedia-interne PDF-Konvertierung (linke Spalte, unter „Print/export“).
Das ist übrigens ein für Freunde des PDF-Formats sehr günstig angelegter Testfall, denn was, wenn nicht die Website-eigene Konvertierung, sollte dazu in der Lage sein, eine gute PDF-Datei zu erzeugen?
Die fertige PDF-Datei sieht zunächst einmal, finde ich, ganz hübsch aus. Die Links in dem Dokument sind anklickbar. Die Sortierbarkeit der Tabelle ist verlorengegangen, was unter Archivierungs- unsd Zitier-Gesichtspunkten zu verkraften ist.
Aber: Die Textstruktur, darunter die in diesem Fall entscheidende Tabellenstruktur, können Sie nur noch im PDF selbst betrachten, so als wäre das ein Screenshot den Sie in einem Grafikprogramm betrachten. Als normal ausgestatteter PC-Benutzer werden Sie diese Textstrukturen dort nicht mehr herausbekommen.
Probieren Sie es bitte mal aus: Übernehmen Sie per Copy-and-Paste ein Stück daraus, sagen wir: Von der ersten Zwischenüberschrift („General“) bis einschließlich der zweiten Zeile in der Tabelle.
Bei mir sieht das Ergebnis so aus:
General
In the „notes“ section, there is a difference between:
• web-based, referring to applications that may be installed on a web server (usually requiring MySQL or another
database and PHP, perl, Python, or some other language for webapps)
• centrally-hosted website
Software Developer First public
release
Latest stable
version
Cost (USD) Open
source
License Notes
2collab Elsevier 2007-11
? Free No
proprietary centrally-hosted website, no
longer accepting new accounts
Ich will versuchen, einmal alle verlorengegangenen Informationen in diesem kurzen Abschnitt aufzuzählen:
1. Die Zwischenüberschrift „General“ ist nicht mehr als solche erkennbar.
2. Hinter „requiring“ kommt ein Absatz, der im HTML-Original natürlich nicht vorhanden ist.
3. Auch mit reparierten Absatzmarken: Die Einrückung der Stichpunkte geht verloren. Selbst wenn ich das Textstück in ein leeres Word-Dokument einfüge und hinter dem Stichpunkt die Enter-taste drücke, schlägt mir Word nicht vor, den Punkt in einen eingerückten Stichpunkt zu verwandeln. Was immer dieses Sonderzeichen sein mag, das beim Kopieren mitgekommen ist – seine strukturierende Eigenschaft als Stichpunkt mit Einrückung hat es verloren.
4. Die Hervorhebung der Begriffe „web based“ und „centrally-hosted website“ ist verloren gegangen. (Diese Hervorhebung hier als solche ist eine Information, die diesen Artikelanfang entscheidend strukturiert.)
5. Bei dem Wort „Software“ beginnt eine Tabelle (!) – diese Information ist komplett verloren gegangen.
6. Das Wort „Software“ ist eigentlich hervorgehoben – in meiner Kopie nicht mehr. Von der anderen Art der Hervorhebung (fett statt vorhin kursiv) einmal ganz zu schweigen.
7. Hinter „First public“ erscheint auf einmal ein Zeilenumbruch, dann wieder hinter „release“, etc. – kurz gesagt, selbst wenn ich die Tabelle noch als solche „wiederentdecke“, habe ich noch nicht einmal einen Anhaltspunkt für die Begrenzung der Tabellenzellen und -zeilen.
Digitale Kopien eines Dokuments speichert man im Regelfall im Literaturverwaltungsprogramm, um die enthaltenen Informationen später einmal weiter zu verwenden. Ich hoffe es ist hinreichend deutlich geworden, wie groß der Informationsverlust ist, den man in diesem Fall durch die PDF-Konvertierung erlitten hätte. Ich vermute fast, das Abtippen eines Ausdrucks wäre in diesem Fall einfacher gewesen, als die Fehler in der digitalen Kopie per Hand zu korrigieren…
Und das, obwohl hier wie gesagt ein verhältnismäßig schönes PDF generiert wird. Ich versuche immer wieder, Text aus PDF-Versionen wissenschaftlicher Aufsätze zu kopieren, und erlebe dann, wie ganze Zwischenüberschriften oder Worte mit Sonderzeichen in Buchstabensalat zerfallen, Trennstriche mitgenommen werden etc.
Öffnen Sie den Wikipedia-Artikel bitte abschließend noch einmal in Mozilla Firefox und speichern Sie Ihn mit „Seite speichern unter“ – „Website, komplett“ ab. Sie haben dann eine voll funktionstüchtige Kopie auf Ihrem Rechner, selbst die Sortierfunktion der Tabellen bleibt intakt. Wie groß und unübersichtlich ist das „Sammelsurium“ der Dateien, daß hierfür heruntergeladen wird? Ich weiß es offen gesagt nicht, denn das regelt alles der Browser für mich. Der ganze Vorgang ist schneller und einfacher als die PDF-Konvertierung. Und ohne nennenswerten Informationsverlust – das ist das i-Tüpfelchen darauf.
Erst mal herzlichen Dank an Lambert für den Beitrag im Kampf gegen die Unstrukturiertheit von wissenschaftlichen Texten ;-). Ich möchte auch nur noch etwas polemisch ergänzend nachfragen, ob nicht eigentlich die lokale Speicherung von Texten zunehmend obsolet und kontraproduktiv wird / werden sollte. Voll Neunziger, sozusagen. In Zeiten von Langzeitarchivierung, Cloud, DOIs, Repositories etc.pp. ist die schnelle und stabile Verfügbarbeit der in der Literaturverwaltung referenzierten Texte gegeben. Und hinsichtlich der Indexierung und Durchsuchbarkeit tut sich auch einiges. So durchsucht bspw. Google mittlerweile auch (bei Benutzung von Chrome) die lokalen Bookmarks und stellt sie bei den Suchergebnissen nach oben. Lokale Speicherung — v.a. die via PDF, aber m.E. auch die per Websitearchivierung oder HTML — ist fehleranfällig, macht wichtige Informationen, Metadaten unzugänglich oder verfälscht sie gar und ist zumindest langfristig arbeitsintensiver.
Wir haben vielleicht ein wenig aneinander vorbei diskutiert. Ich meine nicht Wikipedia oder andere Quellen mit hoher Zitierfähigkeit und Nachvollziehbarkeit einzelner Versionen und für Langzeitarchivierung konzipierten Standards, sondern Kopien von Texten auf ganz normalen Webseiten, die dann auf dem eigenen Rechner eine Art „Privatarchiv“ bilden (im Sinne eines Screenshots mit Zeitstempel mit lesbarer Darstellung im Ausdruck, durchsuchbarem Text und anklickbaren Links). Da es unsicher ist, ob daraus erstellte Webarchive Standards genügen, die auch nach einiger Zeit noch maschinenlesbar ist (Sie sind es ja z.T. bereits jetzt nicht bei Plattformwechsel), finde ich die Implementierung dieser Funktion in Citavi begrüßenswert, weil sie der Realität Rechnung trägt. Wünschenswert ist das natürlich nicht und Zitierfähigkeit ist ein anderes Thema (obwohl ja nicht selten auch Manuskripte und Typoskripte zitiert werden – ohne Angabe, wo man sie einsehen kann).
[…] kann. Während sich bestimmt zahlreiche Anwender darüber freuen dürften, gibt es Kritik im Blog Literaturverwaltung & Bibliotheken. Lambert Heller verweist auf bessere Möglichkeiten zur Speicherung der aktuellen Version der […]
[…] Ein Klick, und nicht nur die Quellenangaben, sondern auch das dazugehörige PDF (wenn verfügbar) oder die HTML-Seite (“Screenshot”) landen auf der eigenen Festplatte. Wer mag kann die Quellenangaben taggen, in Listen sortieren, mit eigenen Notizen ergänzen, detailliert durchsuchen, auf Dubletten prüfen und anderes mehr. Die PDF-/HTML-Sammlung läßt sich mit Zotero im Volltext durchsuchen, bibliographische Angaben lassen sich automatisch erkennen und ergänzen, in PDFs und HTML-Archiven lassen sich Markierungen und Kommentare anlegen. (Übrigens: Nicht alle populären Literaturverwaltungen können nahtlos HTML archivieren — obwohl dies für’s spätere Zitieren und Weiterverarbeiten stets vorzuziehen ist.) […]