Module ocr_prep 

ONNX-free half of the PP-OCRv3 recognition pipeline: everything before and after the session.run call — line segmentation, crop preparation, width-batching, CTC decoding, dictionary handling.

Split out of ocr.rs (which keeps the ort session) so the browser build can reuse it (issue #79 phase 2): docling-wasm runs these exact functions and delegates only the inference call to ONNX Runtime Web on the JS side. Keeping one implementation is what makes the wasm output byte-comparable to the native CPU path — any drift then comes from the runtime, not from pre/post-processing.

Structs

PrepLine

A text-line crop prepared for recognition: resized to the fixed model height, normalised to [-1, 1], laid out CHW.

Constants

REC_BATCH

Cap on lines per recognition run: bounds peak input-tensor memory (16 × 3 × 48 × 2400 px ≈ 22 MB f32) without costing measurable batching benefit — same-width groups are rarely larger.

REC_HEIGHT

PP-OCRv3’s fixed input height.

Functions

batch_input

Pack one width-batch into the model’s (N, 3, H, W) input buffer.

decode_row

Greedy CTC decode of one row’s (T, C) probabilities.

dict_chars

The CTC class table for a recognition dictionary file: index 0 = blank, then one class per dictionary line, then the space class.

is_text_label

Layout labels whose content is recognised as running text.

normalize_polarity

Normalize an image to the scan polarity every stage assumes — dark ink on light paper (the segmentation threshold and the recognition model’s training data both bake it in): a predominantly dark page (mean luma below mid-gray — a dark-mode screenshot, an inverted scan) is inverted. Browser-path helper; the native pipeline never calls it (its input is scanned paper, and the conformance baseline stays untouched).

prep_line

Prepare one line crop, or None for a degenerate (zero-sized) crop.

prep_page_lines

Whole-image line preparation for the browser OCR path (no layout model: the page itself is the single text region). Returns page-order prepared lines; callers that need geometry use segment_lines directly.

prep_region_lines

Gather every text-region line crop on a page, in page order: crop each text region (page points × scale → image px), split it into lines, prep each line, and keep the line’s page-point bbox. The exact gathering the native ocr_page does — shared so the browser path produces the same cells given the same probabilities.

prep_table_words

Gather word crops from a page’s table regions (browser table path, #157 stage 3): crop each table region, split it into lines, split each line into words (segment_words), prep each word for recognition, and keep the word’s page-point bbox. Recognizing table interiors is what gives the cell matcher the word boxes it needs — the native pipeline reads those from pdfium’s text layer, which the browser doesn’t have. NOT used by native.

segment_lines

Split a region crop into text lines via a horizontal ink-projection profile. Returns tight (l, t, r, b) boxes in crop pixels.

segment_words

Split a text line into word tokens by a vertical ink-projection profile: runs of ink columns separated by whitespace wider than ~0.6× the line height (an inter-word/-column gap, not an inter-character one). Returns tight (l, 0, r, h) boxes in line-crop pixels. The browser table path recognizes these individually so each word carries its own box for column matching — the native pipeline gets word boxes from the pdfium text layer instead.

width_batches

Deterministic recognition batching: page-order line indices grouped by exact width (equal widths share a run — bit-identical to one-at-a-time recognition, see ocr.rs), each group split into REC_BATCH chunks.

Type Aliases

LineBox

A line’s page-point bounding box, (l, t, r, b).