Problem
When processing PDFs with ocrbridge-ocrmac, the generated hOCR contains ocr_page + ocrx_word elements but no ocr_line/ocrx_line (and typically no ocr_par/ocr_carea).
This breaks downstream searchable-PDF workflows that rely on line/paragraph hierarchy. In our service, compatibility checks fail with line_count=0, and when forced through other pipelines, output can be a PDF without usable searchable text.
Observed behavior
- Engine:
ocrbridge-ocrmac 2.0.0
- Input: PDF
- hOCR stats (representative):
page_count > 0word_count > 0line_count = 0
- Practical result: searchable-PDF generation fails or yields non-searchable output depending on downstream tool.
Suspected root cause
In ocrbridge/engines/ocrmac/engine.py, _convert_to_hocr(...) emits words directly under ocr_page (<span class=\"ocrx_word\">...</span>) and does not construct line/paragraph/area nodes.
Reproduction
- Run
ocrbridge-ocrmac on any multi-line PDF page.
- Inspect generated hOCR.
- Confirm there are
ocrx_word spans but no ocr_line/ocrx_line classes.
- Feed that hOCR into a searchable-PDF overlay pipeline (e.g.,
pdfocr) and observe incompatibility or missing text layer.
Expected behavior
Generated hOCR for PDF input should include a structure consumable by common hOCR->PDF tools, ideally one of:
ocr_page -> ocr_line -> ocrx_word, orocr_page -> ocr_par/ocr_carea -> (ocr_line?) -> ocrx_word
Suggested fix
- Group OCR annotations into lines (and optionally paragraphs/areas), then emit corresponding hOCR containers before words.
- Keep existing bbox + confidence attributes on words.
Why this matters
ocrbridge-ocrmac currently produces valid-looking hOCR for words, but the missing hierarchy reduces interoperability and can lead to false-success PDF conversion outcomes in production OCR services.
Problem
When processing PDFs with
ocrbridge-ocrmac, the generated hOCR containsocr_page+ocrx_wordelements but noocr_line/ocrx_line(and typically noocr_par/ocr_carea).This breaks downstream searchable-PDF workflows that rely on line/paragraph hierarchy. In our service, compatibility checks fail with
line_count=0, and when forced through other pipelines, output can be a PDF without usable searchable text.Observed behavior
ocrbridge-ocrmac2.0.0page_count > 0word_count > 0line_count = 0Suspected root cause
In
ocrbridge/engines/ocrmac/engine.py,_convert_to_hocr(...)emits words directly underocr_page(<span class=\"ocrx_word\">...</span>) and does not construct line/paragraph/area nodes.Reproduction
ocrbridge-ocrmacon any multi-line PDF page.ocrx_wordspans but noocr_line/ocrx_lineclasses.pdfocr) and observe incompatibility or missing text layer.Expected behavior
Generated hOCR for PDF input should include a structure consumable by common hOCR->PDF tools, ideally one of:
ocr_page -> ocr_line -> ocrx_word, orocr_page -> ocr_par/ocr_carea -> (ocr_line?) -> ocrx_wordSuggested fix
Why this matters
ocrbridge-ocrmaccurrently produces valid-looking hOCR for words, but the missing hierarchy reduces interoperability and can lead to false-success PDF conversion outcomes in production OCR services.