PyMuPDF 1.23.0rc1 - en to ja translation catalogue (92 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 3: Assorted Technical Information
ja: 付録3：さまざまな技術情報

en: This section deals with various technical topics, that are not necessarily related to each other.
ja: このセクションでは、必ずしも関連しないさまざまな技術的なトピックについて取り扱います。

en: Image Transformation Matrix
ja: 画像変換行列

en: Starting with version 1.18.11, the image transformation matrix is returned by some methods for text and image extraction: :meth:`Page.get_text` and :meth:`Page.get_image_bbox`.
ja: バージョン1.18.11から、テキストと画像の抽出に関する一部のメソッドで画像変換行列が返されます：:meth:`Page.get_text` および :meth:`Page.get_image_bbox` 。

en: The transformation matrix contains information about how an image was transformed to fit into the rectangle (its "boundary box" = "bbox") on some document page. By inspecting the image's bbox on the page and this matrix, one can determine for example, whether and how the image is displayed scaled or rotated on a page.
ja: 変換行列には、画像が文書ページ上の矩形（「境界ボックス」=「bbox」）に適合するためにどのように変換されたかに関する情報が含まれています。ページ上の画像のbboxとこの行列を検査することにより、例えば画像がページ上で拡大縮小または回転して表示されるかどうか、そしてどのように表示されるかを判断することができます。

en: The relationship between image dimension and its bbox on a page is the following:
ja: 画像の寸法とページ上のbboxとの関係は次のとおりです：

en: Using the original image's width and height,
ja: 元の画像の幅と高さを使用して、

en: define the image rectangle `imgrect = fitz.Rect(0, 0, width, height)`
ja: 画像の矩形を `imgrect = fitz.Rect(0, 0, width, height)` と定義します。

en: define the "shrink matrix" `shrink = fitz.Matrix(1/width, 0, 0, 1/height, 0, 0)`.
ja: 「縮小行列」を `shrink = fitz.Matrix(1/width, 0, 0,1/height, 0, 0)` と定義します。

en: Transforming the image rectangle with its shrink matrix, will result in the unit rectangle: `imgrect * shrink = fitz.Rect(0, 0, 1, 1)`.
ja: 画像矩形を縮小行列で変換すると、単位矩形が得られます： `imgrect * shrink = fitz.Rect(0, 0, 1, 1)` 。

en: Using the image **transformation matrix** "transform", the following steps will compute the bbox::
ja: 画像 **変換行列** 「transform」を使用して、次の手順でbboxを計算します：

en: Inspecting the matrix product `shrink * transform` will reveal all information about what happened to the image rectangle to make it fit into the bbox on the page: rotation, scaling of its sides and translation of its origin. Let us look at an example:
ja: 行列の積 `shrink * transform` を検査することで、画像矩形がページ上のbboxに適合させるために何が起こったかに関するすべての情報が明らかになります。回転、辺のスケーリング、および原点の移動です。例を見てみましょう：

en: PDF Base 14 Fonts
ja: PDFベース14フォント

en: The following 14 builtin font names **must be supported by every PDF viewer** application. They are available as a dictionary, which maps their full names amd their abbreviations in lower case to the full font basename. Wherever a **fontname** must be provided in PyMuPDF, any **key or value** from the dictionary may be used::
ja: 以下の14の組み込みフォント名は、**すべてのPDFビューアアプリケーションでサポートされる必要があります** 。これらは辞書として利用可能で、それぞれのフルネームとその略称を小文字で完全な **フォントベース名** にマッピングします。PyMuPDFでフォント名を提供する必要がある場合、辞書からの任意の **キーまたは値** を使用できます：

en: In contrast to their obligation, not all PDF viewers support these fonts correctly and completely -- this is especially true for Symbol and ZapfDingbats. Also, the glyph (visual) images will be specific to every reader.
ja: 義務とは対照的に、すべてのPDFビューアがこれらのフォントを正確かつ完全にサポートしているわけではありません。特にSymbolとZapfDingbatsについては、これが特に当てはまります。また、グリフ（視覚的な）イメージは、それぞれの閲覧者に固有のものになります。

en: To see how these fonts can be used -- including the **CJK built-in** fonts -- look at the table in :meth:`Page.insert_font`.
ja: これらのフォントがどのように使用されるか（ **CJK組み込みフォント** も含めて）、:meth:`Page.insert_font` のテーブルをご覧ください。

en: Adobe PDF References
ja: Adobe PDFリファレンス

en: This PDF Reference manual published by Adobe is frequently quoted throughout this documentation. It can be viewed and downloaded from `here <https://opensource.adobe.com/dc-acrobat-sdk-docs/standards/pdfstandards/pdf/PDF32000_2008.pdf>`_.
ja: Adobeによって公開されたこのPDFリファレンスマニュアルは、このドキュメンテーション全体で頻繁に引用されています。 `こちら <https://opensource.adobe.com/dc-acrobat-sdk-docs/standards/pdfstandards/pdf/PDF32000_2008.pdf>`_ から閲覧およびダウンロードが可能です。

en: For a long time, an older version was also available under `this <http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf>`_ link. It seems to be taken off of the web site in October 2021. Earlier (pre 1.19.*) versions of the PyMuPDF documentation used to refer to this document. We have undertaken an effort to replace referrals to the current specification above.
ja: 長い間、古いバージョンも `この <http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf>`_ リンクで利用可能でしたが、2021年10月にウェブサイトから取り下げられたようです。以前（1.19.*より前）のPyMuPDFドキュメンテーションはこの文書を参照していました。私たちは、上記の現行仕様への参照を置き換える取り組みを行っています。

en: Using Python Sequences as Arguments in PyMuPDF
ja: PythonシーケンスをPyMuPDFで引数として使用する場合

en: When PyMuPDF objects and methods require a Python **list** of numerical values, other Python **sequence types** are also allowed. Python classes are said to implement the **sequence protocol**, if they have a `__getitem__()` method.
ja: PyMuPDFのオブジェクトとメソッドが数値の値のPython **リスト** を必要とする場合、他のPython **シーケンス型** も許可されています。Pythonのクラスは、`__getitem__()` メソッドを持つ場合、**シーケンスプロトコル** を実装していると言われています。

en: This basically means, you can interchangeably use Python *list* or *tuple* or even *array.array*, *numpy.array* and *bytearray* types in these cases.
ja: 基本的には、これらの場合にPythonの *リスト* や *タプル* 、*array.array* 、*numpy.array* 、*bytearray* 型を互換性を持って使用できることを意味しています。

en: For example, specifying a sequence `"s"` in any of the following ways
ja: 例えば、次のいずれかの方法でシーケンス `"s"` を指定すると

en: `s = [1, 2]` -- a list
ja: `s = [1, 2]` – リスト

en: `s = (1, 2)` -- a tuple
ja: `s = (1, 2)` – タプル

en: `s = array.array("i", (1, 2))` -- an array.array
ja: `s = array.array("i", (1, 2))`  – array.array

en: `s = numpy.array((1, 2))` -- a numpy array
ja: `s = numpy.array((1, 2))` – numpy配列

en: `s = bytearray((1, 2))` -- a bytearray
ja: `s = bytearray((1, 2))` – bytearray

en: will make it usable in the following example expressions:
ja: これによって、以下の例の式で使用可能になります：

en: Similarly with all geometry objects :ref:`Rect`, :ref:`IRect`, :ref:`Matrix` and :ref:`Point`.
ja: 同様に、すべてのジオメトリオブジェクト :ref:`Rect` 、:ref:`IRect` 、:ref:`Matrix` 、 :ref:`Point` も同様です。

en: Because all PyMuPDF geometry classes themselves are special cases of sequences, they (with the exception of :ref:`Quad` -- see below) can be freely used where numerical sequences can be used, e.g. as arguments for functions like *list()*, *tuple()*, *array.array()* or *numpy.array()*. Look at the following snippet to see this work.
ja: なぜなら、すべてのPyMuPDFジオメトリクラス自体がシーケンスの特殊なケースであるため、（ :ref:`Quad`  を除く）数値のシーケンスが使用可能な場所で自由に使用できるからです。例えば、 *list()* 、 *tuple()* 、 *array.array()*

en: :ref:`Quad` is a Python sequence object as well and has a length of 4. Its items however are :data:`point_like` -- not numbers. Therefore, the above remarks do not apply.
ja:  :ref:`Quad` もPythonのシーケンスオブジェクトであり、長さが4です。ただし、そのアイテムは数値ではなく :data:`point_like` です。したがって、上記の注釈は適用されません。

en: Ensuring Consistency of Important Objects in PyMuPDF
ja: 重要なオブジェクトの整合性を確保するためのPyMuPDF

en: PyMuPDF is a Python binding for the C library MuPDF. While a lot of effort has been invested by MuPDF's creators to approximate some sort of an object-oriented behavior, they certainly could not overcome basic shortcomings of the C language in that respect.
ja: PyMuPDFは、CライブラリMuPDFのPythonバインディングです。MuPDFの開発者たちは、ある種のオブジェクト指向の振る舞いを模倣するために多くの努力をしてきましたが、C言語の基本的な制約を克服することはできませんでした。

en: Python on the other hand implements the OO-model in a very clean way. The interface code between PyMuPDF and MuPDF consists of two basic files: *fitz.py* and *fitz_wrap.c*. They are created by the excellent SWIG tool for each new version.
ja: 一方で、Pythonは非常にクリーンな方法でOOモデルを実装しています。PyMuPDFとMuPDFの間のインターフェースコードは、基本的に2つのファイルから構成されています： *fitz.py* と *fitz_wrap.c* 。これらは、新バージョンごとに優れたSWIGツールによって作成されます。

en: When you use one of PyMuPDF's objects or methods, this will result in execution of some code in *fitz.py*, which in turn will call some C code compiled with *fitz_wrap.c*.
ja: PyMuPDFのオブジェクトやメソッドのいずれかを使用すると、これにより *fitz.py* でいくつかのコードが実行され、それがさらに *fitz_wrap.c* でコンパイルされたCコードを呼び出します。

en: Because SWIG goes a long way to keep the Python and the C level in sync, everything works fine, if a certain set of rules is being strictly followed. For example: **never access** a :ref:`Page` object, after you have closed (or deleted or set to *None*) the owning :ref:`Document`. Or, less obvious: **never access** a page or any of its children (links or annotations) after you have executed one of the document methods *select()*, *delete_page()*, *insert_page()* ... and more.
ja: SWIGはPythonとCレベルを同期させるために大いに役立っているため、一定のルールが厳密に守られる限り、すべてが正常に動作します。例えば、所有している :ref:`ドキュメント` を閉じたり（または削除したり、Noneに設定したり）した後に :ref:`Page` オブジェクトに **アクセスしないでください** 。また、より明確な例では、 *select()* 、*delete_page()* 、 *insert_page()* などのドキュメントメソッドを実行した後にページやその子要素（リンクや注釈など）に **アクセスしないでください** 。

en: But just no longer accessing invalidated objects is actually not enough: They should rather be actively deleted entirely, to also free C-level resources (meaning allocated memory).
ja: ただし、無効なオブジェクトへのアクセスをやめるだけでは実際には十分ではありません。これらのオブジェクトは、Cレベルのリソース（割り当てられたメモリ）も解放するために、完全に削除されるべきです。

en: The reason for these rules lies in the fact that there is a hierarchical 2-level one-to-many relationship between a document and its pages and also between a page and its links / annotations. To maintain a consistent situation, any of the above actions must lead to a complete reset -- in **Python and, synchronously, in C**.
ja: これらのルールの理由は、ドキュメントとそのページ、およびページとそのリンク/注釈の間に階層的な2段階の1対多の関係があるためです。一貫した状況を維持するために、上記のアクションのいずれもが **PythonとCの両方で** 完全なリセットを引き起こさなければなりません。

en: SWIG cannot know about this and consequently does not do it.
ja: SWIGはこれを知ることはできないため、それを実行しません。

en: The required logic has therefore been built into PyMuPDF itself in the following way.
ja: 必要な論理はしたがって、PyMuPDF自体に以下のように組み込まれています。

en: If a page "loses" its owning document or is being deleted itself, all of its currently existing annotations and links will be made unusable in Python, and their C-level counterparts will be deleted and deallocated.
ja: ページが所有するドキュメントを失ったり、それ自体が削除されると、現在存在するすべての注釈とリンクはPythonで使用できなくなり、それらのCレベルの対応部分が削除されて解放されます。

en: If a document is closed (or deleted or set to *None*) or if its structure has changed, then similarly all currently existing pages and their children will be made unusable, and corresponding C-level deletions will take place. "Structure changes" include methods like *select()*, *delePage()*, *insert_page()*, *insert_pdf()* and so on: all of these will result in a cascade of object deletions.
ja: ドキュメントが閉じられたり（または削除されたり、 *None* に設定されたり）したり、構造が変更されたりすると、同様に現在存在するすべてのページとその子要素は使用できなくなり、対応するCレベルの削除が行われます。「構造の変更」とは、 *select()* 、 *delete_page()* 、 *insert_page()* 、 *insert_pdf()* などのメソッドを含みます。これらのすべてはオブジェクトの削除の連鎖を引き起こします。

en: The programmer will normally not realize any of this. If he, however, tries to access invalidated objects, exceptions will be raised.
ja: プログラマーは通常、これらのいずれも気づかないでしょう。ただし、無効なオブジェクトにアクセスしようとすると、例外が発生します。

en: Invalidated objects cannot be directly deleted as with Python statements like *del page* or *page = None*, etc. Instead, their *__del__* method must be invoked.
ja: 無効なオブジェクトは、 *del page* または *page = None* などのPythonステートメントで直接削除することはできません。代わりに、その *__del__* メソッドを呼び出す必要があります。

en: All pages, links and annotations have the property *parent*, which points to the owning object. This is the property that can be checked on the application level: if *obj.parent == None* then the object's parent is gone, and any reference to its properties or methods will raise an exception informing about this "orphaned" state.
ja: すべてのページ、リンク、注釈には、所有するオブジェクトを指す *親* プロパティがあります。これはアプリケーションレベルでチェックできるプロパティです： *obj.parent == None* ならば、そのオブジェクトの親は存在せず、そのプロパティやメソッドへの参照は例外を発生させてこの「孤立」した状態について通知します。

en: A sample session:
ja: サンプルセッション：

en: This shows the cascading effect:
ja: これは連鎖効果を示しています。

en: Objects outside the above relationship are not included in this mechanism. If you e.g. created a table of contents by *toc = doc.get_toc()*, and later close or change the document, then this cannot and does not change variable *toc* in any way. It is your responsibility to refresh such variables as required.
ja: 上記の関係外のオブジェクトは、このメカニズムに含まれていません。たとえば、 `toc = doc.get_toc()`  のように目次を作成し、後で文書を閉じたり変更したりする場合、これは変数 toc をどのようにも変更しません。必要に応じてそのような変数を更新する責任はあなたにあります。

en: Design of Method :meth:`Page.show_pdf_page`
ja: メソッド  :meth:`Page.show_pdf_page`  の設計

en: Purpose and Capabilities
ja: 目的と機能

en: The method displays an image of a ("source") page of another PDF document within a specified rectangle of the current ("containing", "target") page.
ja: このメソッドは、現在の（「含まれる」、「ターゲット」）ページの指定された矩形内に別のPDF文書の（「ソース」）ページの画像を表示します。

en: **In contrast** to :meth:`Page.insert_image`, this display is vector-based and hence remains accurate across zooming levels.
ja: :meth:`Page.insert_image`  **とは異なり** 、この表示はベクターベースであり、ズームレベルを超えて正確に保たれます。

en: **Just like** :meth:`Page.insert_image`, the size of the display is adjusted to the given rectangle.
ja: :meth:`Page.insert_image`  **と同様に** 、表示のサイズは指定された矩形に調整されます。

en: The following variations of the display are currently supported:
ja: 現在、次のバリエーションの表示がサポートされています：

en: Bool parameter `"keep_proportion"` controls whether to maintain the aspect ratio (default) or not.
ja: Bool パラメーター `"keep_proportion"` はアスペクト比を保持するかどうかを制御します（デフォルト）。

en: Rectangle parameter `"clip"` restricts the visible part of the source page rectangle. Default is the full page.
ja: 矩形パラメーター `"clip"` はソースページの矩形の可視部分を制限します。デフォルトはフルページです。

en: float `"rotation"` rotates the display by an arbitrary angle (degrees). If the angle is not an integer multiple of 90, only 2 of the 4 corners may be positioned on the target border if also `"keep_proportion"` is true.
ja: float `"rotation"` は表示を任意の角度（度）で回転させます。角度が90の倍数でない場合、`"keep_proportion"` も true の場合、ターゲットの境界に4つのうち2つのコーナーのみが配置される場合があります。

en: Bool parameter `"overlay"` controls whether to put the image on top (foreground, default) of current page content or not (background).
ja: Bool パラメーター `"overlay"` は、画像を現在のページコンテンツの上（前景、デフォルト）に配置するか、そうでないか（背景）を制御します。

en: Use cases include (but are not limited to) the following:
ja: 使用例は以下のようなものがありますが、これに限定されません：

en: "Stamp" a series of pages of the current document with the same image, like a company logo or a watermark.
ja: 現在の文書の複数のページに同じ画像（企業のロゴや透かし）を「スタンプ」する。

en: Combine arbitrary input pages into one output page to support “booklet” or double-sided printing (known as "4-up", "n-up").
ja: 任意の入力ページを1つの出力ページに組み合わせ、"ブックレット"や両面印刷をサポートする（「4-up」、「n-up」としても知られています）。

en: Split up (large) input pages into several arbitrary pieces. This is also called “posterization”, because you e.g. can split an A4 page horizontally and vertically, print the 4 pieces enlarged to separate A4 pages, and end up with an A2 version of your original page.
ja: （大きな）入力ページをいくつかの任意のピースに分割する。これは「ポスタリゼーション」とも呼ばれ、たとえばA4ページを水平および垂直に分割し、4つのピースを別々のA4ページに拡大印刷して、元のページのA2バージョンを作成することができます。

en: Technical Implementation
ja: テクニカル実装

en: This is done using PDF **"Form XObjects"**, see section 8.10 on page 217 of :ref:`AdobeManual`. On execution of a :meth:`Page.show_pdf_page`, the following things happen:
ja: これはPDF **「フォームXObject」** を使用して行われます。 :ref:`AdobeManual` リファレンス の217ページ、セクション8.10を参照してください。 :meth:`Page.show_pdf_page`  が実行されると、次のことが起こります。

en: The :data:`resources` and :data:`contents` objects of source page in source document are copied over to the target document, jointly creating a new **Form XObject** with the following properties. The PDF :data:`xref` number of this object is returned by the method.
ja: ソースドキュメント内のソースページの :data:`resources`  と  :data:`contents` オブジェクトは、ターゲットドキュメントにコピーされ、共同で新しい **フォームXObject** が作成されます。このオブジェクトのPDF  :data:`xref`  番号がメソッドによって返されます。

en: `/BBox` equals `/Mediabox` of the source page
ja: `/BBox` はソースページの `/Mediabox` に等しいです。

en: `/Matrix` equals the identity matrix.
ja: `/Matrix` は単位行列と等しいです。

en: `/Resources` equals that of the source page. This involves a “deep-copy” of hierarchically nested other objects (including fonts, images, etc.). The complexity involved here is covered by MuPDF's grafting [#f1]_ technique functions.
ja: `/Resources` はソースページのものに等しいです。これには、階層的にネストされた他のオブジェクト（フォント、画像など）の「ディープコピー」が含まれます。ここでの複雑さは、MuPDFのグラフティング[1]技術関数によってカバーされています。

en: This is a stream object type, and its stream is an exact copy of the combined data of the source page's :data:`contents` objects.
ja: これはストリームオブジェクトタイプであり、そのストリームはソースページの :data:`contents` オブジェクトの結合データの正確なコピーです。

en: This Form XObject is only executed once per shown source page. Subsequent displays of the same source page will skip this step and only create "pointer" Form XObjects (done in next step) to this object.
ja: このフォームXObjectは、表示されるソースページごとに1回だけ実行されます。同じソースページの後続の表示では、このステップはスキップされ、このオブジェクトへの「ポインター」フォームXObject（次のステップで行われる）のみが作成されます。

en: A second **Form XObject** is then created which the target page uses to invoke the display. This object has the following properties:
ja: 次に、ターゲットページが表示を呼び出すために使用する2番目の **フォームXObject** が作成されます。このオブジェクトには次のような特性があります。

en: `/BBox` equals the `/CropBox` of the source page (or `"clip"`).
ja: `/BBox` はソースページの `/CropBox`（または `"クリップ"` ）に等しいです。

en: `/Matrix` represents the mapping of `/BBox` to the target rectangle.
ja: `/Matrix` は `/BBox` からターゲット矩形へのマッピングを表します。

en: `/XObject` references the previous Form XObject via the fixed name `fullpage`.
ja: `/XObject` は、以前のフォームXObjectを固定された名前 `fullpage` を介して参照します。

en: The stream of this object contains exactly one fixed statement: `/fullpage Do`.
ja: このオブジェクトのストリームには、正確に1つの固定されたステートメントが含まれています： `/fullpage Do` 。

en: If the method's `"oc"` argument is given, its value is assigned to this Form XObject as `/OC`.
ja: メソッドの `「oc」` 引数が指定された場合、その値はこのフォームXObjectに `/OC` として割り当てられます。

en: The :data:`resources` and :data:`contents` objects of the target page are now modified as follows.
ja: ターゲットページの :data:`リソース` と :data:`コンテンツ` オブジェクトは以下のように変更されます。

en: Add an entry to the `/XObject` dictionary of `/Resources` with the name `fzFrm<n>` (with n chosen such that this entry is unique on the page).
ja: `/Resources` の `/XObject` 辞書に、 ` fzFrm ` という名前のエントリをページ内で一意であるように追加します（nはこのエントリがページで一意であるように選択されます）。

en: Depending on `"overlay"`, prepend or append a new object to the page's `/Contents` array, containing the statement `q /fzFrm<n> Do Q`.
ja: `"overlay"` に応じて、ページの `/ Contents` 配列に新しいオブジェクトを前または後に追加し、ステートメント `q / fzFrm<n> Do Q` を含めます。

en: This design approach ensures that:
ja: この設計アプローチは次を保証します：

en: The (potentially large) source page is only copied once to the target PDF. Only small "pointer" Form XObjects objects are created per each target page to show the source page.
ja: （潜在的に大きな）ソースページは、ターゲットPDFに1度だけコピーされます。各ターゲットページごとに、ソースページを表示するための小さな「ポインター」フォームXObjectオブジェクトが作成されます。

en: Each referring target page can have its own `"oc"` parameter to control the source page's visibility individually.
ja: 参照する各ターゲットページは、ソースページの表示を個別に制御するための独自の `「oc」` パラメータを持つことができます。

en: Redirecting Error and Warning Messages
ja: エラーと警告メッセージのリダイレクト

en: Since MuPDF version 1.16 error and warning messages can be redirected via an official plugin.
ja: MuPDFバージョン1.16以降、エラーと警告メッセージは公式プラグインを介してリダイレクトできます。

en: PyMuPDF will put error messages to `sys.stderr` prefixed with the string "mupdf:". Warnings are internally stored and can be accessed via *fitz.TOOLS.mupdf_warnings()*. There also is a function to empty this store.
ja: PyMuPDFはエラーメッセージを、先頭に文字列「mupdf:」を付けて `sys.stderr` に表示します。警告は内部で保存され、*fitz.TOOLS.mupdf_warnings()* を通じてアクセスできます。また、この保存領域を空にするための関数も存在します。

en: Footnotes
ja: 脚注

en: MuPDF supports "deep-copying" objects between PDF documents. To avoid duplicate data in the target, it uses so-called "graftmaps", like a form of scratchpad: for each object to be copied, its :data:`xref` number is looked up in the graftmap. If found, copying is skipped. Otherwise, the new :data:`xref` is recorded and the copy takes place. PyMuPDF makes use of this technique in two places so far: :meth:`Document.insert_pdf` and :meth:`Page.show_pdf_page`. This process is fast and very efficient, because it prevents multiple copies of typically large and frequently referenced data, like images and fonts. However, you may still want to consider using garbage collection (option 4) in any of the following cases:
ja: MuPDFはPDFドキュメント間でオブジェクトを「ディープコピー」することをサポートしています。対象の中で重複するデータを避けるために、「グラフトマップ」と呼ばれる仕組みを使用します。これはスクラッチパッドのようなもので、コピーされる各オブジェクトについて、その :data:`xref` 番号をグラフトマップで調べます。もし見つかれば、コピーはスキップされます。それ以外の場合は、新しい :data:`xref` が記録され、コピーが行われます。PyMuPDFは、:meth:`Document.insert_pdf` と :meth:`Page.show_pdf_page` の2つの場所でこの技術を使用しています。このプロセスは高速で非常に効率的です。なぜなら、通常大きなデータや頻繁に参照されるデータ（画像やフォントなど）の複数のコピーを防ぐためです。ただし、次のいずれかの場合にはガベージコレクション（オプション4）の使用を検討することをお勧めします：

en: The target PDF is not new / empty: grafting does not check for resources that already existed (e.g. images, fonts) in the target document before opening it.
ja: 対象のPDFが新しい/空でない場合：グラフティングは、対象ドキュメント内で既に存在しているリソース（例：画像、フォント）をチェックしません。

en: Using :meth:`Page.show_pdf_page` for more than one source document: each grafting occurs **within one source** PDF only, not across multiple. So if e.g. the same image exists in pages from different source PDFs, then this will not be detected until garbage collection.
ja: 複数のソースドキュメントで :meth:`Page.show_pdf_page` を使用する場合：グラフティングは **1つのソース** PDF内でのみ発生し、複数のソースPDF間では発生しません。したがって、同じ画像が異なるソースPDFのページに存在する場合、これはガベージコレクションまで検出されません
