PDFの文字化けを見分けて、直し方を変える

PDFの文字化けは、まず「どう化けたか」を見る。表示できない文字と、別の文字に置き換わる現象は同じではない。

しろまえ殿は、PDFを開いて文字をコピーした。画面には日本語が見えている。しかし、貼り付けた先では文字が崩れた。

画面に見える文字と、コピーできる文字

PDFの文字は、字形（画面に描く形）とUnicode（文字を識別する番号）の対応を持っている。この対応表がToUnicode CMap（字形と文字コードの対応表）だ。

対応表が無いPDFでは、画面に字形だけを描ける。一方で、コピー時に元の文字へ戻せない。これは閲覧アプリの設定より、PDFを作った側の問題である。

たとえば、看板の形は見えているのに、住所録の番号が貼られていない状態だ。見た目を読めても、機械は文字を特定できない。

この型では、まず元データを探す。 WordやHTMLが残っていれば、そこからコピーするのが早い。元データが無ければ、OCR（画像から文字を読み取る処理）を使う。

「の」が別の似た文字になる場合は、文字コードの対応がずれていることがある。この型は、対応表が完全に無いケースとは違う。

変換前後の対応を少数のサンプルで確認する。確認できた後に、対象文字だけを置換する。全ての文字を一括変換するのは危険だ。

しろまえ殿は、実際のPDFを受け取ってから化け方を分類した。画像だけでは、字形の問題か文字コードの問題かを切り分けにくい。現物を先に確認する。

HTMLからA4のPDFを作る場合、CSS（表示位置を指定する仕組み）だけで余白を消す方法は安定しないことがある。高さを指定しても、変換エンジンや内容によって下側に余白が残る。

しろまえ殿の作業では、画像を一度はさむ方式に切り替えた。

1. HTMLをPDFへ変換する。 2. PDFをPNG画像へ変換する。 3. 白い背景以外の領域を検出して切り出す。 4. 切り出した画像をA4の大きさへ配置し直す。

背景全体をグラデーションにすると、白い余白の検出が狂う。 bodyの背景は白のままにする。装飾は内側のページ要素へ限定する。

この分離で、検出する基準と見た目の装飾を両立できた。正直、この時点でようやく紙面の位置が読めるようになり、クルーは安堵した。

文字化けも余白も、見た目だけで直そうとしないことだ。まず現物の構造を分類する。それから、元データ・OCR・画像処理のどこへ戻るかを決める。