Parsing PDF with table and pseudo-tables

[minomgm]

Hi, I'm parsing financial PDFs (Final Terms) that are primarily text-based but contain several tables and pseudo-tables (key-value structures that get classified as TextItem by the layout model instead of TableItem). My end goal is hierarchical chunking of the resulting DoclingDocument.
Given this, what parsing strategy would you recommend?

• Standard PdfPipeline with docling-layout-heron + TableFormer, accepting that pseudo-tables stay as text (sometimes i have all the keys and then all the values) ?
• VlmPipeline with force_backend_text=True and granite_docling, hoping the VLM correctly classifies those structures and produces clean DocTags for chunking?

Is there a third option I'm missing?

One important constraint: I cannot rely on post-processing heuristics (regex, line-based parsers, etc.) because I don't know in advance the structure of all the PDFs I'll need to process — the pipeline must generalize across different Final Terms from different issuers, which may vary significantly in layout.

[dosubot[bot]]

Hi @minomgm! I'm Dosu and I’m helping the docling team.

Great question — this is a well-known pain point with financial PDFs. Here's a summary of your options:

Option 1: StandardPdfPipeline (layout model + TableFormer)

This works well for actual tables but has a structural limitation for pseudo-tables: the layout postprocessor has hardcoded rules that prefer TABLE over KEY_VALUE_REGION classifications, with no public API to override this behavior [1] [2]. So key-value structures will often remain as TextItem. You can try using a larger layout model like DOCLING_LAYOUT_EGRET_LARGE or EGRET_XLARGE for improved structural understanding, or lower the detection score_threshold below the default 0.3, but these are marginal improvements for your use case.

Option 2: VlmPipeline with force_backend_text=True

This is likely your best bet. The VLM approach offers better semantic understanding of complex layouts, forms, and key-value structures compared to the traditional layout model [3]. With force_backend_text=True, the pipeline uses VLM-predicted bounding boxes and structure classification while extracting text deterministically from the PDF backend — reducing hallucination on text-heavy financial docs [4]. The granite_docling model outputs DocTags with spatial markers, so you still get structure for chunking.

Option 3: ThreadedLayoutVlmPipeline (experimental hybrid)

There's a third option you may have missed — the experimental ThreadedLayoutVlmPipeline [5]. It runs the layout model first to detect elements and bounding boxes, then injects those spatial predictions as XML context directly into VLM prompts. This gives the VLM explicit knowledge of document structure before it processes each page. It's not production-ready yet but could be worth testing on your corpus:

from docling.experimental.pipeline.threaded_layout_vlm_pipeline import ThreadedLayoutVlmPipeline
from docling.experimental.datamodel.threaded_layout_vlm_pipeline_options import ThreadedLayoutVlmPipelineOptions

pipeline_options = ThreadedLayoutVlmPipelineOptions(
    vlm_options=GRANITEDOCLING_2STAGE_TRANSFORMERS,
    layout_batch_size=2,
    vlm_batch_size=1,
)

Regarding chunking: HybridChunker will still produce reasonable chunks from key-value TextItems because it respects hierarchical document structure and section headings [6]. You just lose explicit table/key-value metadata — the content is treated as flat text within its section. The contextualize() method prepends section headings which helps downstream RAG.

My recommendation: Start with the VlmPipeline + force_backend_text=True + granite_docling. If results are inconsistent, try the experimental ThreadedLayoutVlmPipeline as it combines the spatial precision of layout detection with VLM semantic understanding. Both generalize across varied layouts without heuristics.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.