Lässt sich der ursprüngliche WWW-Vorschlag als Word-for-Macintosh-4-Datei von 1990 heute noch öffnen?

 (blog.jgc.org)
1 Punkte von GN⁺ 2024-02-14 | 1 Kommentare | Auf WhatsApp teilen
  • Tim Berners-Lees ursprünglicher WWW-Vorschlag war ein 68.608 Byte großes Microsoft-Word-for-Macintosh-4.0-Dokument; die zentrale Frage war, ob es sich in einer modernen Umgebung möglichst originalgetreu öffnen und in PDF umwandeln lässt
  • Microsoft Word und Apple Pages scheiterten; Apache OpenOffice konnte die Datei zwar öffnen, bewahrte aber Formatierung und Diagramme nicht korrekt
  • LibreOffice öffnete das Dokument und zeigte auch scharfe Diagramme an, doch Ränder, Schriftgrößen, Kopf-/Fußzeilen und Abstände wichen vom Original ab und erforderten zusätzliche Korrekturen
  • Während das CERN-PDF von 1998 20 Seiten hat, zeigte das in Infinite Mac mit einem Macintosh der 1990er und Word geprüfte Originallayout bei A4 22 Seiten
  • Eine manuell korrigierte .odt-Datei und ein auf einem emulierten Mac erzeugtes PDF wurden auf GitHub veröffentlicht; auch 34 Jahre alte Dokumente exakt zu öffnen und zu bewahren, ist nicht einfach

Identität der Originaldatei und Ziel der Konvertierung

  • Das W3C bietet auf der Seite zu Tim Berners-Lees original WWW proposal einen Download an, der offenbar die ursprüngliche Dokumentdatei ist
  • Dieser Download war mit dem Hinweis „I think - I can't test it“ versehen; außerdem gibt es separat eine RTF-Version und eine 1998 aus der Originaldatei erzeugte HTML-Version
  • Der file-Befehl auf dem Mac identifiziert das Originaldokument als Microsoft-Word-for-Macintosh-4.0-Datei
  • Auch eine Notiz auf der W3C-Seite hält fest, dass es sich um das ursprüngliche MacWord- bzw. Word-for-Mac-Dokument handelt, das im März 1989 erstellt und – abgesehen von einem hinzugefügten Datum im Mai 1990 – unverändert erneut bereitgestellt wurde
  • Ziel war es, das Originaldokument zu öffnen und, wenn möglich, in ein modernes Format wie ein PDF mit hoher Wiedergabetreue zu konvertieren

Ergebnisse mit moderner Software

  • Um es zunächst mit Microsoft Word zu versuchen, wurde die Dateiendung .doc ergänzt, die Datei auf OneDrive hochgeladen und dort geöffnet
  • Auch Apple Pages verstand die alte Microsoft-Word-for-Macintosh-Datei nicht
  • Apache OpenOffice konnte die Datei öffnen, doch die Formatierung ging verloren und die Diagramme fehlten
  • LibreOffice öffnete die Datei und zeigte auch die Diagramme scharf an
    • Allerdings waren die Ränder merkwürdig und weitere Formatierungsprobleme blieben bestehen

Unterschiede zwischen CERN-PDF und LibreOffice-Ausgabe

  • CERN stellt eine PDF-Version des Vorschlags bereit
  • Dieses PDF wurde offenbar 1998 mit Acrobat Distiller Daemon 2.1 für SunOS/Solaris (SPARC) erzeugt und umfasst 20 Seiten
  • Die in LibreOffice importierte Version hatte 24 Seiten
  • Nachdem aus der LibreOffice-Version ein PDF erstellt worden war, wurde es in der Kontaktbogenansicht von Apple Preview mit dem CERN-PDF verglichen
    • In der LibreOffice-Version fehlte der rechte Rand
    • Der größte Teil des Fließtexts wurde nicht wie im CERN-PDF in 12 pt, sondern in 14 pt angezeigt
    • Die Kopfzeile mit TBLs Initialen wurde zu einer Fußzeile
    • Anhand der Bildpositionen wirkten die Seitenumbrüche im Großen und Ganzen passend; das größte Problem schien die Schriftgröße zu sein
    • Im CERN-PDF gibt es unter der Überschrift Leerraum, in der LibreOffice-Version nicht

