1990年の Word for Macintosh 4 ファイルで作られたWWWの原提案書は、今でも開けるのか？
(blog.jgc.org)- Tim Berners-Lee のWWW原提案書は 68,608バイトの Microsoft Word for Macintosh 4.0 文書で、現代の環境で原本に近い形で開き、PDFへ変換できるかが焦点だった
- Microsoft Word と Apple Pages は失敗し、Apache OpenOffice は開けたものの、書式と図表を適切に保持できなかった
- LibreOffice は文書を開き、鮮明な図表も表示したが、余白・フォントサイズ・ヘッダー/フッター・空白が原本と異なり、追加の補正が必要だった
- CERN の1998年版PDFは20ページである一方、Infinite Mac 上で1990年代の Macintosh と Word により確認した原本レイアウトは、A4基準で 22ページだった
- 手動補正した
.odtと、エミュレートした Mac で作成したPDFが GitHub にアップロードされており、34年前の文書でも正確に開いて保存するのは簡単ではない
原本ファイルの正体と変換の目的
- W3C は Tim Berners-Lee の original WWW proposal ページで、元の文書ファイルと思われるダウンロードを提供している
- そのダウンロードには「I think - I can't test it」という説明が付いており、別途RTF版と、1998年に原本ファイルから生成されたHTML版もある
- Mac の
fileコマンドは、原本文書を Microsoft Word for Macintosh 4.0 ファイルとして識別する - W3Cページのメモにも、この文書は1989年3月に作成された元の MacWord または Word for Mac 文書であり、1990年5月の日付が追加された以外は変更なしで再配布されたと記されている
- 目的は原本文書を開き、可能であれば高忠実度PDFのような現代的な形式に変換することだった
現代のソフトウェアで開いた結果
- まず Microsoft Word から試すため、ファイル拡張子を
.docにして OneDrive にアップロードし、開いてみた - Apple Pages も古い Microsoft Word for Macintosh ファイルを理解できなかった
- Apache OpenOffice はファイルを開けたが、書式が失われ、図表が欠落した
- LibreOffice はファイルを開き、図表も鮮明に表示した
- ただし余白がおかしく、ほかの書式上の問題も残っていた
CERN PDF と LibreOffice 出力の違い
- CERN は提案書の PDF版 を提供している
- このPDFは1998年に Acrobat Distiller Daemon 2.1 for SunOS/Solaris（SPARC）で生成されたものとみられ、20ページである
- LibreOffice に取り込んだバージョンは 24ページだった
- LibreOffice版からPDFを作成した後、Apple Preview のコンタクトシート表示で CERN PDF と比較した
- LibreOffice版では右余白が消えていた
- 本文の大半が CERN PDF の12ptではなく 14ptで表示されていた
- TBL のイニシャルが入ったヘッダーがフッターに変わっていた
- 画像位置を見ると改ページはおおむね合っているように見え、最大の問題はフォントサイズだと思われた
- CERN PDF にはタイトル下に空白があるが、LibreOffice版にはなかった
エミュレーションで確認した原本レイアウト
- 実際の原本文書がどのように見えていたのかを確認するため、Infinite Mac で1990年代の Macintosh を起動し、Word for Macintosh 4.0 で原本文書を実行した
- この方法で実際のフォント、フォントサイズ、レイアウトを確認できた
- エミュレートした Mac で確認した結果、元の Mac 上の文書と CERN PDF はかなり異なっていた
- CERN PDF は20ページ
- Word for Macintosh 4.0 をA4用紙で実行した文書は 22ページ
- その後の目標は CERN PDF に合わせることではなく、Mac で見える原本文書に近づけることへと変わった
手動補正と保存結果
- LibreOffice文書を原本に近づけるため、複数の項目を手動で調整した
- 用紙を A4 に設定
- 右余白を左余白と同じ大きさに設定
- 1ページ目はガター、フッター、ヘッダーが同じではないため、別の形式として調整
- 本文フォントを14ptなどから 12pt に変更
- ページ間で誤って分割されるテキストや配置の問題を手動で処理
- フッターに変わっていた要素をヘッダーに修正
- 最終結果は、Mac で見える文書にかなり近いものになった
- 変換結果である
.odt版は GitHubリポジトリ にアップロードされた - この作業は、古い文書を現代的な形式で保存することの難しさと、オープンソースソフトウェアがこうした変換に有用であり得ることを示している
- 当初の目的は、発表で使うために元の提案書の高品質な図表を得ることだったが、想定より時間がかかった
エミュレートした Mac で作成した追加PDF
- Hacker News のコメントで、エミュレートした Mac から PostScript ファイルやPDFを作成できるという提案が出た
- System 7 と1992年版 Word、PDFファイルを作るプリンタードライバー Print2PDF を使い、Word for Macintosh 5.1a から直接出力した
- この方法で生成されたPDFも GitHub に追加された
- このバージョンは 20ページ
- フォントは異なるが、元の要件だったPDF生成は満たしている
- 別の Hacker News コメントでは、別の Word バージョンと調整により、現代形式の良好な変換版を作成した事例へリンクしている
1件のコメント
Hacker News のコメント
興味のある人向けに、ベクターアートワークとフォントがすべて保たれた現代の Word 形式の文書を置いておいた: https://jasomill.at/proposal.docx
変換は、QEMU でエミュレートした Power Mac 上の Word 98[1]で開いて再保存し、その後、現代の Word for Mac 16.82 で開くという方法で行った
ただし画像は抜け落ちており、Word は “There is not enough memory or disk space to display or print the picture.” と表示したが、RAM の問題というより、Word がもはや PICT 画像形式をサポートしていないためのように見える
画像は、Word 98 から Acrobat 5.0.10 の PDF 印刷で PDF を作成し、現代の Adobe Illustrator で 3 つの画像をそれぞれ PDF として抽出して、元のフォント、ベクター、サイズ、バウンディングボックスを保ったうえで、Finder からドラッグ＆ドロップして復元した
比較用として、Power Mac の Word 98 から Acrobat で作った PDF は https://jasomill.at/proposal-Word98.pdf、macOS Sonoma の現代の Word が作った PDF は https://jasomill.at/proposal-Word16.82.pdf
[1] https://archive.org/details/ms-word98-special-edition
もちろんテキストが含まれていれば依然としてフォントの問題は残るが、PDF でベクターを保持するという発想は思いつかなかったし、PDF はフォント埋め込みもきちんとやってくれる
[1] http://fileformats.archiveteam.org/wiki/PICT
仕事中に少し調べた範囲では、LHC プロジェクトがいつ始まり、1990 年の時点ですでに関係があったのかは確認できなかったが、実際の稼働より 20 年前という点も、予想よりはるかに長く感じる
「実際のフォント、フォントサイズ、レイアウトを見て文書がどう見えるべきだったかを確認できる」というのは、元のフォントがある場合の話だ
Word 4.0 は System 6 向けに出たもので、System 3.2 までサポートしていたが、当時のフォントは出力解像度ごとに画面用ファイルとプリンタ用ファイルが分かれていた
プリンタフォントがなければ画面フォントを最近傍法で拡大して印刷し、画面フォントがなければシステムフォントで代替する。スクリーンショットのように、デフォルトは Geneva だ
この場合に必要なのは有名な Palatino と Courier だけだが、LibreOffice は Palatino Linotype がインストールされていても Times New Roman に置き換えた
PalatinoLinotype、Adobe OpenType 版ではPalatinoLTStdだからである可能性が高いハードコードされた例外がなければ、共通プレフィックスに基づくフォントマッチングは簡単に不適切な結果を生む。たとえば
LucidaをLucidaConsoleにマッピングしてしまうことがあり、文書作成者の意図という観点では、ほとんどどんなプロポーショナルなサンセリフ体でもそちらよりはましだろうさらに、正確な名前マッチングも保証されない。Apple は内部名が
NewYorkのフォントを 2 回配布しており、ひとつは Susan Kare による 1983 年の初代 Macintosh ビットマップデザインを TrueType 化したもの、もうひとつは 2019 年に出た無関係なデザインだこの小さな話で過小評価されがちなヒーローは、古くからある
file(1)コマンドだproposal: Microsoft Word for Macintosh 4.0ファイルが何なのか気になったとき、ほとんど反射的に使ってしまうし、返してくる情報が好奇心を満たしつつ実用的でもある程度にちょうど十分で、本当に便利だ
fileは素晴らしいツールだ以前、仕事用の Windows コンピュータの前に座ったとき、このツールを簡単に使えなくて何度も悪態をついた。後に WSL のおかげで楽になり、今は幸いほとんど Windows なしで過ごしている
LibreOffice はこのファイルをそのまま開いてくれる。古い文書ファイル形式のサポートが本当に優れているので、こういう用途のために入れっぱなしにしている: https://imgur.com/a/JENgq6V
それでも BasiliskII と InfiniteMac エミュレータを使うのも好きだ
スクリーンショットでもその問題が見えるようだし、これほど古いプロプライエタリ形式をここまでサポートしているのはかなり良いが、そうした問題があると「本当に優れている」とまで言うのは微妙だ
今の LibreOffice の中に 1990 年代初頭のサードパーティ形式の解析コードがまだ残っているのか、それともずっと後の Word バージョンをリバースエンジニアリングして作った互換・変換コードが実際に仕事をしているのか、気になってくる
Microsoft の下位互換性を示す例として、Windows 版 Word 2401 ではファイルはおおむね問題なく開け、レイアウトも記事の PDF と同じに見えた
基本的にはファイル形式がブロックされるものの、許可するのは簡単だった
ただし Microsoft Word Picture 形式用のグラフィックフィルターがないため、画像は開けなかった。かなり昔に廃止されたようだが、Word 2003 なら開けそうで、現代のシステムで動かせないほど古いものでもない
そこで保存すると現代の
.docに変換され、Office 365 で開いて PDF などに変換できた教訓は、Windows Office チームのほうが下位互換性に少し余計に時間をかけているようだ、ということ
Microsoft のような会社なら、Microsoft Word のあらゆるバージョンが作成した文書を、どれほど古くても開けるようにすることを重要視すべきだと思う
社会的・歴史的・経済的な責任があると思う
古いパースコードの脆弱性が心配なら、外部プロセスに移してサンドボックス隔離で実行し、その場で新しい読み取り可能なバージョンを吐き出させればよい。この機能自体をなくしてはいけない
追記: デスクトップ版 Word はファイルをきちんと開け、Web 版だけができないということが分かったので、この投稿は無効と見てもよい
追記 2: 文書は開けるが、埋め込まれたグラフィックを表示したり印刷したりはできないようだ
形式を文書化することが標準でもなかった。社会的責任があるという点には同意するが、デジタルアーカイブの仕事をした立場から言うと、昔は本当に、本当にめちゃくちゃだった。本当に
当時の印刷物が正確にどのようなものだったかを知りたいなら、Word for Mac 4.0 を実行するエミュレーターにPostScript ファイルを生成する印刷キューをインストールできるはず
その
.psファイルは PDF に変換できるあるいは、それほど古い OS でも Acrobat があるなら、仮想プリンタードライバーで直接 PDF を作れるかもしれない
自分でさらに細かく調整したいなら、Ghostscriptの深みに入っていけばよい :)
https://www.ghostscript.com
Word 4.0 ファイルも開いた記憶がある
LibreOffice は驚異的。多くの文書形式を開けるだけでなく、ヘッドレス実行とコマンドラインオプションで形式変換のような作業を自動化できる
こうした作業は、ほかの方法では難しいことが多い
https://help.libreoffice.org/latest/en-US/text/shared/guide/start_parameters.html
https://opensource.com/article/21/3/libreoffice-command-line
企業がよく過小評価している潜在的な問題がある。一部の企業は無期限保存のバックアップを持っている
10 年保存のバックアップは一般的で、法的理由から 20 年保存するところもあるが、ほとんどは「読める」と「使える」の違いを理解していない
データにもよるが、仮想マシン全体を無期限にバックアップし、後で実行できると信じている企業もある。vSphere 5.x のマシンを最新の vSphere 8 で復元するだけでも十分に難しいのに、こうした容量の無駄遣いはよく理解できない
この価格なら整理する価値はない。DevOps 1 人が時給 100 ドル以上かかり、もっと生産的な仕事の代わりに退屈な整理をする機会費用は含めていない
会社が買収されたり十分な時間が経ったりした後は、整理せずにデータを削除するか捨てればよい
仮想マシンも、たとえば VMDK なら起動せずに生ディスクを読める。月 10 ドルを節約するためにデータ損失のリスクを負う価値はなく、その金額は開発者 1 人がチームイベントでビールをもう 1 杯飲むのと同じくらいだ
だから容量の無駄というよりは、管理上の無駄に近い
形式がどれほど早く陳腐化するか、とりわけ非公開形式がどれほど危険かを示すよい警告談
長期保存する文書には Markdown、プレーンテキスト、PNG を使っている
こうした形式が消えたとしても、パーサーを自分で再実装するのは容易なはず
単純なケースで Markdown パーサーのように動作し、人々にパースできていると思わせるパーサーを作るのは簡単だが、本物のパーサーは別物
それでも Markdown データが復旧可能である可能性は高い。自分で生成するデータなら、HTML のほうが安全かもしれない
HTML も似ているし、プレーンテキストもある程度はそうだ。PDF は永久にまったく同じであるべきだが、編集可能な文書形式のうち、ソフトウェアが更新されても同じ書式を本当に維持するものは、知る限り TeX/LaTeX だけ
実際、LaTeX では同じ入力文書が以前のバージョンとまったく同じレイアウトを生成しなければ、公式にはバグとされる
より複雑な形式やプロトコルの文書を、その形式やプロトコル自体で書かなければならない場合は特に問題になる
Just Solve The File Format Problem という Wiki もある。自分も内容を追加したことがあるが、HTML を使っていて、すべてのファイル形式の完全な仕様があるわけではなく、一部は外部ファイルへのリンクにすぎない。それでもファイル形式の情報を探す助けにはなる
歴史を知らない者は同じ過ちを繰り返すというが、私たちの文書が将来世代に読めなくなったり失われたりしたら、彼らはどうやって私たちの過ちから学べるのだろうか？