グループ課題のレポートを二晩かけて整え、.docx をまとめ役に送ったら、スクリーンショットが三枚返ってきた。表紙の英字サブタイトルが二行に折り返され、3 ページ目にあったはずの表が 4 ページ目に移り、本文の途中に半ページ分の空白ができている。ファイルは誰も触っていない。違うのは開いた PC だけだった。
何が動いているのかを測るために、よくある提案書に似せた見本を自分で作った。A4 で 7 ページ、36 行の長い表、画像 3 枚、脚注 4 本、ヘッダーとフッター入り、中身はすべて架空。これをブラウザ上で 1 枚の Web ページに変換して、要素ごとの実際の幅と高さを測った。使ったのは ImgIng（https://imging.ai/）で、処理はローカルで完結する。ネットワークパネルを開いたまま何度か回したが、非 GET のリクエストは 0 件で、ファイルは外に出ていない。
原因は二つあった。
一つはフォントの置換だ。Word ファイルに入っているのはフォントの「名前」であって、フォントそのものではない。開いた側の PC にその名前のフォントが無ければ、OS は表示できる別のフォントを黙って当てる。フォント名の欄はそのままなので気づきにくい。そして字形ごとに 1 文字の幅も高さも違うから、字形が変われば、その文字列が占める面積も変わる。見本で測ると、同じ英字の 1 行がフォント未導入で 411.9×33 px、導入済みで 575.3×81 px。中国語の本文段落では高さが 45.6% 違った。収まっていた行が収まらなくなって折り返し、収まっていたページが収まらなくなって次に押し出される。以降のページ番号はまとめてずれる。
もう一つは、もっと根本的な話。.docx の拡張子を .zip に変えて開くと、中に「ページ」は一枚も入っていない。あるのは XML の集まりで、この段落はどのフォントで、何ポイントで、行間はいくつで、ここに改ページが入っている、と書いてあるだけだ。完成した紙面ではなく、組版の指示書にあたる。実際の改ページは開いた瞬間に、その PC に実在するフォントと用紙サイズと余白から計算される。別の PC で結果が変わるのは故障ではなく、想定どおりの挙動ということになる。（拡張子を戻せば普通に開くので、この確認自体は安全に試せる。）
そこから渡し方を変えた。相手が編集を続けるものは .docx のまま渡し、OS 標準のフォントだけを使うと先に決めておく。読むだけのもの——先生に出すレポート、確定版、発表前に送る資料——は、開いたときに組み直されない形で渡す。PDF はその代表格。もう一つ試しているのがオフラインの読み取り専用 HTML で、さきほどの 7 ページの見本は 85,903 バイトの .html 一枚になった。画像 3 枚は base64 で中に埋まっていて、外部リソースの参照は 0 件。受け取る側に Office は要らないし、うっかり書き換えられることもない。
デスクトップのブラウザで JavaScript を切って開き直してもみた。本文は有効時と 1 行も差が無く、3,178 文字をそのまま選択してコピーできた。
ただ「Word とまったく同じ見た目になる」とは言えない。手元に Word が無く、突き合わせていないからだ。見本ではページ数が元ファイルの明示的な改ページと一致し、本文の文字も欠けていなかった一方で、表紙のワードアート見出しは空白になり、フッターのページ番号は自分で確認する必要があった。どの形式に変換するにせよ、送る前に一度は自分で開いてみるのが結局いちばん早い。
「そっちでは崩れてる」と言われたとき最初に聞くべきなのは、Word のバージョンではない。その文字がそちらの画面で何というフォント名で表示されているか、のほうだ。