Überprüfung des Originallayouts per Emulation

  • Um zu prüfen, wie das tatsächliche Originaldokument aussah, wurde in Infinite Mac ein Macintosh der 1990er gestartet und das Originaldokument mit Word for Macintosh 4.0 geöffnet
  • Auf diese Weise ließen sich die tatsächlichen Schriften, Schriftgrößen und das Layout überprüfen
  • Die Prüfung auf dem emulierten Mac ergab, dass sich das Dokument auf dem ursprünglichen Mac und das CERN-PDF deutlich unterschieden
    • Das CERN-PDF hat 20 Seiten
    • Das mit Word for Macintosh 4.0 auf A4-Papier geöffnete Dokument hat 22 Seiten
  • Danach änderte sich das Ziel: Statt das CERN-PDF nachzubilden, sollte die Fassung möglichst nah an das auf dem Mac sichtbare Originaldokument herankommen

Manuelle Korrekturen und Ergebnis der Bewahrung

  • Um das LibreOffice-Dokument näher an das Original zu bringen, wurden mehrere Punkte manuell angepasst
    • Das Papierformat wurde auf A4 gesetzt
    • Der rechte Rand wurde auf dieselbe Breite wie der linke Rand eingestellt
    • Die erste Seite wurde wegen abweichender Bundstege, Fußzeilen und Kopfzeilen mit einem eigenen Format angepasst
    • Die Schriftgröße des Fließtexts wurde von 14 pt und anderen Größen auf 12 pt geändert
    • Falsch zwischen Seiten umbrochener Text und Ausrichtungsprobleme wurden manuell bearbeitet
    • Elemente, die zu Fußzeilen geworden waren, wurden wieder zu Kopfzeilen korrigiert
  • Das Endergebnis kam dem auf dem Mac sichtbaren Dokument recht nahe
  • Die konvertierte .odt-Version wurde in ein GitHub-Repository hochgeladen
  • Die Arbeit zeigt, wie schwierig es ist, alte Dokumente in modernen Formaten zu bewahren, und dass Open-Source-Software für solche Konvertierungen nützlich sein kann
  • Ursprünglich ging es darum, hochwertige Diagramme aus dem ursprünglichen Vorschlag für eine Präsentation zu erhalten, doch der Aufwand war größer als erwartet

