なぜチャンカーは 3 つあるのか
PDF チャンカー、lines チャンカー、page チャンカーがすべて同梱される理由を、チャンクの座標がどこから来るかから読み解く。
チャンクは呼び出し側が検索する単位であり、プレイグラウンドがページの上に描く単位です。だから チャンクは 2 つのものを求めます。リーダーが作ったテキストと、それがページのどこにあるかを言う ボックスです。リーダーが残していくものはどれも同じではなく、それが組み込みのチャンカーが 1 つではなく 3 つある理由のすべてです。
PDF チャンカーは、ネイティブリーダーが使ったエンジン PDFium でバイト列を開き直し、ファイル自身の レイアウトがグリフを置いた場所で切ります。テキストレイヤーのある PDF であることが必要なので、 スキャンされたページは辞退します。OCR が作ったテキストの座標を持たないからです。何も読めなかった ページを 1 つの画像チャンクにレンダリングし、そのページがベクトルを持てるようにするのもこの チャンカーです。
lines チャンカーはバイト列を決して開きません。OCR エンジンは読んだ各行がどこにあるかを知っており、
generic-ocr はそれを PageOutput.lines、ワイヤーに届かないポートモデルのフィールドに述べます。
lines チャンカーは見つかった行ごとに 1 つのチャンクをそのボックスで切ります。どのメディアタイプでも、
2 度目のエンジン実行なしにです（ADR-0047）。
DXF 図面のテキストも同じ形で位置つきで届きます。行を述べなかったリーダーからは何も得ません。
page チャンカーは床です。あらゆるメディアタイプの読み取り可能なすべてのページを、全テキストを
1 つのチャンクとして bbox_reason: no_geometry で主張します。ビジョンモデルの回答、CSV、メールが
持つのはそれです。fallback = True を設定するので、すべての後ろに並び、より特化したものが主張
しなかったページだけを埋めます。これがなければ、素の pip install indx はチャンクブロックを
1 つも返しません。
ページ 1 つに書き手 1 つ
Section titled “ページ 1 つに書き手 1 つ”エグゼキューターはチャンカーに順に尋ね、ページごとに統合し、最初の回答が勝ちます （ADR-0012）。 あるページに何も答えないことが「自分のものではない」と言う方法なので、各チャンカーは自分が知る ことについて正直でいられます。
これがサンプルの省庁通知です。1 つの文書に、ネイティブの 25 ページとスキャンされた別添 3 ページ。 ボックスの出どころが 2 つに分かれているので、1 つのチャンカーでは 28 ページすべてをボックス付きで 切れません。トレースは誰が何を切ったかを名指し、プレイグラウンドのルート欄はそれをページごとに 繰り返します。
同じ 3 つを、バージョンで
Section titled “同じ 3 つを、バージョンで”同じページへのより良い境界は、同じチャンカーの新しいバージョンで、古いものと並んでインストール
されます（ADR-0067）。
pdf v2 と lines v2 は同じ行を段落にまとめます。3 つのファミリーは残ります。座標は今も 3 つの
場所から来るからです。バージョンが変えるのは、1 つのチャンクがそのうちどれだけをまたぐかです。
スライドのチャンカーは、.pptx ファイルが述べる図形という 4 つ目の座標の出どころに対する同じ
考え方で、ここで省いたのは、この 3 つとページを取り合うことが決してないからです。