PDF を Word に変換することは、ソース文書が英語であり、左から右、上から下の単純な読み取り順序である場合には、非常に困難です。ソース文書がアラビア語、ヘブライ語、ペルシア語、またはウルドゥー語である場合、変換では、テキストが右から左に流れること、RTL テキスト内の数字が左から右に書かれること、およびページ全体のレイアウトが右側から始まることも正しく判断する必要があります。 PDF から Word へのコンバーターのほとんどは、主に LTR ドキュメントで設計およびテストされており、RTL コンテンツでのパフォーマンスは不完全なものからまったく使用できないものまで多岐にわたります。
PDF 形式は、テキストのプロパティとして読み上げ順序を明示的に保存しません。個々のテキスト ランをページ上に配置されたグリフとして保存します。 LTR テキストの場合、物理レイアウトと一致するため、コンバータはテキストが左から右、上から下に読まれると合理的に想定できます。 RTL テキストの場合、この仮定はまったく間違っています。ページ上で右から左に読まれるアラビア語テキストの行は、LTR 順序を想定するコンバータによって反転され、各行のスペルが逆になった出力が生成されます。これは書式設定に関する小さな問題ではありません。アラビア語の反転された行は、アラビア語話者には読めません。
複数の言語にわたる PDF からテキストへの抽出精度に関する 2025 年の調査では、同じ変換ツール セットにおける RTL 抽出エラー率が LTR 抽出エラー率より 3.6 倍高く、最も一般的なエラー タイプは語順の逆転であることがわかりました (Computational Linguistics Institute、「多言語 PDF テキスト抽出精度」、2025 年)。この研究では、エラーがランダムではないことも判明しました。特定のツールは一貫して RTL を正しく処理するか、体系的に反転した出力を生成します。つまり、RTL 変換に適切なツールを選択することは、変換設定を微調整するよりも重要であり、ツールを切り替えることで絶望的に壊れているように見える変換を修正できる可能性があります。
PDF が RTL テキストを保存する方法と単純な抽出が失敗する理由
PDF 内では、テキストは一連のグリフ インデックスと位置決めコマンドとして保存されます。 PDF は、テキストの実行ごとに、フォント、文字のグリフ コード、ページ上の各グリフの X 座標と Y 座標を指定します。 「このテキストはアラビア語です」という明示的なフラグはありません。または「この行は右から左に読みます。」 PDF コンバータ は、Unicode 文字コードからテキストの方向を推測する必要があり、Unicode 双方向アルゴリズムを通じて方向性をエンコードします。アラビア文字とヘブライ文字には固有の RTL 方向があり、Unicode アルゴリズムは、表示のために RTL 文字と LTR 文字の混合シーケンスを並べ替える方法を指定します。
問題は、PDF からのグリフの生の抽出順序が、元のテキスト内の文字の論理順序と一致しない可能性があることです。 PDF ライターは、ページ上にグリフを任意の順序で自由に配置できます。一部のライター ソフトウェアは、読み取り順序が右から左であっても、RTL グリフをコンテンツ ストリーム内で左から右に配置します。単純にグリフを抽出順に連結するコンバーターは、元の PDF ライターが選択したテキストのエンコード方法に応じて、正しく読み取られるテキストまたは逆方向に読み取られるテキストを生成します。同じアラビア語文書を 2 つの異なるワード プロセッサから PDF に印刷すると、グリフの順序が異なるコンテンツ ストリームが生成される可能性があり、一方では完全に機能するコンバータが、もう一方では反転したテキストが生成される可能性があります。
Unicode 双方向アルゴリズムは、Unicode 標準付録 9 で指定されており、方向性が混在した文字シーケンスを表示のために並べ替える方法を定義します。このアルゴリズムを正しく実装したコンバーターは、PDF コンテンツ ストリーム内のグリフの順序に関係なく、ほとんどの RTL テキストを正しく処理できます。ただし、実装の品質にはばらつきがあります。このアルゴリズムは一般的なケースを適切に処理しますが、ネストされた方向のオーバーライド、方向境界での句読点、およびアラビア語文内の英語の専門用語などの混合スクリプト テキストを含む特殊なケースもあります。
RTL 読み取り順序を処理するコンバータの選択
RTL ドキュメントの最も信頼できるコンバータは、テキスト抽出中に Unicode 双方向アルゴリズムを実装するコンバータです。 Adobe Acrobat Pro と、Apache PDFBox や pdfplumber を含むいくつかのオープンソース ライブラリは、さまざまな程度でこのアルゴリズムをサポートしています。 RTL ドキュメント バッチのコンバータをコミットする前に、単一の代表的なページでテストしてください。テキストを Word に抽出し、出力を単語ごとに元の PDF と比較します。文内の語順の逆転、RTL テキスト内の数字の正しい配置、アラビア語の段落内の英語の会社名などの LTR/RTL シーケンスの混合をチェックします。
コンバーターが一貫して RTL テキストを反転する場合は、中間形式を経由する変換パスを使用することで問題を回避できる場合があります。 RTL を正しく処理するツールを使用して、PDF を HTML またはタグ付きテキスト形式に変換します。次に、中間フォーマットを Word にインポートします。この 2 段階のプロセスは、PDF から Word への直接変換よりも利便性が劣りますが、直接パスで反転テキストが生成される場合、使用可能な出力への自動化されたルートは間接パスだけになります。
WukongPDF は、ソース ドキュメントのメタデータが RTL 言語を示している場合に、正しい読み取り方向とテキスト配置を自動的に適用する RTL 対応変換をサポートします。コンバーターは文書の主要なスクリプトを検出し、テキスト抽出中に適切な方向ルールを適用して、正しい段落方向、テキスト配置、および文字順序を備えた Word 文書を生成します。
RTL ドキュメントでのページ レイアウト構造の保持
読む順序はテキスト以外にも影響します。 RTL ドキュメントのページ レイアウト全体が、LTR ドキュメントに対してミラーリングされます。アラビア語の本の最初のページは、英語の読者が最後のページと考えるものです。テーブルは右から左に並びます。リストは右側にインデントされています。とじしろは右ページの右側にあります。テキストの方向は正しく処理されますが、レイアウト構造は調整されない変換では、テキストは正しく読み取れますが、すべてが LTR 文書であるかのように配置され、左揃えの段落と左インデントのリストが配置された Word 文書が生成され、RTL リーダーには正しく見えません。
PDF から Word への変換が編集と再エクスポートを目的としている場合、エディターが構造を調整するため、PDF 形式 レイアウトを保持することはそれほど重要ではありません。変換がアーカイブまたは参照目的であり、Word 文書が元の PDF と視覚的に一致する必要がある場合、レイアウトの保持がより重要になります。このような場合は、テキスト ボックスの位置、列のレイアウト、余白の配置を元の状態から保持するコンバータを選択してください。変換後、すべてのページでテキストの方向が正しいことを手動で確認します。アラビア語とヘブライ語のテキストの段落の配置がデフォルトの左揃えではなく右揃えに設定されていることを確認します。すべてのテーブルに列が正しい右から左の順序で含まれていることを確認します。これらの手動チェックは、コンバータがコンテンツの意味を理解していないため、自動変換では検出できない問題を検出します。