Zusätzliches PDF aus einem emulierten Mac

  • In einem Hacker-News-Kommentar wurde vorgeschlagen, mit einem emulierten Mac eine PostScript-Datei oder ein PDF zu erstellen
  • Mit System 7, Word von 1992 und dem Druckertreiber Print2PDF, der PDF-Dateien erzeugt, wurde direkt aus Word for Macintosh 5.1a ausgegeben
  • Auch das auf diese Weise erzeugte PDF wurde zu GitHub hinzugefügt
    • Diese Version hat 20 Seiten
    • Die Schriftarten sind anders, aber die ursprüngliche Anforderung, ein PDF zu erzeugen, wird erfüllt
  • Ein weiterer Hacker-News-Kommentar verweist auf ein Beispiel, bei dem mit anderen Word-Versionen und Anpassungen eine gute Konvertierung in ein modernes Format erstellt wurde

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-02-14
Kommentare auf Hacker News

  • Für alle, die es interessiert: Ich habe ein Dokument im modernen Word-Format hochgeladen, bei dem Vektor-Artwork und Schriften erhalten geblieben sind: https://jasomill.at/proposal.docx
    Die Konvertierung lief so: auf einem per QEMU emulierten Power Mac in Word 98[1] öffnen und erneut speichern, anschließend in modernem Word for Mac 16.82 öffnen
    Allerdings fehlten die Bilder, und Word meldete: „There is not enough memory or disk space to display or print the picture.“ Das wirkt aber weniger wie ein RAM-Problem, sondern eher so, als unterstütze Word das PICT-Bildformat nicht mehr
    Die Bilder habe ich wiederhergestellt, indem ich in Word 98 über den PDF-Drucker von Acrobat 5.0.10 ein PDF erstellt, die drei Bilder jeweils mit modernem Adobe Illustrator als PDF extrahiert und dabei ursprüngliche Schriften, Vektoren, Größen und Bounding Boxes beibehalten und sie dann aus dem Finder per Drag-and-drop eingefügt habe
    Zum Vergleich: Das mit Acrobat aus Word 98 auf dem Power Mac erzeugte PDF ist https://jasomill.at/proposal-Word98.pdf, und das von modernem Word unter macOS Sonoma erzeugte PDF ist https://jasomill.at/proposal-Word16.82.pdf
    [1] https://archive.org/details/ms-word98-special-edition

    • Ich frage mich, ob du versucht hast, die Bilder separat zu extrahieren und mit einem anderen Programm direkt zu konvertieren. Laut Archive Team kann LibreOffice Vektor-PICT-Dateien lesen[1] und auch als SVG speichern
      Wenn Text enthalten ist, bleiben natürlich weiterhin Schriftprobleme, aber auf die Idee, Vektoren über PDF zu erhalten, wäre ich nicht gekommen, und PDF kümmert sich auch gut um das Einbetten von Schriften
      [1] http://fileformats.archiveteam.org/wiki/PICT
    • Nebenbei: MacClippy 98 wusste schon, was los war: https://jasomill.at/Clippy.png
    • Der Beruf des digitalen Archäologen, wie man ihn aus der Science-Fiction kennt, wird langsam Realität
    • Ich hätte nicht erwartet, in einem so alten Dokument den LHC zu sehen
      Soweit ich es während der Arbeit kurz nachschlagen konnte, habe ich nicht herausgefunden, wann das LHC-Projekt begann und ob es 1990 bereits relevant war; dass das 20 Jahre vor der tatsächlichen Inbetriebnahme war, fühlt sich jedenfalls deutlich länger an, als ich erwartet hätte

  • „Man kann die tatsächlichen Schriften, Schriftgrößen und das Layout sehen und prüfen, wie das Dokument hätte aussehen sollen“ gilt nur, wenn man die Originalschriften hat
    Word 4.0 erschien für System 6 und unterstützte zurück bis System 3.2; damals gab es für Schriften separate Dateien für den Bildschirm und für Drucker, je nach Ausgabeauflösung
    Wenn die Druckerschrift fehlte, wurde die Bildschirmschrift per Nearest-Neighbor-Verfahren vergrößert und gedruckt; wenn die Bildschirmschrift fehlte, wurde auf die Systemschrift zurückgegriffen. Wie im Screenshot zu sehen, war Geneva der Standard
    In diesem Fall braucht man nur die bekannten Palatino und Courier, aber LibreOffice ersetzte Palatino durch Times New Roman, obwohl Palatino Linotype installiert war

    • Vermutlich liegt das daran, dass der interne Name von Palatino Linotype in der Windows-Bundle-Version PalatinoLinotype ist, in der Adobe-OpenType-Version aber PalatinoLTStd
      Ohne hartcodierte Ausnahmen kann Schriftabgleich anhand gemeinsamer Präfixe leicht unpassende Ergebnisse liefern. Zum Beispiel könnte Lucida auf LucidaConsole gemappt werden, obwohl aus Sicht der Absicht des Dokumentautors fast jede proportionale serifenlose Schrift besser wäre
      Außerdem ist selbst exaktes Namensmatching nicht garantiert. Apple hat zweimal eine Schrift mit dem internen Namen NewYork ausgeliefert: einmal als TrueType-Konvertierung von Susan Kares ursprünglichem Macintosh-Bitmap-Design von 1983 und einmal als völlig unabhängiges Design aus dem Jahr 2019
    • Das mag solche Unterschiede bis zu einem gewissen Grad erklären, aber was ich in der Emulation hauptsächlich überprüfen wollte, waren die Schriftgrößen

  • Der leicht zu unterschätzende Held dieser kleinen Geschichte ist der alte file(1)-Befehl
    proposal: Microsoft Word for Macintosh 4.0
    Wenn ich wissen will, was eine Datei ist, nutze ich ihn fast reflexartig, und die Informationen, die er zurückgibt, sind genau ausreichend, um die Neugier zu stillen und zugleich praktisch nützlich zu sein

    • Stimme zu. file ist ein großartiges Tool
      Früher saß ich mehrmals fluchend vor einem Windows-Arbeitsrechner, weil ich dieses Tool nicht ohne Weiteres nutzen konnte. Später wurde es dank WSL angenehmer, und heute komme ich zum Glück fast ohne Windows aus

  • LibreOffice öffnet diese Datei direkt. Die Unterstützung für alte Dokumentdateiformate ist wirklich hervorragend, deshalb halte ich es für solche Zwecke weiter installiert: https://imgur.com/a/JENgq6V
    Trotzdem nutze ich auch gern die Emulatoren BasiliskII und InfiniteMac

    • Im Original stand ebenfalls, dass LibreOffice sie öffnet, zugleich aber auch, dass „die Ränder seltsam sind und es andere Formatierungsprobleme gibt“
      Diese Probleme scheinen auch im Screenshot sichtbar zu sein, und für ein so altes proprietäres Format ist die Unterstützung zwar ziemlich gut, aber mit solchen Problemen würde ich sie nicht unbedingt als „wirklich hervorragend“ bezeichnen
    • QEMU ist ebenfalls einen Versuch wert. Die aktuellen Versionen emulieren Power Macs gut und können sowohl 9.2.2, die letzte PowerPC-Version von classic Mac OS, als auch Mac OS X 10.5 ausführen
    • StarOffice gab es damals auch schon
      Da fragt man sich, ob in LibreOffice heute noch Parsing-Code für Drittanbieterformate aus den frühen 1990ern steckt, oder ob tatsächlich Kompatibilitäts- und Konvertierungscode die Arbeit macht, der durch Reverse Engineering deutlich späterer Word-Versionen entstanden ist

  • Als Beispiel für Microsofts Abwärtskompatibilität: In Word 2401 für Windows ließ sich die Datei größtenteils problemlos öffnen, und auch das Layout sah identisch mit dem PDF des Artikels aus.
    Standardmäßig war das Dateiformat zwar blockiert, die Freigabe war aber einfach.
    Allerdings fehlte der Grafikfilter für das Microsoft-Word-Picture-Format, daher wurden die Bilder nicht geöffnet. Der scheint schon vor ziemlich langer Zeit eingestellt worden zu sein, aber Word 2003 dürfte ihn wohl öffnen können, und so alt, dass es auf modernen Systemen nicht mehr lauffähig wäre, ist es auch nicht.

    • Ich habe Word 2003 installiert; mit den Standardeinstellungen wurde das Dokument sofort und perfekt geöffnet.
      Beim Speichern dort wurde es in ein modernes .doc umgewandelt und ließ sich in Office 365 öffnen und etwa in PDF konvertieren.
      Die Lehre daraus ist, dass das Windows-Office-Team offenbar etwas mehr Zeit in Abwärtskompatibilität investiert.

  • Ein Unternehmen wie Microsoft sollte es meiner Meinung nach wichtig nehmen, Dokumente öffnen zu können, die von jeder Version von Microsoft Word erstellt wurden, egal wie alt sie sind.
    Ich denke, es gibt dafür eine soziale, historische und wirtschaftliche Verantwortung.
    Wenn man sich wegen Schwachstellen in altem Parsing-Code Sorgen macht, kann man ihn in einen externen Prozess auslagern und in einer Sandbox ausführen, die ad hoc eine neue, lesbare Version ausgibt. Diese Funktion sollte man nicht einfach entfernen.
    Edit: Ich habe erfahren, dass die Desktop-Version von Word die Datei gut öffnet und nur die Web-Version es nicht kann; damit kann man diesen Beitrag als hinfällig betrachten.
    Edit 2: Das Dokument lässt sich zwar öffnen, aber eingebettete Grafiken werden offenbar nicht angezeigt oder gedruckt.

    • Viele alte Formate waren im Grunde binäre Speicher-Dumps oder unterschieden sich kaum davon.
      Formate zu dokumentieren war auch kein Standard. Ich stimme zu, dass es eine gesellschaftliche Verantwortung gibt, aber aus meiner Erfahrung mit digitaler Archivierung war früher wirklich, wirklich chaotisch. Wirklich.
    • Man muss gar nicht bis 1990 zurückgehen: Es ist leicht, Fälle zu finden, in denen moderne Microsoft-Apps, insbesondere Cloud-Apps, Probleme haben, Dokumente zu öffnen, die mit früheren Versionen erstellt wurden.
    • Mich würde ganz ehrlich interessieren, ob es ein Unternehmen gibt, das bei Abwärtskompatibilität kommerzieller Software einen besseren Ruf hat als Microsoft.
    • Alte Dateiformate enthalten Sicherheitslücken. Die Online-Version von Word ist grundsätzlich nur für docx konzipiert und kann nur einige binäre Dokumente öffnen.
    • Ich hatte übersehen, dass das echte Word diese Datei problemlos öffnet. Das Problem betrifft nur die spielzeugartige Web-Version; beim Mac könnte es zwar ähnlich sein, aber das ist eine andere Frage.

  • Wenn man genau wissen möchte, wie der Ausdruck damals aussah, könnte man in einem Emulator mit Word for Mac 4.0 eine Druckwarteschlange einrichten, die eine PostScript-Datei erzeugt.
    Diese .ps-Datei kann man in PDF umwandeln.
    Oder, falls es selbst für ein so altes OS Acrobat gibt, lässt sich mit einem virtuellen Druckertreiber vielleicht direkt ein PDF erstellen.

    • https://web.mit.edu/ghostscript/www/Ps2pdf.htm
      Wenn man selbst mehr Feintuning möchte, kann man in die Tiefen von Ghostscript eintauchen :)
      https://www.ghostscript.com
    • Ich habe noch einen Mac, auf dem Word 5.1a läuft, und persönlich halte ich das für die letzte Word-Version, die ich brauche.
      Ich meine mich zu erinnern, damit auch Word-4.0-Dateien geöffnet zu haben.
    • Guter Vorschlag. Ich habe gerade mit Print2PDF aus Word ein PDF erstellt und werde den Blog aktualisieren.

  • LibreOffice ist erstaunlich. Es kann nicht nur viele Dokumentformate öffnen, sondern über Headless-Ausführung und Kommandozeilenoptionen auch Aufgaben wie Formatkonvertierungen automatisieren.
    Solche Dinge sind auf anderem Weg oft schwierig.
    https://help.libreoffice.org/latest/en-US/text/shared/guide/start_parameters.html
    https://opensource.com/article/21/3/libreoffice-command-line

  • Es gibt ein potenzielles Problem, das Unternehmen häufig unterschätzen. Manche Unternehmen haben Backups mit unbegrenzter Aufbewahrungsdauer.
    Backups mit 10 Jahren Aufbewahrung sind üblich, manche bewahren aus rechtlichen Gründen 20 Jahre auf, aber die meisten verstehen den Unterschied zwischen „lesbar“ und „nutzbar“ nicht.
    Je nach Daten gibt es auch Unternehmen, die komplette virtuelle Maschinen unbegrenzt sichern und glauben, sie später wieder ausführen zu können. Schon eine vSphere-5.x-Maschine in einem aktuellen vSphere 8 wiederherzustellen ist schwierig genug; diese Platzverschwendung verstehe ich nicht wirklich.

    • Wenn man alles sichert, kann man es später aufräumen, und am Ende muss man es gar nicht aufräumen. Bei Google Cloud kostet 1 TB Speicher 1 Dollar pro Monat.
      Bei diesem Preis lohnt sich Aufräumen nicht. Ein DevOps-Mitarbeiter kostet mehr als 100 Dollar pro Stunde, und die Opportunitätskosten dafür, dass er statt produktiverer Arbeit langweiliges Aufräumen macht, sind dabei noch nicht einmal eingerechnet.
      Wenn das Unternehmen übernommen wurde oder genug Zeit vergangen ist, kann man die Daten ohne Aufräumen löschen oder wegwerfen.
      Auch bei virtuellen Maschinen kann man, etwa bei VMDK, die Rohdisk lesen, ohne sie zu booten. Es lohnt sich nicht, für 10 Dollar Ersparnis pro Monat Datenverlust zu riskieren; das entspricht ungefähr einem zusätzlichen Bier, das ein Entwickler bei einem Teamevent trinkt.
    • Alte Dateien oder Disk-Images sind im Vergleich zu heutigen Dateigrößen oft klein.
      Deshalb ist es weniger eine Platzverschwendung als eher Verwaltungsaufwand.

  • Eine gute Warnung, die zeigt, wie schnell Formate veralten und wie gefährlich insbesondere proprietäre Formate sind
    Für langfristig aufzubewahrende Dokumente verwende ich Markdown, Klartext und PNG
    Selbst wenn diese Formate verschwinden sollten, wäre es einfach, die Parser selbst neu zu implementieren

    • Eine Markdown-Parser-Implementierung ist keineswegs trivial
      Es ist leicht, einen Parser zu bauen, der sich in einfachen Fällen wie ein Markdown-Parser verhält und Leute glauben lässt, er würde parsen; ein echter Parser ist aber etwas anderes
      Trotzdem ist die Wahrscheinlichkeit hoch, dass Markdown-Daten wiederherstellbar sind. Bei selbst erzeugten Daten könnte HTML sogar sicherer sein
    • Das Problem bei Markdown ist, dass sich die Ausgabe beim Umwandeln in eine Menge formatierter Seiten je nach Version des Konverters unterscheidet
      Bei HTML ist es ähnlich, und bei Klartext in gewissem Maße auch. PDF sollte für immer exakt gleich bleiben, aber unter den bearbeitbaren Dokumentformaten ist TeX/LaTeX meines Wissens das einzige, das die gleiche Formatierung wirklich beibehält, selbst wenn die Software aktualisiert wird
      Tatsächlich gilt es bei LaTeX offiziell als Bug, wenn dasselbe Eingabedokument nicht exakt dasselbe Layout wie in früheren Versionen erzeugt
    • Aus diesen Gründen halte ich es für sinnvoll, Dokumente zu Protokollen und Dateiformaten möglichst als reinen ASCII-Text zu verfassen
      Besonders problematisch wird es, wenn die Dokumentation eines komplexeren Formats oder Protokolls in genau diesem Format oder Protokoll selbst erstellt werden muss
      Es gibt auch das Wiki „Just Solve The File Format Problem“. Ich habe dort selbst schon Inhalte ergänzt; es verwendet HTML und enthält nicht zu jedem Dateiformat die vollständige Spezifikation, manche Einträge sind nur Links auf externe Dateien, aber beim Auffinden von Informationen zu Dateiformaten ist es hilfreich
    • Ist Markdown nicht auch Klartext? Davon habe ich nicht abgeraten
    • Seit wir gesellschaftlich begonnen haben, weniger Papier-Hardcopys aufzubewahren, hätten wir digitale Bewahrung ernster nehmen müssen
      Es heißt, wer die Geschichte nicht kennt, sei dazu verdammt, dieselben Fehler zu wiederholen; aber wenn unsere Dokumente für künftige Generationen unlesbar werden oder verschwinden, wie sollen sie dann aus unseren Fehlern lernen?