Docling related issues

[jborsky]

During the evaluation, I've discovered that Docling has some issues with certain documents.

• Documents with atypical dimensions cause the default Docling parser to give errors.
• EasyOCR occasionally misrecognizes digit "1" as letter "I" in certificate identifiers, especially in certificates.
• Some single page certificates are processed as empty because Docling's parser treats them as image elements rather than text content. Then the OCR doesn't enrich it because with the default config, the OCR just merges text elements.
• In some French documents, Docling produces unusual spacing patterns, sometimes inserting spaces within words.

For each issue, there are specific fixes:

• Atypical dimensions: Switch backend to pypdfium (but this produces worse results overall, so only use it for affected documents)
• Empty outputs and French spacing: Force full-page OCR mode, which means Docling doesn't merge OCR with programmatic parsing results. So the text result is purely from OCR.
• OCR misrecognition: Try different OCR engines (Tesseract, RapidOCR)

So the proposed approach could be to implement a multi-step and fallback approach, similar to the pdftotext with Tesseract strategy:

• Convert the entire dataset using "normal" Docling options
• Detect problematic documents (errors, empty outputs, suspected OCR issues, spacing anomalies)
• Reprocess affected documents with alternative configurations based on the detected issue type

[adamjanovsky]

Makes sense. We probably want to avoid branching if possible, so we should probably check if some issues are preventable with different docling settings (that would not break conversion of the remaining documents). If that's the case, we could just stick to updating the settings and don't fallback.

Otherwise, fallbacks are likely the best option, as you suggest. Or, if it's just few documents, then the best option is to ignore the problem :)

[J08nY]

I was kind of hoping that by using Docling these issues would be gone. It seems that with the move we went out of the frying pan and into the fire... Instead of pdftotext producing crappy stuff that we needed to OCR (to hope to fix) we now have Docling doing so. I actually think some of the issues may be exactly the same as with pdftotext. For example the French documents, there we saw the same as something in the pdf structure made it so that pdftotext inserted spaces after every character.

It seems that the whole pdf conversion step in our pipeline deserves some more attention and fine-tuning. Some questions we need to ask:

• Do we want to support multiple PDF conversion tools going forward (pdftotext, Docling)?
• Would it make sense to fallback between these?
• The pdftotext pipeline had (has?) a mechanism where it detected that the converted text is garbage and ran OCR via tesserract on the document instead. Perhaps what @jborsky is describing is a similar approach.

[jborsky]

@J08nY Just to clarify, all the identified issues can be solved using just Docling with different configurations. The proposed fallbacks are simply different Docling settings (switching parser backends, using different OCR engines, enabling full-page OCR mode, etc.), not switching between different tools. The default configuration is optimal for the common case, but some documents hit these cases where a different configuration works better.

As Adam suggested, I'd like to evaluate this further and assess how many documents are actually affected, so we know if this is something we should care about or just ignore.

[J08nY]

Sure I understand the approach, my questions were a bit more exploratory on whether combining the converters may make sense.