When you click a sentence in a PDF, you expect to select a sentence. You expect the words to stay together, the line to wrap normally, and the next edit to behave like an edit to a document.

That expectation is reasonable. It is also not what most PDFs actually store.

A PDF page starts as drawing instructions

A word processor thinks in paragraphs, headings, lists, tables, and margins. A PDF is closer to a set of instructions for painting a finished page:

  • choose a font and size
  • move the text position
  • show some glyphs
  • draw a line or rectangle
  • fill a shape
  • place an image

Those instructions are excellent for preserving a page across printers and operating systems. They do not guarantee that the page contains a paragraph object waiting to be edited.

The visible paragraph might be split across many text operations. Spaces may be represented by a cursor movement instead of an actual space character. Font subsets may contain the visual glyph without a clean mapping back to the character you would type. A table may be nothing more than text, thin rules, filled rectangles, and a lot of carefully repeated coordinates.

This is why PDF editing is harder than it looks. The editor has to infer the structure a reader sees without pretending that the structure was explicitly stored in the file.

Lifting starts with evidence

Papaya PDF calls this process lifting. The engine starts with the display list that it already uses to render the page, then builds increasingly useful objects from the facts in that list.

The important point is that the first question is not "Which text operation did the user click?" It is "Which editable region does that operation belong to?"

That change in perspective matters. A clicked operation is a useful hint about user intent, but it is rarely the whole object the user thinks they selected.

The geometry behind a text region

The lifting pass looks for several signals at once. No single coordinate or string can tell the engine where a paragraph begins and ends.

Baselines form visual rows

Text fragments that share a baseline can form one visual row even when the PDF producer emitted them as separate operations. This handles ordinary cases where one word, glyph cluster, or styled run was painted separately from the next one.

The engine keeps the fragment geometry instead of throwing it away. That makes it possible to reason about the row while preserving the source information needed to edit and write the result.

Gaps reveal words and line flow

PDFs frequently omit literal space characters. A gap between fragments can still carry the meaning of a word boundary, but the gap has to be interpreted in the context of the row, font, and advances around it.

The same idea applies vertically. A small baseline gap is often wrapped line flow. A much larger gap may mark a new paragraph, a disclosure section, or a different kind of content. The useful boundary depends on the surrounding geometry rather than on the words themselves.

Columns and alignment constrain the region

Whitespace gaps can reveal columns. Shared left edges, repeated right edges, font and size patterns, and local text density help distinguish a reading block from a neighboring block.

This matters for forms and reports. A compact block of aligned labels and values can look like a paragraph if the engine only follows paint order. A multi-column page can look like one scrambled stream if the engine ignores the page's gutters.

Provenance protects the edit

The engine also keeps track of where a candidate came from. A recovered text box is associated with its source operations so the original painted text can be suppressed when the editable object takes over.

That ownership boundary is what separates an engine-backed edit from a visual cover-up. The goal is not to draw browser text on top of a PDF screenshot. The goal is to recover an editable object, render it through the engine, and write a valid PDF when the user saves.

Conservative inference beats confident nonsense

Layout recovery is an inference problem, so the engine has to know when not to invent structure.

A few thin lines do not automatically make a table. A tax form can use the same rectangles and rules as a table while representing independent fields instead of repeatable rows. A short group of aligned text may be a list, a form, a notice, or ordinary prose.

When the evidence is weak, Papaya PDF should fall back to ordinary text handling or let the user make an explicit selection. A wrong table object is worse than a missed automatic table because it changes the user's document model and can make later edits surprising.

That is also why the production rules are phrased in terms of reusable layout signals such as baselines, gaps, alignment, styles, source order, and repeated structure. They should not depend on a particular form label, vendor name, or document vocabulary.

Deterministic facts come first

Born-digital PDFs contain exact information that a model should not have to rediscover from pixels: glyph positions, text matrices, font resources, vector paths, fills, annotations, clipping, and source-operation order.

Papaya PDF uses those facts as the foundation. This keeps the core lifting path inspectable, local-first, and tied to the PDF that is actually being edited. Learned layout models and OCR can help with ambiguity or scanned pages, but they should propose or rank candidates. The engine still needs to decide what can become an editable object, how the original source is suppressed, and whether the result can be written back safely.

What works today and what is next

Papaya PDF already supports per-operation text lifting into editable text boxes, and it has a basic selected-region table-lift path. The table path is a rough prototype, so the useful work now is measuring it against real, geometry-rich PDFs and tightening its failure boundaries.

Full structural paragraph lifting is still being built. That work includes paragraph clustering, stable paragraph identity, word and paragraph selection, and deeper reflow editing across arbitrary PDFs. We would rather say that plainly than pretend that every PDF has already become a Word document.

The direction is straightforward even when the implementation is not: recover the smallest trustworthy structure that makes the user's next edit behave like an edit to a document they authored.

For more on the practical side, try editing text in a PDF or read about the hidden font problem in PDFs.