PyMuPDF 1.23.0rc1 - en to ja translation catalogue (45 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: Glossary
ja: 用語集

en: A Python sequence of 6 numbers.
ja: 6つの数字からなるPythonのシーケンス。

en: A Python sequence of 4 numbers.
ja: 4つの数字からなるPythonのシーケンス。

en: A Python sequence of 4 integers.
ja: 4つの整数からなるPythonのシーケンス。

en: A Python sequence of 2 numbers.
ja: 2つの数字からなるPythonのシーケンス。

en: A Python sequence of 4 :data:`point_like` items.
ja: 4つの :data:`point_like` アイテムからなるPythonのシーケンス。

en: A number of values in a PDF can inherited by objects further down in a parent-child relationship. The mediabox (physical size) of pages may for example be specified only once or in some node(s) of the :data:`pagetree` and will then be taken as value for all *kids*, that do not specify their own value.
ja: PDF内のいくつかの値は、親子関係で下位のオブジェクトに継承されることがあります。例えば、ページのmediabox（物理的なサイズ）は一度だけ指定されるか、:data:`pagetree` のいくつかのノードで指定され、それ以外の値を指定しない子供たちにとってその値が取得されます。

en: A PDF array of 4 floats specifying a physical page size -- (:data:`inheritable`, mandatory). This rectangle should contain all other PDF  -- optional -- page rectangles, which may be specified in addition: CropBox, TrimBox, ArtBox and BleedBox. Please consult :ref:`AdobeManual` for details. The MediaBox is the only rectangle, for which there is no difference between MuPDF and PDF coordinate systems: :attr:`Page.mediabox` will always show the same coordinates as the `/MediaBox` key in a page's object definition. For all other rectangles, MuPDF transforms y coordinates such that the **top** border is the point of reference. This can sometimes be confusing -- you may for example encounter a situation like this one:
ja: 物理的なページサイズを指定する4つの浮動小数点数からなるPDF配列 -（:data:`inheritable`、必須）。この矩形には、追加で指定できる他のすべてのPDFページ矩形を含める必要があります。これらの矩形にはCropBox、TrimBox、ArtBox、BleedBoxがあります。詳細については、 :ref:`AdobeManual`  を参照してください。MediaBoxは、MuPDFとPDFの座標系の間に違いがない唯一の矩形です。 :attr:`Page.mediabox` は常に、ページオブジェクト定義内の `/MediaBox` キーと同じ座標を示します。他のすべての矩形に関して、MuPDFはy座標を変換し、上部境界が参照点となるようにします。これは時に混乱することがあります。例えば、次のような状況に遭遇することがあります。

en: The page definition contains the following identical values: `/MediaBox [ 36 45 607.5 765 ]`, `/CropBox [ 36 45 607.5 765 ]`.
ja: ページ定義には次のような同一の値が含まれています:  `/MediaBox [ 36 45 607.5 765 ]` 、 `/CropBox [ 36 45 607.5 765 ]`。

en: PyMuPDF accordingly shows `page.mediabox = Rect(36.0, 45.0, 607.5, 765.0)`.
ja: したがって、PyMuPDFは `page.mediabox = Rect(36.0, 45.0, 607.5, 765.0)` と表示します。

en: **BUT:** `page.cropbox = Rect(36.0, 0.0, 607.5, 720.0)`, because the two y-coordinates have been transformed (45 subtracted from both of them).
ja: しかし、 `page.cropbox = Rect(36.0, 0.0, 607.5, 720.0)` です。なぜなら、2つのy座標が変換されているため（両方から45が引かれているため）です。

en: A PDF array of 4 floats specifying a page's visible area -- (:data:`inheritable`, optional). It is the default for TrimBox, ArtBox and BleedBox. If not present, it defaults to MediaBox. This value is **not affected** if the page is rotated -- in contrast to :attr:`Page.rect`. Also, other than the page rectangle, the top-left corner of the cropbox may or may not be *(0, 0)*.
ja: ページの可視領域を指定する4つの浮動小数点数からなるPDF配列 -（:data:`inheritable`、任意）。これはTrimBox、ArtBox、BleedBoxのデフォルト値です。存在しない場合、デフォルトはMediaBoxです。この値はページが回転している場合には影響を受けません -  :attr:`Page.rect` とは対照的です。また、ページ矩形以外では、クロップボックスの左上隅が(0, 0)であるかどうかは問題ありません。

en: A central PDF :data:`dictionary` -- also called the "root" -- containing document-wide parameters and pointers to many other information. Its :data:`xref` is returned by :meth:`Document.pdf_catalog`.
ja: 中央のPDF :data:`dictionary` - または「ルート」とも呼ばれる - で、文書全体のパラメータと多くの他の情報へのポインタを含んでいます。その :data:`xref` は :meth:`Document.pdf_catalog` で返されます。

en: More precisely, the **PDF trailer** contains information in :data:`dictionary` format. It is usually located at the file's end. In this dictionary, you will find things like the xrefs of the catalog and the metadata, the number of :data:`xref` numbers, etc. Here is the definition of the PDF spec:
ja: より正確には、PDFトレーラーには :data:`dictionary` 形式の情報が含まれています。通常、ファイルの末尾に配置されています。この辞書には、カタログやメタデータの :data:`xref` 、:data:`xref` の数などが含まれています。PDF仕様の定義は次のとおりです：

en: *"The trailer of a PDF file enables an application reading the file to quickly find the cross-reference table and certain special objects. Applications should read a PDF file from its end."*
ja: 「PDFファイルのトレーラーは、ファイルを読むアプリケーションがクロスリファレンステーブルと特定の特別なオブジェクトを迅速に見つけることを可能にします。アプリケーションはPDFファイルを末尾から読むべきです。」

en: To access the trailer in PyMuPDF, use the usual methods :meth:`Document.xref_object`, :meth:`Document.xref_get_key` and :meth:`Document.xref_get_keys` with `-1` instead of a positive xref number.
ja: PyMuPDFでトレーラーにアクセスするには、通常の方法で :meth:`Document.xref_object` 、 :meth:`Document.xref_get_key` 、:meth:`Document.xref_get_keys` を使用し、正のxref番号の代わりに `-1` を指定します。

en: A **content stream** is a PDF :data:`object` with an attached :data:`stream`, whose data consists of a sequence of instructions describing the graphical elements to be painted on a page, see "Stream Objects" on page 19 of :ref:`AdobeManual`. For an overview of the mini-language used in these streams, see chapter "Operator Summary" on page 643 of the :ref:`AdobeManual`. A PDF :data:`page` can have none to many contents objects. If it has none, the page is empty (but still may show annotations). If it has several, they will be interpreted in sequence as if their instructions had been present in one such object (i.e. like in a concatenated string). It should be noted that there are more stream object types which use the same syntax: e.g. appearance dictionaries associated with annotations and Form XObjects.
ja: コンテンツストリームは、PDF :data:`object` に添付された :data:`stream` を持ち、そのデータはページに描画されるグラフィカル要素を記述する命令のシーケンスから成り立っています。 :ref:`AdobeManual` の「Stream Objects」（p.19）を参照してください。これらのストリームで使用されるミニ言語の概要については、 :ref:`AdobeManual` の「Operator Summary」章（p.643）をご覧ください。PDFページには0から多くのコンテンツオブジェクトを持つことができます。コンテンツオブジェクトが存在しない場合、ページは空になります（ただし注釈は表示される可能性があります）。複数のコンテンツオブジェクトがある場合、それらは1つのオブジェクトに存在するかのように順番に解釈されます（つまり、連結された文字列のように）。なお、同じ構文を使用する他のストリームオブジェクトタイプもあることに注意してください。たとえば、注釈に関連する外観辞書やフォームXObjectなどです。

en: PyMuPDF provides a number of methods to deal with contents of PDF pages:
ja: PyMuPDFは、PDFページのコンテンツに対処するためのいくつかのメソッドを提供しています：

en: :meth:`Page.read_contents()` -- reads and concatenates all page contents into one `bytes` object.
ja: :meth:`Page.read_contents()` – ページのすべてのコンテンツを読み込んで1つのバイトオブジェクトに連結します。

en: :meth:`Page.clean_contents()` -- a wrapper of a MuPDF function that reads, concatenates and syntax-cleans all page contents. After this, only one `/Contents` object will exist. In addition, page :data:`resources` will have been synchronized with it such that it will contain exactly those images, fonts and other objects that the page actually references.
ja: :meth:`Page.clean_contents()` – MuPDFの関数をラップして、ページのすべてのコンテンツを読み込んで連結し、構文をクリーンアップします。これにより、1つの  `/Contents` オブジェクトのみが存在します。さらに、ページの :data:`resources` はそれと同期され、ページが実際に参照する画像、フォント、その他のオブジェクトのみが含まれるようになります。

en: :meth:`Page.get_contents()` -- return a list of :data:`xref` numbers of a page's :data:`contents` objects. May be empty. Use :meth:`Document.xref_stream()` with one of these xrefs to read the resp. contents section.
ja: :meth:`Page.get_contents()` – ページの :data:`contents` オブジェクトの :data:`xref` 番号のリストを返します。空かもしれません。:meth:`Document.xref_stream()` をこれらのxrefの1つとともに使用して、対応するコンテンツセクションを読み込むことができます。

en: :meth:`Page.set_contents()` -- set a page's `/Contents` key to the provided :data:`xref` number.
ja: :meth:`Page.set_contents()` – ページの `/Contents` キーを指定されたxref番号に設定します。

en: A :data:`dictionary` containing references to any resources (like images or fonts) required by a PDF :data:`page` (required, inheritable, :ref:`AdobeManual` p. 81) and certain other objects (Form XObjects). This dictionary appears as a sub-dictionary in the object definition under the key */Resources*. Being an inheritable object type, there may exist "parent" resources for all pages or certain subsets of pages.
ja: PDFページに必要なリソース（画像やフォントなど）への参照を含む :data:`dictionary`（必須、継承可能、 :ref:`AdobeManual`  p. 81）および一部の他のオブジェクト（フォームXObject）が必要です。この :data:`dictionary` は、オブジェクト定義内のキー/リソースの下にサブ辞書として表示されます。継承可能なオブジェクトタイプであるため、すべてのページまたは一部のページの「親」リソースが存在する可能性があります。

en: A PDF :data:`object` type, which is somewhat comparable to the same-named Python notion: "A dictionary object is an associative table containing pairs of objects, known as the dictionary's entries. The first element of each entry is the key and the second element is the value. The key must be a name (...). The value can be any kind of object, including another dictionary. A dictionary entry whose value is null (...) is equivalent to an absent entry." (:ref:`AdobeManual` p. 18).
ja: PDF :data:`object` のタイプで、同じ名前のPythonの概念に多少似ています。「辞書オブジェクトは、辞書のエントリとして知られるオブジェクトのペアを含む連想テーブルです。各エントリの最初の要素はキーであり、2番目の要素は値です。キーは名前である必要があります（...）。値は他の辞書を含む他の種類のオブジェクトであることができます。値がnull (...) の辞書エントリは、不在のエントリと同等です。」（:ref:`AdobeManual` p. 18）。

en: Dictionaries are the most important :data:`object` type in PDF. Here is an example (describing a :data:`page`)::
ja: 辞書は、PDF内で最も重要なオブジェクトのタイプです。以下は、:data:`page` を記述する例です::

en: *Contents*, *Type*, *MediaBox*, etc. are **keys**, *40 0 R*, *Page*, *[0 0 595.32 841.92]*, etc. are the respective **values**. The strings *"<<"* and *">>"* are used to enclose object definitions.
ja: Contents、Type、MediaBoxなどはキーであり、40 0 R、Page、[0 0 595.32 841.92]などはそれぞれの値です。「<<」と「>>」という文字列は、オブジェクト定義を括るために使用されます。

en: This example also shows the syntax of **nested** dictionary values: *Resources* has an object as its value, which in turn is a dictionary with keys like *ExtGState* (with the value *<</R7 26 0 R>>*, which is another dictionary), etc.
ja: この例は、ネストされた辞書の値の構文も示しています。Resourcesはその値としてオブジェクトを持ち、それ自体がExtGState（値は<</R7 26 0 R>>で、これは別の辞書です）、などのキーを持つ辞書です。

en: A PDF page is a :data:`dictionary` object which defines one page in a PDF, see :ref:`AdobeManual` p. 71.
ja: PDFページは、PDF内の1つのページを定義する :data:`dictionary` オブジェクトであり、 :ref:`AdobeManual` p. 71を参照してください。

en: The pages of a document are accessed through a structure known as the page tree, which defines the ordering of pages in the document. The tree structure allows PDF consumer applications, using only limited memory, to quickly open a document containing thousands of pages. The tree contains nodes of two types: intermediate nodes, called page tree nodes, and leaf nodes, called page objects. (:ref:`AdobeManual` p. 75).
ja: 文書のページは、ページツリーとして知られる構造を介してアクセスされ、文書内のページの順序を定義します。このツリー構造により、限られたメモリしか使用しないPDFコンシューマーアプリケーションでも、数千ページを含む文書を迅速に開くことができます。ツリーには2種類のノードが含まれています。中間ノードはページツリーノードと呼ばれ、葉ノードはページオブジェクトと呼ばれます。（:ref:`AdobeManual` p. 75）。

en: While it is possible to list all page references in just one array, PDFs with many pages are often created using *balanced tree* structures ("page trees") for faster access to any single page. In relation to the total number of pages, this can reduce the average page access time by page number from a linear to some logarithmic order of magnitude.
ja: ページ参照を単一の配列でリストすることは可能ですが、多くのページを含むPDFは、より迅速な単一ページへのアクセスのためにバランスの取れたツリー構造（「ページツリー」）を使用して作成されることがよくあります。全ページ数に対して、これにより平均ページアクセス時間がページ番号による線形から対数のオーダーに削減されることがあります。

en: For fast page access, MuPDF can use its own array in memory -- independently from what may or may not be present in the document file. This array is indexed by page number and therefore much faster than even the access via a perfectly balanced page tree.
ja: 高速なページアクセスのために、MuPDFは独自のメモリ内配列を使用できます - 文書ファイルに存在するかどうかに関係なく。この配列はページ番号でインデックスされるため、完全にバランスが取れたページツリーを経由するアクセスよりもはるかに高速です。

en: Similar to Python, PDF supports the notion *object*, which can come in eight basic types: boolean values ("true" or "false"), integer and real numbers, strings (**always** enclosed in brackets -- either "()", or "<>" to indicate hexadecimal), names (must always start with a "/", e.g. `/Contents`), arrays (enclosed in brackets "[]"), dictionaries (enclosed in brackets "<<>>"), streams (enclosed by keywords "stream" / "endstream"), and the null object ("null") (:ref:`AdobeManual` p. 13). Objects can be made identifiable by assigning a label. This label is then called *indirect* object. PyMuPDF supports retrieving definitions of indirect objects via their cross reference number via :meth:`Document.xref_object`.
ja: Pythonに類似して、PDFはオブジェクトの概念をサポートしており、8つの基本型があります：ブール値（「true」または「false」）、整数と実数、文字列（常に括弧で囲まれています - 「()」または「<>」で16進数を示す）、名前（必ず「/」で始まる必要があります、例： `/Contents`）、配列（括弧「[]」で囲まれています）、辞書（括弧「<<>>」で囲まれています）、ストリーム（キーワード「stream」/「endstream」で囲まれています）、およびヌルオブジェクト（「null」）（:ref:`AdobeManual` p. 13）。オブジェクトはラベルを割り当てることで識別可能にすることができます。このラベルは、間接オブジェクトと呼ばれます。PyMuPDFは、:meth:`Document.xref_object`  を介して間接オブジェクトの定義をクロスリファレンス番号を使って取得することができます。

en: A PDF :data:`dictionary` :data:`object` type which is followed by a sequence of bytes, similar to Python *bytes*. "However, a PDF application can read a stream incrementally, while a string must be read in its entirety. Furthermore, a stream can be of unlimited length, whereas a string is subject to an implementation limit. For this reason, objects with potentially large amounts of data, such as images and page descriptions, are represented as streams." "A stream consists of a :data:`dictionary` followed by zero or more bytes bracketed between the keywords *stream* and *endstream*"::
ja: PDFの :data:`dictionary` :data:`object` タイプで、Pythonのbytesに似たバイト列が続きます。ただし、「PDFアプリケーションはストリームを段階的に読むことができますが、文字列は完全に読む必要があります。さらに、ストリームの長さは無制限ですが、文字列は実装の制限に従います。そのため、画像やページの説明などの大量のデータを含むオブジェクトは、ストリームとして表現されます。」「ストリームは、キーワード「stream」と「endstream」で囲まれた0バイト以上のバイトで構成される :data:`dictionary` の後に続きます」::

en: See :ref:`AdobeManual` p. 19. PyMuPDF supports retrieving stream content via :meth:`Document.xref_stream`. Use :meth:`Document.is_stream` to determine whether an object is of stream type.
ja: :ref:`AdobeManual` p. 19を参照してください。PyMuPDFは、:meth:`Document.xref_stream` を介してストリームコンテンツを取得するサポートを提供しています。オブジェクトがストリームタイプかどうかを判断するには、:meth:`Document.is_stream` を使用します。

en: A mathematical notion meaning a vector of norm ("length") 1 -- usually the Euclidean norm is implied. In PyMuPDF, this term is restricted to :ref:`Point` objects, see :attr:`Point.unit`.
ja: 数学的な概念で、ノルム（「長さ」）が1のベクトルを意味します。通常、ユークリッドノルムが含まれます。PyMuPDFでは、この用語は :ref:`Point` オブジェクトに制限されます。:attr:`Point.unit` を参照してください。

en: Abbreviation for cross-reference number: this is an integer unique identification for objects in a PDF. There exists a cross-reference table (which may physically consist of several separate segments) in each PDF, which stores the relative position of each object for quick lookup. The cross-reference table is one entry longer than the number of existing object: item zero is reserved and must not be used in any way. Many PyMuPDF classes have an *xref* attribute (which is zero for non-PDFs), and one can find out the total number of objects in a PDF via :meth:`Document.xref_length` *- 1*.
ja: クロスリファレンス番号の省略形：これはPDF内のオブジェクトに対する一意の識別子である整数です。各PDFにはクロスリファレンステーブルが存在し（物理的には複数の別々のセグメントで構成される場合があります）、各オブジェクトの相対位置をクイックルックアップのために保存します。クロスリファレンステーブルは既存のオブジェクトの数よりも1つ長いエントリを持っており、アイテム0は予約され、何の方法でも使用してはいけません。多くのPyMuPDFクラスにはxref属性（非PDFの場合はゼロ）があり、:meth:`Document.xref_length` - 1を介してPDF内のオブジェクトの総数を知ることができます。

en: When referring to font size this metric is measured in points where 1 inch = 72 points.
ja: フォントサイズを指す際、このメトリックは1インチ = 72ポイントとして測定されます。

en: Images and :ref:`Pixmap` objects may contain resolution information provided as "dots per inch", dpi, in each direction (horizontal and vertical). When MuPDF reads an image from a file or from a PDF object, it will parse this information and put it in :attr:`Pixmap.xres`, :attr:`Pixmap.yres`, respectively. If it finds no meaningful information in the input (like non-positive values or values exceeding 4800), it will use "sane" defaults instead. The usual default value is 96, but it may also be 72 in some cases (e.g. for JPX images).
ja: イメージや :ref:`Pixmap` オブジェクトには、各方向（水平および垂直）の「インチあたりのドット数」である解像度情報が含まれている場合があります。MuPDFはファイルまたはPDFオブジェクトからイメージを読み取る際、この情報を解析し、それぞれ :attr:`Pixmap.xres` 、:attr:`Pixmap.yres` に設定します。入力内で有意義な情報が見つからない場合（非正の値や4800を超える値など）、代わりに「適切な」デフォルト値を使用します。通常のデフォルト値は96ですが、一部の場合（例えばJPXイメージの場合）は72になる場合もあります。

en: Optional content properties dictionary - a sub :data:`dictionary` of the PDF :data:`catalog`. The central place to store optional content information, which is identified by the key `/OCProperties`. This dictionary has two required and one optional entry: (1) `/OCGs`, required, an array listing all optional content groups, (2) `/D`, required, the default optional content configuration dictionary (OCCD), (3) `/Configs`, optional, an array of alternative OCCDs.
ja: オプショナルコンテンツプロパティ辞書（OCPD） - PDF :data:`catalog` のサブ :data:`dictionary`。オプショナルコンテンツ情報を保存する中心的な場所で、キー `/OCProperties` で識別されます。この辞書には2つの必須エントリと1つのオプションエントリがあります：（1） `/OCGs` 、必須、すべてのオプショナルコンテンツグループをリストする配列、（2） `/D` 、必須、デフォルトのオプショナルコンテンツ構成辞書（OCCD）、（3） `/Configs` 、オプション、代替のOCCDの配列。

en: Optional content configuration dictionary - a PDF :data:`dictionary` inside the PDF :data:`OCPD`. It stores a setting of ON / OFF states of OCGs and how they are presented to a PDF viewer program. Selecting a configuration is quick way to achieve temporary mass visibility state changes. After opening a PDF, the `/D` configuration of the :data:`OCPD` is always activated. Viewer should offer a way to switch between the `/D`, or one of the optional configurations contained in array `/Configs`.
ja: オプショナルコンテンツ構成辞書（OCCD） - PDF :data:`OCPD` 内のPDF :data:`dictionary`。これはOCGのON / OFF状態とPDFビューアプログラムにどのように表示されるかの設定を保存します。構成を選択することは、一時的な質量表示状態の変更を素早く行う方法です。PDFを開いた後、:data:`OCPD` の `/D` 構成は常にアクティブになります。ビューアは `/D` 、または配列 `/Configs` に含まれるオプショナル構成のいずれかに切り替える方法を提供する必要があります。

en: Optional content group -- a :data:`dictionary` object used to control the visibility of other PDF objects like images or annotations. Independently on which page they are defined, objects with the same OCG can simultaneously be shown or hidden by setting their OCG to ON or OFF. This can be achieved via the user interface provided by many PDF viewers (Adobe Acrobat), or programmatically.
ja: オプショナルコンテンツグループ（OCG） - 画像や注釈などの他のPDFオブジェクトの表示を制御するために使用される :data:`dictionary` オブジェクト。どのページで定義されているかに関係なく、同じOCGを持つオブジェクトは、OCGをONまたはOFFに設定することで同時に表示または非表示にできます。これは多くのPDFビューア（Adobe Acrobat）が提供するユーザーインターフェース、またはプログラムを使用して達成できます。

en: Optional content membership dictionary -- a :data:`dictionary` object which can be used like an :data:`OCG`: it has a visibility state. The visibility of an OCMD is **computed:** it is a logical expression, which uses the state of one or more OCGs to produce a boolean value. The expression's result is interpreted as ON (true) or OFF (false).
ja: オプショナルコンテンツメンバーシップ辞書（OCMD） - :data:`OCG` のように使用できる辞書オブジェクトで、表示状態を持ちます。OCMDの表示は計算されます：これはOCGの1つ以上の状態を使用してブール値を生成する論理式です。式の結果はON（true）またはOFF（false）として解釈されます。

en: Some frequent character combinations are represented by their own special glyphs in more advanced fonts. Typical examples are "fi", "fl", "ffi" and "ffl". These compounds are called *ligatures*. In PyMuPDF text extractions, there is the option to either return the corresponding unicode unchanged, or split ligatures up into their constituent parts: "fi" ==> "f" + "i", etc.
ja: 一部の頻繁な文字の組み合わせは、より高度なフォントでは固有の特別なグリフで表されます。典型的な例には「fi」、「fl」、「ffi」、「ffl」などがあります。これらの複合体はリガチャと呼ばれます。PyMuPDFのテキスト抽出では、対応するユニコードを変更せずに返すオプションがあり、またリガチャをその構成要素に分割することもできます：「fi」 ==> 「f」+「i」など。
