Crate docling 

docling.rs: a Rust port of docling.

The public surface mirrors the Python SDK, kept deliberately small:

use docling::{DocumentConverter, SourceDocument};

let converter = DocumentConverter::new();
let result = converter
    .convert(SourceDocument::from_file("input.md").unwrap())
    .unwrap();
println!("{}", result.document.export_to_markdown());

For the PDF/image ML pipeline (pdfium + layout/TableFormer/OCR ONNX), reuse a Pipeline across documents to amortize model loading, instead of the per-call DocumentConverter. Deploying as a service: examples/Dockerfile is a 3-stage build that bakes the binary, native libs, and exported models (including the KV-cached TableFormer decoder) into a slim, Python-free runtime image — see the “Deploy in a container” section of the README.

See docs/MIGRATION.md for the architecture, format-by-format parity status, and how conformance against Python docling is measured.

Modules

backend

Format backends.

base64

Minimal standard-alphabet Base64 codec (RFC 4648): encode for embedding image bytes as data: URIs, decode for reading them back out — avoids a dependency for the two things we need.

chunker

Document chunking for RAG pipelines — the Rust port of docling-core’s docling_core.transforms.chunker.

chunks

Chunk-record JSON export shared by the CLI (--to chunks) and the HTTP server (to=chunks): the hierarchical chunker’s records always, plus the hybrid chunker’s when a tokenizer is available — DOCLING_CHUNK_TOKENIZER, or .models/chunk/tokenizer.json as populated by scripts/install/download_dependencies.sh (requires the chunking build feature; DOCLING_CHUNK_MAX_TOKENS overrides the default budget of 256).

dclx

.dclx packaging: the DocLang OPC archive (doclang.pack counterpart).

video

Video frame sampling for InputFormat::Video (#138 Phase 2).

vlm

VLM pipeline (issue #77) — remote OpenAI-compatible vision endpoint.

Structs

ConfidenceReport

The document-level report (docling’s ConfidenceReport): the four scores aggregated across pages, plus the per-page breakdown. Page keys are the real 1-based page numbers — the same numbering as the JSON export’s pages map (#171), --pages windows included. (docling keys by its 0-based internal page index; ours is the more useful spelling and the difference is documented in docs/MIGRATION.md.)

ConversionResult

The result of converting one crate::SourceDocument.

DoclingDocument

The unified, format-agnostic document produced by every backend.

DocumentConverter

Routes a SourceDocument to the backend for its format and returns a ConversionResult.

EnrichmentOptions

The opt-in enrichment passes, mirroring docling’s PdfPipelineOptions flags (do_picture_classification, do_code_enrichment, do_formula_enrichment). All off by default.

HeadingHierarchyOptions

Options for the heading-hierarchy stage (docling’s HeadingHierarchyOptions, defaults included).

MarkdownStream

An iterator over a document’s Markdown, yielded in document order as conversion progresses. Each item is a chunk to write as-is; concatenating every Ok chunk reproduces the buffered Markdown byte-for-byte.

MarkdownStreamer

Incremental Markdown serializer: feed finalized, in-document-order batches of Nodes and receive Markdown chunks whose concatenation is byte-identical to [to_markdown_images] over the same nodes. This is the streaming counterpart of the buffered serializer — used to emit a document’s Markdown in chunks (e.g. page by page, as the parallel PDF pipeline finishes pages) instead of building the whole string up front.

ModelEntry

One resolved runtime asset — which file a stage would load right now, given the CWD, the env overrides and the int8/fp32 preference.

PictureImage

An extracted picture’s raw encoded bytes plus its mimetype and pixel size — the docling.rs analogue of docling-core’s ImageRef.

Pipeline

A reusable PDF pipeline. The primary worker runs its models on every core, so a single-page / small / image / METS input is converted at full intra-op speed with no pool to load. A document with enough pages instead fans out across a pool of narrower workers processed concurrently. Both load lazily and are cached for reuse, so a one-shot conversion only pays for what it uses.

RenderedPage

One rasterized page from render_pages (#243): the absolute 1-based page number in the source document, the pixel dimensions, and the PNG bytes.

SourceDocument

A loaded input document: its name, detected format, and raw bytes.

Table

A simple row-major table. By default rows[0] is the header row; a TableStructure overlay overrides that and adds column spans.

Enums

ConversionError

Anything that can go wrong while loading or converting a source document.

ConversionStatus

Outcome status of a conversion, mirroring docling.datamodel.base_models.ConversionStatus.

DocItemLabel

Semantic role of a document item, mirroring docling-core’s DocItemLabel.

ImageMode

How pictures are rendered (mirrors docling-core’s ImageRefMode).

InputFormat

A document format supported by docling.rs backends.

Node

A single piece of document content.

OcrLang

OCR recognition language: which PP-OCRv3 model + dictionary pair runs.

OcrMode

Which document regions feed the OCR — docling 2.116’s OcrMode (#254, upstream docling#3710). Upstream restructured its pipeline so OCR runs after layout, on layout regions filtered by the PDF text layer — the architecture this port has always had — and named the strategies:

QualityGrade

docling’s QualityGrade: a score bucketed for human consumption.

Constants

DEFAULT_VIDEO_FRAMES

Default cap on sampled frames per video. Scene changes rarely exceed this in short clips, and uniform fallback at 8 keeps JSON/DCLX output (which embeds the PNGs) within sane bounds.

PDF_ML_COMPILED

Which PDF conversion this build compiled in: the full ML pipeline (pdf feature), the pure-Rust text-layer path (pdf-text, the wasm32 build), or neither. Compile-time facts, exported so downstream crates (whose own features can’t see this crate’s) can branch — e.g. docling-wasm’s host tests, where workspace feature unification may pull pdf in.

PDF_TEXT_COMPILED

True when the pdf-text text-layer-only PDF path is compiled in.

Functions

model_inventory

Resolve the whole runtime model set without loading anything — the exact selection each stage performs at load time (layout honors the int8/fp32 preference, TableFormer its decoder ranking, OCR the language pair), plus the pdfium library. docling-serve exposes this at /v1/config and logs it at startup, so “the server picked up different models” is one curl away instead of a mystery of dissolved tables. Resolution is CWD-relative with an exe-dir fallback, so the answer can legitimately differ between two working directories.

parse_page_range

Parse a user-facing page-range string (issue #80’s --pages): "A-B" for an inclusive 1-based window, or a single "N" for one page. Whitespace around the numbers is tolerated. Validation against the actual page count happens at convert time; this only checks the spelling (first >= 1, first <= last).

pdf_page_count

Number of pages in a PDF, without converting anything — what the CLI batch mode prints in its per-document start line.

pdf_text_layer_pages

convert_text_layer restricted to a 1-based inclusive page window (issue #80’s --pages); None converts everything. The window is validated the same way as Pipeline::pages: first <= last, 1-based, and it must select at least one existing page.

render_pdf_pages

Rasterize a PDF’s pages to PNG (#243) — the lean path behind serve’s to=images: pdfium render only, no text extraction, no models, and only one page bitmap resident at a time (each is PNG-encoded and dropped before the next renders). scale is pixels per PDF point — 2.0 matches the pipeline’s RENDER_SCALE (144 dpi). Unlike the pipeline’s render there is no 1.5× supersample + downsample pass: that dance exists only because TableFormer is pixel-pinned to docling’s bitmaps, and nothing downstream of this output is — a single render is nearly twice as fast.