PyMuPDF 1.23.0rc1 - en to ja translation catalogue (81 entries)

en: PyMuPDF is a high-performance Python library for data extraction, analysis, conversion & manipulation of PDF (and other) documents.
ja: PyMuPDF は、PDF （およびその他の）ドキュメントのデータ抽出、分析、変換、操作のための高性能な Python ライブラリです。

en: PDF Text Extraction, PDF Image Extraction, PDF Conversion, PDF Tables, PDF Splitting, PDF Creation, Pyodide, PyScript
ja: PDFテキスト抽出、PDFイメージ抽出、PDF変換、PDFテーブル、PDF分割、PDF作成, Pyodide, PyScript

en: Appendix 1: Details on Text Extraction
ja: 付録1: テキスト抽出の詳細

en: This chapter provides background on the text extraction methods of PyMuPDF.
ja: この章では、PyMuPDFのテキスト抽出メソッドに関する背景情報を提供します。

en: Information of interest are
ja: 興味のある情報は以下です

en: what do they provide?
ja: 彼らは何を提供するのか？

en: what do they imply (processing time / data sizes)?
ja: それらは何を意味するのか（処理時間 / データサイズ）？

en: General structure of a TextPage
ja: TextPageの一般的な構造

en: :ref:`TextPage` is one of (Py-) MuPDF's classes. It is normally created (and destroyed again) behind the curtain, when :ref:`Page` text extraction methods are used, but it is also available directly and can be used as a persistent object. Other than its name suggests, images may optionally also be part of a text page::
ja: :ref:`TextPage` は（Py-）MuPDFのクラスの一つです。通常、:ref:`Page` のテキスト抽出メソッドが使用されるときにカーテンの後ろで作成され（および破棄され）ますが、直接利用することもでき、永続オブジェクトとして使用することができます。その名前が示すよりも、テキストページにはオプションで画像も含まれる場合があります：

en: A **text page** consists of blocks (= roughly paragraphs).
ja: **テキストページ** は、ブロック（おおよそ段落）で構成されています。

en: A **block** consists of either lines and their characters, or an image.
ja: **ブロック** は、行とその文字、または画像のいずれかから成り立っています。

en: A **line** consists of spans.
ja: **行** は、スパンから成り立っています。

en: A **span** consists of adjacent characters with identical font properties: name, size, flags and color.
ja: **スパン** は、同一のフォントプロパティ（名前、サイズ、フラグ、色）を持つ隣接する文字から成り立っています。

en: Plain Text
ja: プレーンテキスト

en: Function :meth:`TextPage.extractText` (or *Page.get_text("text")*) extracts a page's plain **text in original order** as specified by the creator of the document.
ja: 関数  :meth:`TextPage.extractText` （または *Page.get_text("text")* ）は、ドキュメントの作成者によって指定された元の順序で、ページのプレーンテキストを抽出します。

en: An example output::
ja: 例の出力：

en: The output may not equal an accustomed "natural" reading order. However, you can request a reordering following the scheme "top-left to bottom-right" by executing `page.get_text("text", sort=True)`.
ja: 出力は通常の「自然な」読み順と一致しない場合があります。ただし、`page.get_text("text", sort=True)` を実行することで、「左上から右下」のスキームに従った並べ替えを要求することができます。

en: BLOCKS
ja: ブロック

en: Function :meth:`TextPage.extractBLOCKS` (or *Page.get_text("blocks")*) extracts a page's text blocks as a list of items like::
ja: 関数  :meth:`TextPage.extractBLOCKS` （または `Page.get_text("blocks")` ）は、ページのテキストブロックを以下のような項目のリストとして抽出します：

en: Where the first 4 items are the float coordinates of the block's bbox. The lines within each block are concatenated by a new-line character.
ja: 最初の4つの項目は、ブロックのバウンディングボックスの浮動小数点座標です。各ブロック内の行は改行文字で連結されます。

