fix: update docling prediction provider to include word cells

[samiuc]

DoclingPredictionProvider returned 0 F1, Recall, and Precision scores during evaluation and upon investigation, I found out that the word cells were not being populated in the SegmentedPage object that OCREvaluator uses for calculating metrics, so added a fix to copy cells from the original page to the parsed_page (SegmentedPage) word cells object.

[mergify]

Merge Protections

Your pull request matches the following merge protections and will not be merged until they are valid.

🔴 Require two reviewer for test updates

This rule is failing.

When test data is updated, we require two reviewers

• #approved-reviews-by >= 2

🟢 Enforce conventional commit

Wonderful, this rule succeeded.

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert)(?:\(.+\))?(!)?:

[cau-git]

This check is already done on the caller side, through ... for p in res.pages if p.parsed_page. No need to repeat it here.

[samiuc]

Actually, the type checker was throwing error as it still sees parsed_page as Optional[SegmentedPdfPage] and throws the union-attr error. So I had to add this check explicitly

error: Item "None" of "SegmentedPdfPage | None" has no attribute "word_cells"  [union-attr]
            page.parsed_page.word_cells = page.cells
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~

[cau-git]

This is going to inject fake cells into the word_cells of a parsed_page. The only case in which that is currently a valid case is when the document was fully OCRed, hence this is a very partial workaround.

Also please consider that...

• The standard OCR options in Docling are generating line-level cells (TextCellUnit.LINE), not word-level cells. So this would not compare.
• The parsed_page will be populated from Docling, this code would simply overwrite the word_cells without checking if some are present (they will be present whenever the source PDF hat programmatic cells)