Layout misclassifies dotted poetic line as formula, export leaves text empty

[rkudryashov]

Bug

A poetic line with dot leaders (................ жизни картиновой ................ понесло Константиново ».) is misclassified as formula by the layout model (OCR text with ellipsis, not a math formula).

The block is exported as FormulaItem with OCR text in orig, but text is empty / missing. Parse returns success, yet json_content fails DoclingDocument.model_validate_json(). Chunking then fails: Input document parsed.json is not valid.

Setting text from orig fixes validation and chunking.

Root cause (as seen downstream): classification error → invalid schema export.

Steps to reproduce

1. Parse attached 1-page PDF (misprocessed.pdf, poetic excerpt with dot leaders)
2. In json_content, find item with "label": "formula" and dotted Russian text in orig, no text.
3. Validate: ```python
   from docling_core.types.doc import DoclingDocument
   DoclingDocument.model_validate_json(open("parsed.json", "rb").read())

   → fails (`text` required on formula item).
   

4. Chunk same JSON via /v1/chunk/hybrid/source/async (from_formats: ["json_docling"]) → 0 chunks.
5. Add "text": "<same as orig>" → validation and chunking succeed.

Parsing options used:

{
  "do_ocr": false,
  "do_formula_enrichment": false,
  "do_code_enrichment": false,
  "to_formats": ["json", "text"]
}

Minimal fragment:

		{
			"self_ref": "#/texts/5",
			"parent": {
				"$ref": "#/body"
			},
			"content_layer": "body",
			"label": "formula",
			"prov": [omitted],
			"orig": "..................... жизни  картиновой ..................... понесло  Константиново »."
		},
		{
			"self_ref": "#/texts/6",
			"parent": {
				"$ref": "#/body"
			},
			"content_layer": "body",
			"label": "text",
			"prov": [omitted],
			"orig": "(Восп.,  2,  131)",
			"text": "(Восп.,  2,  131)"
		},

Expected: classify as text/paragraph; if labeled formula, populate text (e.g. from orig) so export passes schema validation.

Docling and Python versions

docling-serve output:

Docling version: 2.107.0
Docling Core version: 2.85.0
Docling IBM Models version: 3.13.3
Docling Parse version: 7.2.0
Python: cpython-312 (3.12.13)
Platform: Linux-6.18.33.2-microsoft-standard-WSL2-x86_64-with-glibc2.34

Attachments: 1-page PDF + JSON fragment above.

[dosubot]

Hi @rkudryashov! I'm Dosu and I'm helping the IBM Docling team.

You've identified a real bug. The root cause is in the ReadingOrderModel, which deliberately sets text="" for FORMULA-labeled items, placing the OCR cell text only in orig [1]:

elif label == DocItemLabel.FORMULA:
    current_list = None
    new_item = out_doc.add_text(
        label=DocItemLabel.FORMULA, text="", orig=cap_text, prov=prov
    )

The design assumes the formula enrichment VLM stage will later populate text with LaTeX. But since do_formula_enrichment defaults to False [2], the text field stays empty permanently in the default configuration. Other text element types don't have this problem — they get text populated directly during assembly.

So there are two issues at play:

1. Layout misclassification — the dot-leader poetic line is classified as FORMULA by the layout model (label ID 2 in the 17-label taxonomy) [3]. This is a model accuracy issue that would require retraining or confidence-threshold tuning.

2. Empty text on FORMULA items when enrichment is off — even when the classification is wrong, the exported document should be schema-valid. The fix would be to populate text from the cell text (same as orig) in ReadingOrderModel, so that if enrichment later runs, it can overwrite it with LaTeX, but if it doesn't, the field is still usable.

Your workaround of copying orig into text is correct and matches what the fix should look like.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[zeweihan]

Good bug report — and dosubot's root-cause localization is precise: ReadingOrderModel hardcodes text="" for FORMULA-labeled items, betting that the enrichment stage will fill it later. When do_formula_enrichment=False (the default), the bet silently loses and the field stays empty permanently. A regulated-domain (legal/compliance corpus) lens on why this is a content-survival defect, not a misclassification cosmetic:

1. text="" on a FORMULA item is a one-way content door — the OCR text is in orig but the retrieval-facing field is empty. For any pipeline that chunks/embeds from text (the default export path), the formula region's content is gone before enrichment ever runs. The bytes survived OCR, they're sitting in orig, and the chunker walks right past them because the contract says "read text." No error, no degradation signal — same shape as the EMF/WMF silent-drop class (#3684) and the formula-exclusion-at-ingestion-boundary class where content survives the source but never reaches the chunk stream.

2. The misclassification + empty-text combination makes this worse than either alone. A correctly-classified FORMULA with empty text is at least expected to be filled by enrichment. A misclassified line (poetic dot-leader → FORMULA) with empty text is a structural item that the user's content was forced into, and then its text was blanked — the content was downgraded to formula, then the formula slot was emptied. The downgrade is wrong but at least the item exists; the emptying makes the item retrieve as nothing. Two independent defects compound into silent loss where either alone might have surfaced.

3. The OP's workaround (orig → text) is the right minimal fix, and it generalizes. Populating text from the cell text at assembly time means: if enrichment runs, it overwrites with LaTeX; if enrichment doesn't run, the field is still usable. That's the "emit something, never let a detected region vanish" philosophy — the same one behind formula_render_status and text_coverage signals. The fix isn't "make the layout model better" (that's a separate, harder problem); it's "don't blank a field that downstream depends on, betting on a stage that defaults to off."

4. Cheap orthogonal companion: a text_population_status signal on FORMULA items. When text is empty because enrichment hasn't run, that's a legitimate state — but it should be inspectable, not invisible. A per-item {text_source: orig|enrichment|empty, enrichment_ran: bool} stamp lets a consumer (or audit pass) distinguish "this formula was intentionally left for enrichment" from "this slot is empty and nothing will fill it." Same provenance philosophy as stamping the effective decoding params rather than the configured ones — the artifact's metadata should describe what actually happened, not what was supposed to.

[ceberam]

@rkudryashov Thanks for reporting this issue.

As @dosu pointed out, there are two parts in this issue:

Layout misclassification : the dot-leader poetic line is classified as FORMULA by the layout model

This will need to be addressed separately

Empty text on FORMULA items when enrichment is off

By design, the extracted text of the formula item should be empty if the do_formula_enrichment option is False, which is the default case. This behavior should not be changed and therefore your suggested PR #3788 will not be accepted.

However, I'd like to focus on the fact that you reported a missing text field when the example above (misprocessed.pdf) is converted. This should not happen: text should still appear as a field of the formula item, set to an empty text, in the JSON serialization. I was not able to reproduce this situation.

@rkudryashov could you please share:

• The command to deploy docling-serve. For instance:

  pip install docling-serve
  docling-serve run

• The exact output of the version endpoint. Assuming that it is deployed with the default options, run:

   curl http://localhost:5001/version

• The exact output of the conversion to JSON. With the previous assumptions, run:

  curl -X 'POST' \
  'http://localhost:5001/v1/convert/source' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
   "options": {"to_formats": ["json"]},
   "sources": [{"kind": "http", "url": "https://github.com/user-attachments/files/29854351/misprocessed.pdf"}]
  }'
  

[dosubot]

Thank you for the clarification, @ceberam. I want to correct my earlier analysis on one point:

The maintainer is right that text="" on FORMULA items is by design when do_formula_enrichment=False. The ReadingOrderModel intentionally sets text="" because the enrichment stage is expected to populate it with LaTeX if enabled [1].

Regarding the user's report of a missing text field (not just empty): from reviewing the serialization code in docling-core, there's no obvious path that would drop empty-string fields from JSON output. The text field is defined as a required str without a default [2], and DoclingDocument.export_to_dict() uses exclude_none=True [3] which only excludes None values — not empty strings. The custom serializers only strip empty comments, source, field_regions, and field_items lists [4].

So the reproduction details @ceberam is requesting from the reporter should help clarify whether the text field is truly absent from the serialized JSON or if the issue was something else (e.g., a version mismatch or a downstream consumer stripping empty fields).

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[rkudryashov]

Follow-up on the missing text field.

We re-checked the raw Docling Serve JSON: formula items do contain "text": "" as expected.

The field disappeared later when we serialized the docling-java DoclingDocument with Jackson. Empty text is still present on the Java object, but @JsonInclude(NON_EMPTY) on the model types omits it on write. Application-level Include.ALWAYS does not override that.

So the "missing text → model_validate_json fails" report is not a Docling Serve issue — please consider the missing-field part resolved / not reproducible on Serve’s side. We’ll follow up on the Java client/model side.

The layout misclassification of dotted poetic lines as formulas remains a separate accuracy issue. For now we work around it downstream by copying orig → text when enrichment is disabled.

[edeandrea]

Following up on @rkudryashov 's comment - what is the semantic meaning of the text field? Does docling have any documentation or place any meaning to differentiate "text": "" from "text": null, or the text element itself being absent from the response?

If the presence of the text field in the payload (regardless of value - empty or otherwise) has meaning vs it not being present at all, thats one thing. But if there is no intended meaning on empty value vs absent, then @rkudryashov may have to adjust expectations.

Semantic meaning unfortunately isn't something you can convey in an OpenAPI document...

cc: @ceberam