en: This is a high-speed method, which by default also extracts image meta information: Each image appears as a block with one text line, which contains meta information. The image itself is not shown.
ja: これは高速なメソッドであり、デフォルトでは画像のメタ情報も抽出されます。各画像はメタ情報を含む1行のテキスト行で表されるブロックとして表示されます。画像そのものは表示されません。

en: As with simple text output above, the `sort` argument can be used as well to obtain a reading order.
ja: 前述の単純なテキスト出力と同様に、`sort` 引数を使用して読み順を取得することもできます。

en: Example output::
ja: 例の出力：

en: WORDS
ja: 単語

en: Function :meth:`TextPage.extractWORDS` (or *Page.get_text("words")*) extracts a page's text **words** as a list of items like::
ja: 関数 :meth:`TextPage.extractWORDS` （または *Page.get_text("words")* ）は、ページのテキスト単語を以下のような項目のリストとして抽出します：

en: Where the first 4 items are the float coordinates of the words's bbox. The last three integers provide some more information on the word's whereabouts.
ja: 最初の4つの項目は、単語のバウンディングボックスの浮動小数点座標です。最後の3つの整数は、単語の位置に関する追加情報を提供します

en: This is a high-speed method. As with the previous methods, argument `sort=True` will reorder the words.
ja: これは高速なメソッドです。前のメソッドと同様に、引数 `sort=True` を使用すると単語が再並べ替えされます。

