Search, Layout, and Inspection
Three endpoints read a PDF without changing it: pdf-search finds text and says exactly
where, pdf-layout returns the page geometry viewers and overlays are built from, and
pdf-info reports the document facts a pipeline routes on. Together they are the
observation half of the toolbox: everything the transforming endpoints
do can be verified, located, or decided with these.
1Search: three modes, honest results#
POST /lmkit/v1/pdf-search is a real in-document search engine, not a substring loop:
| Mode | Behavior | Its knobs |
|---|---|---|
Text |
Literal matching | case_sensitive, whole_word |
Regex |
Pattern matching, for references, identifiers, and formats | regex_ignore_case |
Fuzzy |
Tolerant matching by Damerau-Levenshtein edit distance, built for OCR output where "lnvoice" means "Invoice" | max_edit_distance (1 to 10), min_score (0 to 1), token_aware (discounts whitespace splits) |
Normalization applies before matching, each toggle independent: collapse whitespace
(default on), strip diacritics (default on, so "resume" finds "résumé"), strip punctuation,
strip symbols. page_range scopes the scan, context_chars sizes the snippet around each
hit, and max_results caps the sweep, with limited_by_max_results in the response saying
so explicitly, so a capped sweep never masquerades as a complete one.
Every match carries text (as it appears), snippet (with context), score,
page_number, and bounds: the coordinates that turn a search result into a highlight, a
review-UI jump target, or a region for area redaction. Two
compositions do heavy lifting: search an OCR-overlaid scan as if
it were born digital, and search a redacted output for the redacted terms as the
verification step. For a rendered, highlighted copy instead of coordinates, the
highlight endpoint draws it for you.
2Layout: the geometry beneath the text#
POST /lmkit/v1/pdf-layout returns per-page structure: paragraphs, their lines, and
bounding boxes, over an optional page selection, with total_pages and processed_pages
stating coverage. This is the raw material for anything that must point AT a page: viewer
overlays, click-to-select review tools, region pickers that feed
area redaction, and layout-aware chunking for retrieval pipelines
that want paragraph boundaries instead of character counts. The coordinates live in the
same page space as extraction's field bounds and search's
match bounds, so the three compose on one canvas.
3Info: the facts a pipeline routes on#
POST /lmkit/v1/pdf-info answers the questions asked before any work starts, in one call:
page count and PDF version; per-page width and height (layout decisions before rendering);
the metadata block (title, author, subject, keywords, creator, producer, creation and
modification dates); file size; is_pdfa with pdfa_level, the document's declared
archival identity; and is_encrypted with encryption_method and permissions, the
security surface.
That makes pdf-info the triage endpoint of the whole toolbox: encrypted goes to
unlock (or a password rides the next call), a PDF/A DECLARATION
goes to validation because a declaration is a claim, oversized scans get
downsampled expectations, and metadata anomalies get flagged before content is trusted.
4Scope, stated once#
These endpoints read ONE document deeply. Finding which documents in a corpus of thousands
mention a term is a different problem with a different engine:
Search indexes documents for full-text, semantic, and hybrid retrieval.
The rule of thumb: pdf-search answers "where in THIS file"; the search engine answers
"which files".
5Stated plainly#
- Search is three modes with normalization and coordinates, honest about truncation, and fuzzy enough to work on OCR text; its bounds feed highlights and redaction directly.
- Layout exposes paragraphs, lines, and boxes in the same coordinate space extraction and search use, so overlay UIs build on one geometry.
- Info is the one-call triage: archival identity, encryption surface, geometry, and metadata before any transformation is chosen.