2 ページのレポートを Word に変換して何かを確認したところ、2 番目の段落が次のように戻ってきました。
3 人目の人員は 4 人増の収益が増加し、2 人全員が支援を求めて 4 分の 1 増加しました。 採用の大規模な更新は、8 月の第 4 四半期の計画に署名しました。 マージンは横ばい。 6 つの役割で変更されません。
完全に普通の散文の 2 つの列が、ガター ラインを横切って読み上げられるため、すべての文がその横の 1 文につながれます。 何も壊れていませんでした。 コンバータは、コンバータができることと、それと「PDF から Word への」というフレーズが約束することとの間のギャップが、このガイドの主題全体です。 以下に引用したすべての出力は、変換を説明するのではなく、変換を実行したことによるものです。
tl;dr: PDF は、座標にグリフを格納します。 段落、列、表、または見出しは格納されないため、変換器はそれらを位置から推測する必要があり、それらの推論のいくつかは、予測できる方法で間違っています。 テスト レポートで測定: 2 列の列が 1 行ずつ交互に並んでいる 4 行のテーブルが 1 行に平坦化され、「地域 Q2 Q3 EMEA 412 455 AMER 388 401 APAC 120 166」、その下の段落にマージされた見出しは何も表示されません。テキスト レイヤーは何も生成されませんでした。 確実に取り戻せるのは、ページの順序で編集可能な散文であり、ほとんどのジョブで必要なものです。 ザ・ PDF から Word への変換 ブラウザで実行するので、ドキュメントはアップロードされません。
PDF 内に保存されているものは何ですか?
ドキュメントではなく、ページを描くための手順。
PDF のコンテンツ ストリームには、「このフォントをこのサイズに設定し、X 60、Y 720 に移動して、これらのグリフを表示する」などのことを言います。 ザ・ 仕様自体 は、絵画モデルの説明であり、テキスト演算子は線を描くものや形を埋めるために並んでいます。 ファイルには、「パラグラフ」を意味するオブジェクトはなく、「これはテーブルです」という意味のオブジェクトはなく、テキストの 2 つのブロックが 1 つのワイド ブロックではなく、列であると記録するオブジェクトはありません。 フォーマットは、ページがどこでも同じように印刷されるように設計されており、ページをコンテンツではなくマークとして説明することで、それを実現します。
そのため、コンバーターは配置された実行のリストを受け取ります。 pdf.js、これが実行されるパーサーは、ページが描画したとおりに返します。 テスト ファイルでは、1 ページ目が 34 個を作成し、2 ページ目で 4 を作成しました。 各実行は、X、A Y、幅、およびフォントの高さを持つ文字列で、それらが到着する順序はページが描画された順序であり、必ずしもそれらを読む順序ではありません。
Word 文書に必要なものはすべて、PDF に含まれていないもので、コンバーターはこれら 4 つの数値から再構築する必要があります。 その再構築は、すべての失敗を含め、次のすべてです。
コンバータはどのようにして座標から段落を再構築しますか?
2 回のパスで、それぞれにしきい値が設定されています。
最初のパス グループは、ベースラインによって行に分かれます。その Y 値が互いにフォントの高さの半分以内にある場合、1 行が 1 行になります。 2 番目のグループは、それらの間の垂直ギャップによって段落に線分を合わせます。 通常の行間隔の約 1.45 倍よりも大きいギャップが新しい段落を開始します。ここで、「通常」はそのページの中央値のギャップであり、固定数ではなく、ルールは 9 ポイントまたは 14 ポイントで設定されたドキュメントに適応します。
行内に 3 番目のしきい値があります。 PDF.js は、複数の実行で 1 つの単語を分割することが多く、その間にギャップがないため、スペースでの実行は「ファイル名」を「file e n a m e」に変えます。 修正は、水平ギャップがフォントの高さの 4 分の 1 を超えた場合にのみスペースを挿入することです。つまり、実際の単語スペースの幅となります。
これらの 3 つの数値は、出力に関するほとんどすべてを決定します。 結果が良ければ、彼らは正しかった。 見出しがその下の段落に固執する場合、ギャップは中央値の 1.45 倍未満であり、ルールは 1 つの段落を表明していました。
なぜ 2 つの列がインターリーブされて出てくるのですか?
列の唯一の証拠は水平ギャップであり、線のグループ化は最初に垂直位置を調べます。
私のテスト ページの 2 つのブロックは、共有ベースラインにある X 60 と X 320 の 2 つのブロックでした。 グループ化により、6 つのベースラインが見られ、それぞれが両側からテキストを取り、それぞれのベースラインを読みました。 結果は、このガイドの上部にある段落です。左の列のすべての行のすぐ後に、その横の行が続きます。
これは、OCR のスクランブルされた列と同じ失敗であり、同じ根源があります。読み込み順序は、形状から作成されたレイアウトに関する判断で、読み取れないものによって作成されます。
列をうまく処理するコンバーターは、最初にページのセグメンテーション ステップを実行します。ページの高さを実行し、行グループ化の前にページを分割する、空白の一貫した垂直帯を探します。 これは、ガターが広く規則的な新聞や雑誌の紙で機能します。 サイドバー、プル クォート、または 2 列のテーブルがバンドを壊す、一般的なケースでは信頼性が低くなります。
ドキュメントに列がある場合、実際の答えは、出力を確認して各ページの最初の段落を修正するか、ドキュメントがそれだけの価値がある場合に一度に列を変換することです。
テーブルはどうなる？
文になります。
私のテスト ファイルには、3 列の 4 行のテーブルがありました。 変換後の全体は次のとおりです。
Region Q2 Q3 EMEA 412 455 AMER 388 401 APAC 120 166
すべての価値は生き残った。 構造はありませんでした。 その行から、412 が EMEA の第 2 フィギュアであるとは言えません。位置を数えたり、オリジナルの形状を知らずに。
その理由は、ほとんどの PDF には表も含まれていません。 PDF 内の表は、通常、その周囲に線が引かれた座標でテキストで描かれたテキストで描かれ、線はグラフィック操作であり、それらが囲むテキストに接続するファイルには何もありません。 コンバータは、数値の整列を検出し、グリッドを推測し、どのランが解析問題ではなく、どのセルに属しているかを判断する必要があります。
一部の PDF は、アクセシビリティのために追加されたタグを使用して実際の構造を持ち、それらははるかに優れています。 タグ付きの PDF は、印刷ドライバーからではなく、Word または InDesign からの慎重なエクスポートから得られます。
表が必要な場合は、スプレッドシートに手作業でコピーするか、PDF をテキストに変換して再形状します。 変換された Word ファイルでは、セルは得られません。
なぜ私の見出しが段落に組み合わされたのですか?
その下のスペースは、段落ルールをつまずくほど大きくなかったからです。
テスト ファイルの 2 ページ目で、「メモ」という見出しは本文の 40 点上で、ボディ ラインは 18 ポイント離れています。 4 回の実行しかないページのギャップの中央値は、何の信頼できるものでもないため、そのギャップは線間隔の 2.2 倍です。これは、分割する必要があり、分割されていませんでした。 出力は次のとおりです。
Notes Note 14 covers intercompany revenue and the treatment of
deferred items carried over from the prior year.
これが問題全体の正直な形です。 しきい値規則は、ベースラインのリズムを確立するのに十分なテキストを含むページでうまく機能し、スパース リズムではうまく機能しません。 タイトル ページ、短いメモ、カバー シート、またはフォームが、1 つの段落として戻ってくることがよくあります。
また、事後に修正するのが最も簡単です。 見出しは人間の読者には明らかであり、適切な場所で Return を押すには 1 秒かかります。これは、どのツールが正しく取得するかよりも時間がかかります。
スキャンしたページはどうなりますか?
何も出てきません。それが正しい動作です。
私のテスト ファイルの 3 ページ目には、テキスト レイヤーがまったくなく、スキャンのために灰色の長方形しかありませんでした。 PDF.js は実行をゼロにし、コンバーターはそのためにゼロの段落を生成しました。
ページはまだカウントされます。 Word ファイルには空のページとして表示されるため、ページ番号から作業しているときに重要なのは、元のページと一致した後でページが壊れます。 静かにドロップしたコンバーターは、後でページごとに 1 つずつシフトします。
すべてのページが画像である PDF はスキャンであり、抽出するテキストがないため、そこからテキストを抽出できません。 必要なのは OCR で、文字の写真を読み取って文字を推測し、独自のエラー率をもたらします。 その取引の測定版は OCR を壊すものに関するガイド: 3 度を超える傾きは、解像度ではなくスキャンを台無しにします。
役に立つ経験則: PDF を開いて、カーソルで文章を選択してみてください。 テキストがハイライトされている場合、コンバータはそれを読み取ることができます。 画像上で選択した長方形を取得する場合は、最初に OCR が必要です。
.docx の中に出てくるものは何ですか?
3 つのファイルを zip で、それだけで十分です。
.docx はオープン パッケージング コンベンション アーカイブであり、次のように標準化されています。 ECMA-376: XML 部分を含む ZIP と、各部分が何であるかを示すマニフェスト。 マイクロソフト自身のもの フォーマットの概要 同じ 3 つの部分を歩きます。 Word 文書として開く最小値は 3 つのエントリです。
| パート | 目的 |
|---|---|
[Content_Types].xml |
パッケージ内のすべてのパーツのメディア タイプを宣言します |
_rels/.rels |
メイン文書部分のポイント |
word/document.xml |
コンテンツ自体 |
通常、Word ファイルが持つ他のすべてのものは、スタイル、フォント、テーマ、設定、番号付けの定義などはオプションです。 それらを省略すると、リーダーはデフォルトを適用します。
テスト ドキュメントは、3 ページで 83 語で、1,305 バイトの .docx に届きました。 word/document.xml は 1,169 バイトです。 Apple 独自のドキュメント リーダーで開きました。これは、TextEdit と Pages が使用するもので、ページ ブレークをそのままにして、すべての段落を表示しました。 最小限のパッケージは劣化したパッケージではありません。
その XML の 1 つの詳細は、見た目よりも重要です。 すべての実行は、 xml:space="preserve"。 それがないと、実行の開始またはスペースの終了はスペースを失い、オリジナルでラップされたすべての行は、最後の単語が次の単語に結合されて戻ってきます。
画像はどうなるの?
それらは削除され、ファイルという単語には言及されていません。
ここに書かれたパッケージには 3 つの部分があり、どれもメディアの部分ではありません。 ロゴ、チャート、スキャンした署名、レポートに埋め込まれたスクリーンショット: すべてなくなって、プレースホルダーがどこにあったかはありません。 彼らを取り囲むテキストは、まるでそこに行ったことがないかのように閉じます。
これは、出力を小さく信頼できるものにするのと同じ設計の結果です。 画像を横切って持ち込むということは、PDF から抽出し、その形式を決定し、それを書き込むことを意味します。 word/media/、そのためのコンテンツ タイプを追加し、関係部分を追加し、フローの右側のポイントに図面要素を配置します。 これらのそれぞれは、読者がファイルを拒否する場所であり、ワープロが開くことを拒否する .docx は、ロゴが欠けているよりも悪いものです。
画像が装飾ではなくコンテンツであるドキュメントにとって最も重要です。 レポート内のグラフは何も変換されません。また、Word ファイルのリーダーは、チャートが存在したことを知る方法がありません。 散文で図が参照されている場合は、変換と一緒に元の元を確認してください。
ファイルが開くことをまったく拒否することがあるのはなぜですか?
XML および PDF に含まれる制御文字。
PDF のテキスト レイヤーは、印刷パイプラインからのフォーム フィード、壊れたエンコーディングからの null バイト、ドキュメント内の何の意味もない他の C0 制御コードなど、生成されたものから文字を拾います。 XML 1.0 ほとんどの場合は許可されません。エスケープされた場合でも、指定が許可する文字範囲は、タブ、改行、キャリッジ リターンで開始し、残りの C0 ブロックをスキップします。
失敗は優雅ではありません。 Word は、その文字を警告したり削除したりしません。ファイルを開くことを拒否し、内容が読み取れないと言います。 そのため、コンバーターは文字をエスケープするのではなく、書き込む前に削除します。 ソースには意味がなく、ドキュメント全体が必要になります。
ワープロが読み取れないと拒否する .docx を受け取った場合、これが最初に疑われることです。そのため、XML を手書きで書き込むコンバーターは、それについて考えなければなりません。
単語またはプレーン テキストに変換する必要がありますか?
編集する場合は単語、処理する場合はテキストを送信します。
同じ抽出を共有しています。 違いは最後に書かれるものだけです。1 つは段落を XML の zip に書き、もう一方はそれらを .txt ファイルに書き込む。
| そうしたいのです | 使い | だってさ |
|---|---|---|
| 散文を編集して送信する | PDF から Word | 段落の構造、改ページ、同僚が開くことができるもの |
| 検索、grep、またはスクリプトにフィードする | PDF からテキストへ | 途中でマークアップはありません |
| レイアウトを正確に保つ | どちらでもない | PDF を編集するか、元のファイルを取得します |
| スキャンを読む | OCR が先だ | 抽出するテキスト レイヤーはありません |
3 列目は、一緒にいる価値のあるものです。 レイアウトが重要な場合、Word に変換するのは間違った方向です。変換はレイアウトが失われるからです。 エクスポート元のファイルの PDF を送信した人に尋ねてください。 1 つのメッセージが必要で、これが唯一のフォーマットを維持する方法です。
変換にはどのくらいかかりますか?
ファイルを読むのに十分な長さで、もうありません。
エンコードステップも画像処理もありません。 この作業では、PDF 構造を解析し、各ページのテキスト コンテンツを取得し、実行をグループ化し、XML を zip にシリアル化しています。 テスト ファイルは数ミリ秒かかりましたが、これは 3 ページだったので役に立ちません。 200 ページのレポートは、PDF.js が解析することで制限されています。これは、ページ数がほぼ直線的で高速です。
大きなドキュメントで気付くのはメモリです。ファイル全体が解析された構造とともにブラウザー タブに保持されているからです。 それがスピードではなく、本当の天井です。
出力で何をチェックする必要がありますか?
4 つのこと、順番に間違っている可能性があります。
- すべてのページの最初の段落。 ここに、列のインターリービングとヘッダーのマージが表示されます。
- 任意のテーブル。 数字が存在することを確認し、グリッドがなくなったことを受け入れ、必要に応じて再構築します。
- 行末のハイフンでつながれた単語。 PDF の行に渡って単語が破られた場合、その途中にハイフンが表示されます。
- ページ数。 空白またはスキャンされたページを含め、元のページと一致する必要があります。
このリストは 10 ページのドキュメントで 1 分かかります。これは、送信できるファイルと、静かにスプライスされた文を含むファイルとの違いです。
なぜこれがブラウザで実行されるのですか?
人々が変換する文書は、契約、明細書、手紙、医療結果、および禁輸措置の下にあるものだからです。
変換は解析と zip であり、どちらもブラウザーが完全に機能します。 ファイルはディスクからページに読み込まれ、そこに Web 用にコンパイルされた pdf.js を使用して解析され、メモリー内の .docx に組み立てられ、ダウンロードとして返されます。 リクエストはドキュメントを運びません。サーバーには何も保存されません。また、後で削除するものもありません。
通常の代替手段は、PDF を取得し、何も知らないマシンで変換してリンクをメールで送信するサイトです。 公のパンフレットには問題ありません。 雇用契約の場合、意識的には求められなかった決定です。
コストは、非常に大きなファイルのタブのメモリであり、スキャンされたページのサーバー側の OCR はありません。 どちらも、静かな制限ではなく、目に見える制限であり、取引の価値があります。
