PDF から DOCX または HTML へ：2 エンジン連携の往復はどう機能するのか
PDF は文書が完成しに行く場所です。レイアウト、フォント、ページ割りを凍結し、どこで印刷しても同一になるものにします。それこそが、内容を再編集したり、ウェブで再公開したり、別のワークフローに取り込んだりする必要が生じたとき、PDF が行き止まりになる理由です。
PDF から引き返すには、2 つの専門エンジンによる往復が必要です。テキストレイヤーを読んで構造を再構成するエンジンと、本物の DOCX や HTML ファイルを書き出すエンジンです。この記事では、当サイトでその連鎖がどう機能するか、旅を生き残るものは何か、そして 2 つの出力先の選び方を説明します。
PDF は目的地であって、出発地ではない
PDF フォーマットは、どの画面でもプリンターでもページが同じに見えるように設計されました。そのために、正確な座標を持つグリフを保存します。この文字、このフォント、ページ上のこの位置、という具合です。保存されないのはテキストの意味です。段落オブジェクトも、見出しスタイルも、リスト構造もなく、あるのは位置上の痕跡だけです。
この設計こそ、PDF からテキストをコピーすると改行が乱れ、書式が失われがちな理由です。閲覧ソフトは空白と幾何学から、段落がどこで始まりどこで終わるかを推測しなければなりません。PDF を編集可能な形式に戻す変換は、同じ推測ゲームを、慎重に、大規模に行うものです。
なぜ 1 つのエンジンでは往復できないのか
テキストレイヤーを読むことと Word 文書を書くことは、別の職能です。前者は幾何学です。位置づけられたグリフを行に並べ、行を段落に融合し、フォントサイズから見出しを検出し、本文と実行中のヘッダーやページ番号を分離する。後者はシリアライズの問題です。適切なスタイルを持つ有効な OOXML、あるいは正しい要素階層のクリーンな HTML を出力する。
それぞれ 1 つの仕事をうまくこなす 2 つのエンジンを連鎖させるほうが、1 つのエンジンに両方を求めるより優れています。当サイトでは、最初のエンジンは専用の PDF テキストレイヤー抽出器、2 番目は文書変換のリファレンスである Pandoc で、ブラウザー内で WebAssembly として動作します。両者の間には、双方が理解する中間形式——Markdown——が座っています。
連鎖：抽出、構造化、書き出し
第 1 段階：抽出器はすべてのページのテキストレイヤーをたどり、グリフを読み順に並べ、論理構造を再構築します。フォントの太さとサイズから見出しを、間隔から段落を、マーカーからリストを。出力は Markdown です。元文書の忠実な構造骨格です。
第 2 段階：Pandoc がその Markdown を受け取り、目的のフォーマットを書き出します。DOCX を求めれば、本物の .docx が得られます。スタイル、見出し、リスト、表が Word ネイティブの構築物として、Word、LibreOffice、Google Docs で開けます。HTML を求めれば、CMS に貼り付けられるクリーンな独立ページが得られます。両段階ともローカルで実行され、ファイルがマシンから出ることはありません。
往復で生き残るもの
構造はよく生き残ります。見出しレベル、段落、箇条書きと番号付きリスト、太字と斜体、ハイパーリンクは、テキストレイヤーから Markdown を経て DOCX や HTML へとクリーンに対応づきます。テキスト中心の文書——レポート、契約書、マニュアル、手紙——では、出力は本当に編集可能であり、打ち直さなければならないファクシミリではありません。
見た目は設計上、生き残りません。正確なフォント、精密な間隔、多段組レイアウト、浮動テキストボックスは、PDF のレンダリング上の決定であって内容ではなく、連鎖は意図的にそれらを捨てます。表は中間に位置します。単純なグリッドは表として通りますが、複雑なセル結合のレイアウトは、手作業の修復が必要な断片に劣化します。正しい期待値は、構造の整った下書きであって、ピクセルパーフェクトな再構築ではありません。
DOCX か HTML か：出力先の選択
人が結果を編集するなら DOCX を選びましょう。赤字修正が必要な契約書、コメント待ちのレポート、転用されるテンプレート——次のステップが Word や互換エディターで起こるあらゆる場面で。ネイティブのスタイルにより、変更履歴、コメント、再スタイル設定が期待どおりに機能します。
内容がウェブに戻るなら HTML を選びましょう。古い PDF ドキュメントをヘルプセンターに移行する、パンフレットをランディングページとして再公開する、静的サイトジェネレーターにコンテンツを供給する——HTML はワープロを完全に迂回し、検査可能なマークアップを生成します。2 つの出力先は同じ抽出段階を共有するので、迷ったら両方を出力しましょう。追加のコストはかかりません。
スキャン PDF には先に OCR が必要
連鎖全体がテキストレイヤーに依存します。スキャン PDF——PDF の殻に包まれたページの写真——にはそれがなく、存在しないものをどんな抽出器も読めません。2 秒のテスト：PDF リーダーで文を選択してみてください。単語をハイライトできなければ、それはスキャンです。
解決策は、前段に認識ステージを追加することです。まずファイルを OCR に通し——当サイトの画像→Markdown ツールはローカルで処理します——認識されたテキストを変換チェーンに供給します。認識エラーが新しい弱い環になるため、出力中の名前と数字は特に注意して校正してください。
信頼しつつ、スポットチェック
PDF から編集可能形式への変換はすべて再構築であり、再構築にはレビューが値します。まず見出し階層を確認しましょう。フォントサイズの手がかりを 1 つ見逃すと、章タイトルが本文に降格することがあります。次に表、重要な数字、そして各セクションの最初と最後の行——ヘッダーとフッターが紛れ込みやすい場所です。
この 5 分間はワークフローの欠陥ではありません。それがワークフローです。連鎖は、手のつけられない PDF を、実際に作業できる下書きに変えます。検証済みの下書きは、まったく編集できないオリジナルよりはるかに価値があります。