PyMuPDF 1.23.0rc1 - en to ja translation catalogue (75 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: Common Issues and their Solutions
ja: 一般的な問題とその解決方法

en: How To Dynamically Clean Up Corrupt :title:`PDFs`
ja: 壊れた :title:`PDF` を動的にクリーンアップする方法

en: This shows a potential use of :title:`PyMuPDF` with another Python PDF library (the excellent pure Python package `pdfrw <https://pypi.python.org/pypi/pdfrw>`_ is used here as an example).
ja: これは、別のPython PDFライブラリ（素晴らしい純粋なPythonパッケージである `pdfrw <https://pypi.python.org/pypi/pdfrw>`_ を例として使用しています）と組み合わせてPyMuPDFを潜在的に使用する方法を示しています。

en: If a clean, non-corrupt / decompressed PDF is needed, one could dynamically invoke PyMuPDF to recover from many problems like so::
ja: クリーンで壊れていない / 解凍されていないPDFが必要な場合、次のようにしてPyMuPDFを動的に呼び出して多くの問題から回復することができます::

en: With the command line utility *pdftk* (`available <https://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/>`_ for Windows only, but reported to also run under `Wine <https://www.winehq.org/>`_) a similar result can be achieved, see `here <http://www.overthere.co.uk/2013/07/22/improving-pypdf2-with-pdftk/>`_. However, you must invoke it as a separate process via *subprocess.Popen*, using stdin and stdout as communication vehicles.
ja: コマンドラインユーティリティ `pdftk <https://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/>`_ （Windowsのみで利用可能ですが、 `Wine <https://www.winehq.org/>`_ 下でも動作すると報告されています）を使用すると、類似の結果を得ることができます。詳細は `こちら <http://www.overthere.co.uk/2013/07/22/improving-pypdf2-with-pdftk/>`_ をご覧ください。ただし、stdinとstdoutを通信手段として使用して別のプロセスとしてsubprocess.Popenを介して呼び出す必要があります。

en: How to Convert Any Document to :title:`PDF`
ja: どの文書も :title:`PDF` に変換する方法

en: Here is a script that converts any :title:`PyMuPDF` :ref:`supported document<Supported_File_Types>` to a :title:`PDF`. These include XPS, EPUB, FB2, CBZ and image formats, including multi-page TIFF images.
ja: 以下は、任意のPyMuPDFが :ref:`サポートされている <Supported_File_Types>` 文書をPDFに変換するスクリプトです。これにはXPS、EPUB、FB2、CBZ、および複数ページのTIFFイメージを含む画像フォーマットが含まれます。

en: It features maintaining any metadata, table of contents and links contained in the source document::
ja: これにはソース文書に含まれるメタデータ、目次、リンクを保持する機能が備わっています::

en: How to Deal with Messages Issued by :title:`MuPDF`
ja: :title:`MuPDF` から発行されるメッセージの処理方法

en: Since :title:`PyMuPDF` v1.16.0, **error messages** issued by the underlying :title:`MuPDF` library are being redirected to the Python standard device *sys.stderr*. So you can handle them like any other output going to this devices.
ja: PyMuPDF v1.16.0以降、基盤となるMuPDFライブラリから発行されるエラーメッセージは、Python標準デバイス *sys.stderr* にリダイレクトされます。したがって、これらのメッセージはこのデバイスに出力される他の出力と同様に扱うことができます。

en: In addition, these messages go to the internal buffer together with any :title:`MuPDF` warnings -- see below.
ja: さらに、これらのメッセージはMuPDFの警告とともに内部バッファに送られます - 以下を参照してください。

en: We always prefix these messages with an identifying string *"mupdf:"*. If you prefer to not see recoverable MuPDF errors at all, issue the command `fitz.TOOLS.mupdf_display_errors(False)`.
ja: これらのメッセージは常に識別用の文字列 `"mupdf:"` で始まります。復旧可能なMuPDFエラーを全く表示したくない場合は、コマンド  `fitz.TOOLS.mupdf_display_errors(False)` を発行してください。

en: MuPDF warnings continue to be stored in an internal buffer and can be viewed using :meth:`Tools.mupdf_warnings`.
ja: MuPDFの警告は引き続き内部バッファに保存され、 :meth:`Tools.mupdf_warnings` を使用して表示できます。

en: Please note that MuPDF errors may or may not lead to Python exceptions. In other words, you may see error messages from which MuPDF can recover and continue processing.
ja: MuPDFのエラーがPython例外につながる場合とつながらない場合があることに注意してください。言い換えれば、MuPDFが回復して処理を続けることができるエラーメッセージが表示される可能性があります。

en: Example output for a **recoverable error**. We are opening a damaged PDF, but MuPDF is able to repair it and gives us a little information on what happened. Then we illustrate how to find out whether the document can later be saved incrementally. Checking the :attr:`Document.is_dirty` attribute at this point also indicates that during `fitz.open` the document had to be repaired:
ja: 回復可能なエラーの例出力です。損傷したPDFを開いていますが、MuPDFはそれを修復し、何が起こったかに関する少しの情報を提供しています。その後、ドキュメントが後で増分保存できるかどうかを調べる方法も示しています。この時点で :attr:`Document.is_dirty` 属性をチェックすることも、 `fitz.open` の際にドキュメントを修復する必要があったことを示しています::

en: Example output for an **unrecoverable error**:
ja: **復旧できないエラー**の例出力:

en: Changing Annotations: Unexpected Behaviour
ja: 注釈の変更：予期しない動作

en: Problem
ja: 問題

en: There are two scenarios:
ja: 2つのシナリオがあります：

en: **Updating** an annotation with PyMuPDF which was created by some other software.
ja: 他のソフトウェアで作成された注釈をPyMuPDFで**更新**する。

en: **Creating** an annotation with PyMuPDF and later changing it with some other software.
ja: PyMuPDFで注釈を**作成**し、後で他のソフトウェアで変更する。

en: In both cases you may experience unintended changes, like a different annotation icon or text font, the fill color or line dashing have disappeared, line end symbols have changed their size or even have disappeared too, etc.
ja: どちらの場合でも、異なる注釈アイコンやテキストフォント、塗りつぶしの色や線の破線が消えたり、線の端のシンボルのサイズが変わったり、さらには消えたりするなど、意図しない変更が発生する可能性があります。

en: Cause
ja: 原因

en: Annotation maintenance is handled differently by each PDF maintenance application. Some annotation types may not be supported, or not be supported fully or some details may be handled in a different way than in another application. **There is no standard.**
ja: 注釈の保守は、各PDF保守アプリケーションごとに異なる方法で処理されます。一部の注釈タイプはサポートされないか、完全にはサポートされていない場合もあり、また、他のアプリケーションとは異なる方法で詳細が処理される場合もあります。標準規格は存在しません。

en: Almost always a PDF application also comes with its own icons (file attachments, sticky notes and stamps) and its own set of supported text fonts. For example:
ja: ほとんどの場合、PDFアプリケーションには独自のアイコン（ファイル添付、付箋、スタンプなど）とサポートされるテキストフォントのセットが付属しています。例えば：

en: (Py-) MuPDF only supports these 5 basic fonts for 'FreeText' annotations: Helvetica, Times-Roman, Courier, ZapfDingbats and Symbol -- no italics / no bold variations. When changing a 'FreeText' annotation created by some other app, its font will probably not be recognized nor accepted and be replaced by Helvetica.
ja: (Py-) MuPDFは、'FreeText'注釈に対してこれらの5つの基本フォントのみをサポートしています：Helvetica、Times-Roman、Courier、ZapfDingbats、Symbol - 斜体や太字のバリエーションはありません。他のアプリで作成された 'FreeText' 注釈を変更する際、そのフォントはおそらく認識されず、Helveticaに置き換えられる可能性があります。

en: PyMuPDF supports all PDF text markers (highlight, underline, strikeout, squiggly), but these types cannot be updated with Adobe Acrobat Reader.
ja: PyMuPDFはすべてのPDFテキストマーカー（ハイライト、下線、取り消し線、波線）をサポートしていますが、これらのタイプはAdobe Acrobat Readerで更新することはできません。

en: In most cases there also exists limited support for line dashing which causes existing dashes to be replaced by straight lines. For example:
ja: ほとんどの場合、破線には限定的なサポートが存在し、既存の破線が直線に置き換えられることがあります。例えば：

en: PyMuPDF fully supports all line dashing forms, while other viewers only accept a limited subset.
ja: PyMuPDFはすべての線の破線形式を完全にサポートしていますが、他のビューアは一部の形式しか受け入れません。

en: Solutions
ja: 解決策

en: Unfortunately there is not much you can do in most of these cases.
ja: 残念ながら、これらの多くの場合、あまり対処できることはありません。

en: Stay with the same software for **creating and changing** an annotation.
ja: 注釈の作成と変更に同じソフトウェアを使用してください。

en: When using PyMuPDF to change an "alien" annotation, try to **avoid** :meth:`Annot.update`. The following methods **can be used without it,** so that the original appearance should be maintained:
ja: "異なる"注釈を変更する際にPyMuPDFを使用する場合、:meth:`Annot.update` を避けるようにしてください。次のメソッドは、元の外観を維持するために、:meth:`Annot.update` を使用せずに使用できます：

en: :meth:`Annot.set_rect` (location changes)
ja: :meth:`Annot.set_rect` (位置の変更)

en: :meth:`Annot.set_flags` (annotation behaviour)
ja: :meth:`Annot.set_flags` (注釈の動作)

en: :meth:`Annot.set_info` (meta information, except changes to *content*)
ja: :meth:`Annot.set_info` (メタ情報、*コンテンツ* の変更以外)

en: :meth:`Annot.set_popup` (create popup or change its rect)
ja: :meth:`Annot.set_popup` (ポップアップの作成または位置の変更)

en: :meth:`Annot.set_optional_content` (add / remove reference to optional content information)
ja: :meth:`Annot.set_optional_content` (オプションコンテンツ情報への参照の追加/削除)

en: :meth:`Annot.update_file` (file attachment changes)
ja: :meth:`Annot.update_file` (ファイル添付の変更)

en: Misplaced Item Insertions on PDF Pages
ja: PDFページ上の誤ったアイテムの挿入

en: You inserted an item (like an image, an annotation or some text) on an existing PDF page, but later you find it being placed at a different location than intended. For example an image should be inserted at the top, but it unexpectedly appears near the bottom of the page.
ja: 既存のPDFページにアイテム（画像、注釈、テキストなど）を挿入しましたが、後で意図した場所とは異なる位置に配置されていることがあります。たとえば、画像はページの上部に挿入する予定でしたが、予想外にページの下部近くに表示されています。

en: The creator of the PDF has established a non-standard page geometry without keeping it "local" (as they should!). Most commonly, the PDF standard point (0,0) at *bottom-left* has been changed to the *top-left* point. So top and bottom are reversed -- causing your insertion to be misplaced.
ja: PDFの作成者が標準ではないページジオメトリを設定しており、それを「ローカル」に保持していないためです（正しい方法で保持すべきです）。最も一般的には、PDF標準の座標（0,0）が左下にある点から、左上の点に変更されています。したがって、上下が逆転し、挿入が誤って配置されてしまいます。

en: The visible image of a PDF page is controlled by commands coded in a special mini-language. For an overview of this language consult "Operator Summary" on pp. 643 of the :ref:`AdobeManual`. These commands are stored in :data:`contents` objects as strings (*bytes* in PyMuPDF).
ja: PDFページの可視イメージは、特別なミニ言語でコード化されたコマンドによって制御されています。この言語の概要については、 :ref:`AdobeManual` のpp. 643にある「オペレーターサマリー」を参照してください。これらのコマンドは、 :data:`contents` オブジェクトに文字列（PyMuPDFではバイト）として格納されます。

en: There are commands in that language, which change the coordinate system of the page for all the following commands. In order to limit the scope of such commands to "local", they must be wrapped by the command pair *q* ("save graphics state", or "stack") and *Q* ("restore graphics state", or "unstack").
ja: この言語には、次に続くすべてのコマンドの座標系を変更するコマンドがあります。このようなコマンドのスコープを「ローカル」に制限するためには、コマンドペアq（「グラフィックスステートの保存」または「スタック」）およびQ（「グラフィックスステートの復元」または「アンスタック」）で囲む必要があります。

en: So the PDF creator did this::
ja: したがって、PDFの作成者は次のように行いました::

en: where they should have done this::
ja: 正しくは、次のように行うべきでした::

en: In the mini-language's syntax, spaces and line breaks are equally accepted token delimiters.
ja: ミニ言語の構文では、スペースと改行は同様にトークンの区切りとして受け入れられます。

en: Multiple consecutive delimiters are treated as one.
ja: 複数の連続した区切りは、1つとして扱われます。

en: Keywords "stream" and "endstream" are inserted automatically -- not by the programmer.
ja: キーワード「stream」と「endstream」は自動的に挿入されます - プログラマーによって挿入されるものではありません。

en: Since v1.16.0, there is the property :attr:`Page.is_wrapped`, which lets you check whether a page's contents are wrapped in that string pair.
ja: v1.16.0以降、プロパティPage.is_wrappedがあり、ページの内容がその文字列ペアでラップされているかどうかを確認できます。

en: If it is *False* or if you want to be on the safe side, pick one of the following:
ja: それが `False` であるか、安全側に立ちたい場合、次のいずれかを選択してください：

en: The easiest way: in your script, do a :meth:`Page.clean_contents` before you do your first item insertion.
ja: 最も簡単な方法：スクリプトで最初のアイテム挿入を行う前に :meth:`Page.clean_contents` を実行します。

en: Pre-process your PDF with the MuPDF command line utility *mutool clean -c ...* and work with its output file instead.
ja: PDFをMuPDFコマンドラインユーティリティ `mutool clean -c …` で前処理し、その出力ファイルで作業します。

en: Directly wrap the page's :data:`contents` with the stacking commands before you do your first item insertion.
ja: 最初のアイテム挿入を行う前に、直接ページの内容をスタッキングコマンドでラップします。

en: **Solutions 1. and 2.** use the same technical basis and **do a lot more** than what is required in this context: they also clean up other inconsistencies or redundancies that may exist, multiple */Contents* objects will be concatenated into one, and much more.
ja: **解決策1と2** は同じ技術的基盤を使用しており、この文脈で必要なもの以上のことを行います：他の不整合や冗長性もクリーンアップされ、複数の */Contents* オブジェクトが1つに結合されるなど、さまざまな操作が行われます。

en: For **incremental saves,** solution 1. has an unpleasant implication: it will bloat the update delta, because it changes so many things and, in addition, stores the **cleaned contents uncompressed**. So, if you use :meth:`Page.clean_contents` you should consider **saving to a new file** with (at least) *garbage=3* and *deflate=True*.
ja: 増分保存の場合、解決策1には不快な影響があります：多くの変更を行い、さらにクリーンされた内容を非圧縮で保存するため、更新デルタが膨れる可能性があります。したがって、 :meth:`Page.clean_contents` を使用する場合は、（少なくとも） `garbage=3` および `deflate=True` を指定して新しいファイルに保存することを検討する必要があります。

en: **Solution 3.** is completely under your control and only does the minimum corrective action. There is a handy utility method :meth:`Page.wrap_contents` which -- as twe name suggests -- **wraps** the page's :data:`contents` object(s) by the PDF commands `q` and `Q`.
ja: **解決策3** は完全にあなたの制御下にあり、最小限の修正しか行いません。便利なユーティリティメソッド :meth:`Page.wrap_contents` があり、名前が示すように、ページの内容 (:data:`contents`) オブジェクトをPDFコマンド `q` と `Q` でラップします。

en: This solution is extremely fast and the changes to the PDF are minimal. This is useful in situations where incrementally saving the file is desirable -- or even a must when the PDF has been digitally signed and you cannot change this status.
ja: この解決策は非常に高速で、PDFへの変更は最小限です。これは、ファイルを増分保存することが望ましい場合、またはPDFがデジタル署名されており、このステータスを変更できない場合に便利です。

en: We recommend the following snippet to get the situation under control:
ja: 次のスニペットを使用して状況をコントロールすることをお勧めします：

en: Missing or Unreadable Extracted Text
ja: 欠落または読み取り不可能な抽出テキスト

en: Fairly often, text extraction does not work text as you would expect: text may be missing, or may not appear in the reading sequence visible on your screen, or contain garbled characters (like a ? or a "TOFU" symbol), etc. This can be caused by a number of different problems.
ja: 非常にしばしば、テキスト抽出が期待通りに機能しないことがあります。テキストが欠落しているか、画面上で表示される読み取り順序に表示されないか、文字が文字化けしている（「？」や「TOFU」シンボルなど）ことがあります。これはさまざまな問題が原因で起こる可能性があります。

en: Problem: no text is extracted
ja: 問題：テキストが抽出されない

en: Your PDF viewer does display text, but you cannot select it with your cursor, and text extraction delivers nothing.
ja: PDFビューアはテキストを表示しているが、カーソルで選択できず、テキストの抽出結果が何も表示されない。

en: You may be looking at an image embedded in the PDF page (e.g. a scanned PDF).
ja: PDFページに埋め込まれた画像を表示している可能性がある（例：スキャンされたPDF）。

en: The PDF creator used no font, but **simulated** text by painting it, using little lines and curves. E.g. a capital "D" could be painted by a line "|" and a left-open semi-circle, an "o" by an ellipse, and so on.
ja: PDFの作成者がフォントを使用せず、テキストをペイントして小さな線と曲線を使用して模倣している場合がある。たとえば、大文字の「D」は縦棒「|」と左開きの半円で描かれ、「o」は楕円で描かれるなど。

en: Solution
ja: 解決策

en: Use an OCR software like `OCRmyPDF <https://pypi.org/project/ocrmypdf/>`_ to insert a hidden text layer underneath the visible page. The resulting PDF should behave as expected.
ja: `OCRmyPDF <https://pypi.org/project/ocrmypdf/>`_ のようなOCRソフトウェアを使用して、表示ページの下に非表示のテキストレイヤーを挿入します。その結果のPDFは期待どおりに動作するはずです。

en: Problem: unreadable text
ja: 問題：読み取れないテキスト

en: Text extraction does not deliver the text in readable order, duplicates some text, or is otherwise garbled.
ja: テキストの抽出が読みやすい順序で行われず、一部のテキストが重複しているか、その他の理由で文字化けしている。

en: The single characters are readable as such (no "<?>" symbols), but the sequence in which the text is **coded in the file** deviates from the reading order. The motivation behind may be technical or protection of data against unwanted copies.
ja: 個々の文字はそのまま読み取れるが（「<?>」シンボルがない）、テキストがファイル内でコード化された順序が読み取り順序と異なる場合がある。その背後には技術的な問題やデータの不正なコピーからの保護がある可能性がある。

en: Many "<?>" symbols occur, indicating MuPDF could not interpret these characters. The font may indeed be unsupported by MuPDF, or the PDF creator may haved used a font that displays readable text, but on purpose obfuscates the originating corresponding unicode character.
ja: 多くの「<?>」シンボルが表示され、MuPDFがこれらの文字を解釈できないことを示している場合。フォントがMuPDFでサポートされていない可能性があるか、PDFの作成者が読み取り可能なテキストを表示するフォントを使用しているが、意図的に元の対応するUnicode文字を曖昧にしている場合があります。

en: Use layout preserving text extraction: `python -m fitz gettext file.pdf`.
ja: レイアウトを保持するテキスト抽出を使用します： `python -m fitz gettext file.pdf`。

en: If other text extraction tools also don't work, then the only solution again is OCRing the page.
ja: 他のテキスト抽出ツールも機能しない場合は、再びOCRでページを処理するのが唯一の解決策です。