en: :meth:`TextPage.extractHTML` (or *Page.get_text("html")* output fully reflects the structure of the page's *TextPage* -- much like DICT / JSON below. This includes images, font information and text positions. If wrapped in HTML header and trailer code, it can readily be displayed by an internet browser. Our above example::
ja: :meth:`TextPage.extractHTML` （または *Page.get_text("html"）* の出力は、ページの `TextPage` の構造を完全に反映します。これは、以下のDICT / JSONのようなものです。これには画像、フォント情報、テキスト位置が含まれます。HTMLヘッダーとトレイラーコードで囲むと、インターネットブラウザで簡単に表示できます。上記の例：

en: Controlling Quality of HTML Output
ja: HTML出力の品質の制御

en: While HTML output has improved a lot in MuPDF v1.12.0, it is not yet bug-free: we have found problems in the areas **font support** and **image positioning**.
ja: MuPDF v1.12.0でHTML出力はかなり改善されましたが、まだバグがないわけではありません。**フォントサポート** や**画像の配置** に関する問題が見つかっています。

en: HTML text contains references to the fonts used of the original document. If these are not known to the browser (a fat chance!), it will replace them with others; the results will probably look awkward. This issue varies greatly by browser -- on my Windows machine, MS Edge worked just fine, whereas Firefox looked horrible.
ja: HTMLテキストには元のドキュメントで使用されたフォントへの参照が含まれています。もしブラウザがそれらを認識できない場合（少ない確率ですが）、他のフォントで置き換えられ、結果が奇妙に見えるかもしれません。この問題はブラウザによって大きく異なります。Windowsマシンでは、MS Edgeはうまく動作するかもしれませんが、Firefoxはひどく見えるかもしれません。

en: For PDFs with a complex structure, images may not be positioned and / or sized correctly. This seems to be the case for rotated pages and pages, where the various possible page bbox variants do not coincide (e.g. *MediaBox != CropBox*). We do not know yet, how to address this -- we filed a bug at MuPDF's site.
ja: 複雑な構造を持つPDFの場合、画像の位置やサイズが正しく配置されないことがあります。これは回転したページや、さまざまなページbboxのバリアントが一致しない場合に起こる可能性があります（たとえば、*MediaBox != CropBox* ）。これに対処する方法はまだわかっていませんが、MuPDFのサイトにバグを報告しました。

en: To address the font issue, you can use a simple utility script to scan through the HTML file and replace font references. Here is a little example that replaces all fonts with one of the :ref:`Base-14-Fonts`: serifed fonts will become "Times", non-serifed "Helvetica" and monospaced will become "Courier". Their respective variations for "bold", "italic", etc. are hopefully done correctly by your browser::
ja: フォントの問題に対処するために、HTMLファイルをスキャンし、フォントの参照を置換するシンプルなユーティリティスクリプトを使用できます。以下は、すべてのフォントをPDFのベース14フォントの一つに置き換える例です：セリフフォントは「Times」になり、セリフのないフォントは「Helvetica」になり、等幅フォントは「Courier」になります。太字、斜体などの各バリエーションは、おそらくブラウザによって正しく処理されるでしょう。

en: DICT (or JSON)
ja: DICT（またはJSON）

en: :meth:`TextPage.extractDICT` (or *Page.get_text("dict", sort=False)*) output fully reflects the structure of a *TextPage* and provides image content and position detail (*bbox* -- boundary boxes in pixel units) for every block, line and span. Images are stored as *bytes* for DICT output and base64 encoded strings for JSON output.
ja: :meth:`TextPage.extractDICT` （または *Page.get_text("dict", sort=False)* ）の出力は、 *TextPage* の構造を完全に反映し、各ブロック、行、スパンのために画像の内容と位置の詳細（ *bbox*  – ピクセル単位の境界ボックス）を提供します。画像はDICT出力では *バイト* として格納され、JSON出力ではbase64エンコードされた文字列として格納されます。

en: For a visualization of the dictionary structure have a look at :ref:`textpagedict`.
ja: 辞書の構造の可視化については、辞書出力の構造をご覧ください。

en: Here is how this looks like::
ja: 以下がその様子です：

en: RAWDICT (or RAWJSON)
ja: RAWDICT（またはRAWJSON）

en: :meth:`TextPage.extractRAWDICT` (or *Page.get_text("rawdict", sort=False)*) is an **information superset of DICT** and takes the detail level one step deeper. It looks exactly like the above, except that the *"text"* items (*string*) in the spans are replaced by the list *"chars"*. Each *"chars"* entry is a character *dict*. For example, here is what you would see in place of item *"text": "Text in black color."* above::
ja: :meth:`TextPage.extractRAWDICT` （または *Page.get_text("rawdict", sort=False)*  ）は、**DICTの情報のスーパーセット** であり、詳細レベルを一段階深くします。これは上記のように見えますが、スパン内の *「text」* アイテム（文字列）は *「chars」* というリストに置き換えられます。各 *「chars」* エントリは文字の *dict* です。例えば、 *「Text in black color.」* の代わりに以下のような項目が表示されます：

en: The :meth:`TextPage.extractXML` (or *Page.get_text("xml")*) version extracts text (no images) with the detail level of RAWDICT::
ja: :meth:`TextPage.extractXML` （または *Page.get_text("xml"）* バージョンは、RAWDICTの詳細レベルでテキスト（画像なし）を抽出します：

en: We have successfully tested `lxml <https://pypi.org/project/lxml/>`_ to interpret this output.
ja: この出力を解釈するためにlxmlを使用して正常にテストしました。

en: :meth:`TextPage.extractXHTML` (or *Page.get_text("xhtml")*) is a variation of TEXT but in HTML format, containing the bare text and images ("semantic" output)::
ja: :meth:`TextPage.extractXHTML` （または *Page.get_text("xhtml"）* は、テキストと画像を含むHTML形式のTEXTのバリエーションです（「セマンティック」出力）：

en: Text Extraction Flags Defaults
ja: テキスト抽出フラグのデフォルト値

en: New in version 1.16.2: Method :meth:`Page.get_text` supports a keyword parameter *flags* *(int)* to control the amount and the quality of extracted data. The following table shows the defaults settings (flags parameter omitted or None) for each extraction variant. If you specify flags with a value other than *None*, be aware that you must set **all desired** options. A description of the respective bit settings can be found in :ref:`TextPreserve`.
ja: バージョン1.16.2で新しく追加されたメソッド :meth:`Page.get_text` は、抽出されるデータの量と品質を制御するためのキーワードパラメータ `flags` （整数）をサポートしています。以下の表は、各抽出バリエーションのデフォルト設定（ `flags` パラメータが省略されたかNoneの場合）を示しています。 `None` 以外の値でflagsを指定する場合は、**すべての必要なオプション** を設定する必要があることに注意してください。各ビット設定の説明は「テキスト抽出フラグ」で確認できます。

en: New in v1.19.6: The default combinations in the following table are now available as Python constants: :data:`TEXTFLAGS_TEXT`, :data:`TEXTFLAGS_WORDS`, :data:`TEXTFLAGS_BLOCKS`, :data:`TEXTFLAGS_DICT`, :data:`TEXTFLAGS_RAWDICT`, :data:`TEXTFLAGS_HTML`, :data:`TEXTFLAGS_XHTML`, :data:`TEXTFLAGS_XML`, and :data:`TEXTFLAGS_SEARCH`. You can now easily modify a default flag, e.g.
ja: バージョン1.19.6で新しく追加された変更：次の表のデフォルトの組み合わせは、Pythonの定数として利用可能です： :data:`TEXTFLAGS_TEXT` 、 :data:`TEXTFLAGS_WORDS` 、 :data:`TEXTFLAGS_BLOCKS` 、 :data:`TEXTFLAGS_DICT` 、 :data:`TEXTFLAGS_RAWDICT` 、 :data:`TEXTFLAGS_HTML` 、 :data:`TEXTFLAGS_XHTML` 、 :data:`TEXTFLAGS_XML` 、 :data:`TEXTFLAGS_SEARCH` 。これにより、デフォルトのフラグを簡単に変更できます。例えば、

en: **include** images in a "blocks" output:
ja: 「blocks」出力に画像を **含める** 場合：

en: **exclude** images from a "dict" output:
ja: 「dict」出力から画像を **除外する** 場合：

en: set **dehyphenation off** in text searches:
ja: テキスト検索での **ハイフネーション** をオフに設定する：

en: Indicator
ja: 指標

en: preserve ligatures
ja: 連結を保持

en: preserve whitespace
ja: 空白を保持

en: preserve images
ja: 画像を保持

en: inhibit spaces
ja: スペースの抑制

en: dehyphenate
ja: ハイフネーション解除

en: clip to mediabox
ja: メディアボックスにクリップ

en: **search** refers to the text search function.
ja: **検索** はテキスト検索機能を指します。

en: **"json"** is handled exactly like **"dict"** and is hence left out.
ja: **「json」** は **「dict」** とまったく同様に処理されるため、省略されています。

en: **"rawjson"** is handled exactly like **"rawdict"** and is hence left out.
ja: **「rawjson」** は **「rawdict」** とまったく同様に処理されるため、省略されています。

en: An "n/a" specification means a value of 0 and setting this bit never has any effect on the output (but an adverse effect on performance).
ja: 「n/a」の指定は値が0であり、このビットを設定しても出力に影響を与えることはありません（ただしパフォーマンスに悪影響を及ぼす可能性があります）。

en: If you are not interested in images when using an output variant which includes them by default, then by all means set the respective bit off: You will experience a better performance and much lower space requirements.
ja: 画像を含む出力バリアントを使用する際に画像に興味がない場合、必ず該当するビットをオフに設定してください。これにより、パフォーマンスが向上し、スペース要件が大幅に削減されます。

en: To show the effect of *TEXT_INHIBIT_SPACES* have a look at this example::
ja: `TEXT_INHIBIT_SPACES`  の効果を示すために、この例をご覧ください：

en: Performance
ja: パフォーマンス

en: The text extraction methods differ significantly both: in terms of information they supply, and in terms of resource requirements and runtimes. Generally, more information of course means, that more processing is required and a higher data volume is generated.
ja: テキスト抽出メソッドは、情報の提供方法とリソース要件、実行時間の両方で大きく異なります。一般的に、情報が多いほど処理が必要であり、より多くのデータが生成されることを意味します。

en: Especially images have a **very significant** impact. Make sure to exclude them (via the *flags* parameter) whenever you do not need them. To process the below mentioned 2'700 total pages with default flags settings required 160 seconds across all extraction methods. When all images where excluded, less than 50% of that time (77 seconds) were needed.
ja: 特に画像は **非常に大きな** 影響を持ちます。必要のない場合は、必ず画像を除外する（フラグパラメータを使用）ようにしてください。以下で言及されている2,700ページの総ページ数をデフォルトのフラグ設定で処理するには、全ての抽出メソッドで160秒が必要でした。画像をすべて除外した場合、その時間の50%未満（77秒）が必要でした。

en: To begin with, all methods are **very fast** in relation to other products out there in the market. In terms of processing speed, we are not aware of a faster (free) tool. Even the most detailed method, RAWDICT, processes all 1'310 pages of the :ref:`AdobeManual` in less than 5 seconds (simple text needs less than 2 seconds here).
ja: まず始めに、すべてのメソッドは市場にある他の製品と比べて **非常に高速** です。処理速度の観点から、より速い（無料の）ツールは私たちの知る限り存在しません。最も詳細なメソッドであるRAWDICTでも、 :ref:`AdobeManual` リファレンスの1,310ページを5秒未満で処理できます（ここでは簡単なテキストは2秒未満で処理されます）。

en: The following table shows average relative speeds ("RSpeed", baseline 1.00 is TEXT), taken across ca. 1400 text-heavy and 1300 image-heavy pages.
ja: 以下の表は、約1400ページのテキストが多く、約1300ページが画像が多いページでの平均相対速度（ベースライン1.00はTEXT）を示しています。

en: Method
ja: メソッド

en: RSpeed
ja: 平均相対

en: Comments
ja: コメント

en: no images
ja: 画像なし

en: no images, **plain** text, line breaks
ja: 画像なし、 **プレーン** テキスト、改行

en: image bboxes (only), **block** level text with bboxes, line breaks
ja: 画像のバウンディングボックス（のみ）、 **ブロック** レベルのテキストとバウンディングボックス、改行

en: no images, **word** level text with bboxes
ja: 画像なし、 **ワード** レベルのテキストとバウンディングボックス

en: no images, **char** level text, layout and font details
ja: 画像なし、**文字** レベルのテキスト、レイアウトとフォントの詳細

en: **base64** images, **span** level text, no layout info
ja: **base64** 画像、 **スパン** レベルのテキスト、レイアウト情報なし

en: **base64** images, **span** level text, layout and font details
ja: **base64画像** 、 **スパン** レベルのテキスト、レイアウトとフォントの詳細

en: **binary** images, **span** level text, layout and font details
ja: **バイナリ** 画像、 **スパン** レベルのテキスト、レイアウトとフォントの詳細

en: **binary** images, **char** level text, layout and font details
ja: **バイナリ** 画像、**文字** レベルのテキスト、レイアウトとフォントの詳細

en: As mentioned: when excluding image extraction (last column), the relative speeds are changing drastically: except RAWDICT and XML, the other methods are almost equally fast, and RAWDICT requires 40% less execution time than the **now slowest XML**.
ja: 前述のように、画像の抽出を除外する場合（最後の列）、相対速度は大きく変わります。RAWDICTとXMLを除いて、他のメソッドはほぼ同じ速さであり、RAWDICTは **今では遅いXML** よりも40％少ない実行時間を必要とします。

en: Look at chapter **Appendix 1** for more performance information.
ja: もっとパフォーマンス情報については、 **付録1章** をご覧ください。

en: This documentation covers all versions up to |version|.
ja: このドキュメントは |version| までのすべてのバージョンを対象としています。
