docling-project/docling

Type: Bug (silent content loss; low priority, no real document found with this construct) Component: docling/backend/msword_backend.py (body walk over body.iterchildren()) Environment: docling 2.133.0 / docling-core 2.99.0 / python-docx 1.2.0 / Windows 11 Context & Description <mc:AlternateContent> carries <mc:Choice Requires="..."> (modern markup) and <mc:Fallback> (legacy markup). When it is a direct child of w:body, the main body walk does not descend into it, so every paragraph in the supported Choice branch is lost. Evidence repro/min_alternate_content.docx is a copy of the docling.rs test fixture alternate_content_body.docx (a hand-written Markup Compatibility test file, not a Word output; Word flattens a body-level mc:AlternateContent when it saves, so the construct comes from third-party generators). Result on docling 2.133.0: only the paragraphs before and after survive. Element Python docling 2.133.0 Paragraph before AlternateContent present CHOICE_BRANCH_ACTIVE mis

Type: Bug (silent text loss, document mutated by a read-only export) Component: docling_core/types/doc/document.py, DoclingDocument.validate_misplaced_list_items Environment: docling 2.133.0 / docling-core 2.99.0 / Python 3.14 / Windows 11 Context & Description A list item made of several formatted runs is stored as a ListItem with empty text and one TextItem child per run (under an inline group). When such an item has no ListGroup parent, the model validator validate_misplaced_list_items re-wraps it: it calls delete_items(...) (which removes the item and its subtree) and then add_list_item(text=li.text, ...). Only text, marker, formatting, hyperlink and provenance are passed, never the children. For a multi-run item li.text is "", so the item is re-created empty and its content is gone. The effect is visible only after an export: convert() returns 8 texts, export_to_markdown() / export_to_html() reduce doc.texts to 5 in place and their output lacks the second item. Order matters: exp

Background JATS (Journal Article Tag Suite) is a standardized XML format used to encode, publish, and archive academic and scientific literature. It provides a common set of tags to structure article text, metadata (like authors and affiliations), figures, and citations, allowing research to be shared seamlessly across platforms like PubMed, CrossRef, and SciELO. Docling supports the parsing of JATS through the declarative backend JatsDocumentBackend. The first version was released with version 2.23.0 on Feb 17, 2025. Since then, the DoclingDocument data model has evolved and it now supports features that rich JATS document contain but had to be ignored in the first version. Goal The goal of this issue is to review the JATS backend and implement the parsing of features in JATS documents that can currently be support with DoclingDocument. Some of these features were marked as TODO in the code and thus they should be easy to locate and implement. They include: Footnotes @aaarif796 #3

Requested feature Currently, footnotes are serialized as part of MarkdownDocSerializer more or less as-is: Serialized as: 5 https://github.com/tesseract-ocr/tesseract 6 https://github.com/VikParuchuri/surya 7 https://github.com/lukas-blecher/LaTeX-OCR Alternatives For downstream LLM-based applications it would be helpful if footnotes were serialized as actual footnotes in Markdown Syntax for the LLM to indentify them as footnotes (and not as a numbered list, for example). ^[5 https://github.com/tesseract-ocr/tesseract] ^[6 https://github.com/VikParuchuri/surya] ^[7 https://github.com/lukas-blecher/LaTeX-OCR]

Problem When using ImageRefMode.REFERENCED, users must manually: Iterate through all picture elements Save each image to disk Update the URI for each element Then call export_to_markdown() Proposed Solution Add optional image_dir and image_path_prefix parameters to export methods: markdown = doc.export_to_markdown( image_mode=ImageRefMode.REFERENCED, image_dir=Path("./output/images"), image_path_prefix="images/" # relative path in markdown output ) When image_dir is provided: Automatically save images to that directory Generate sequential filenames (e.g. image_001.png) Use image_path_prefix in the markdown output Affected Methods DoclingDocument.export_to_markdown() PictureItem.export_to_markdown() Potentially HTML export methods too Would this be an interesting feature to have? Happy to submit a PR. (PS: Keep up the great work!!)