Bounding Box margin for text

[xave]

There's lots of technical terms for PDFs, so "Bounding Box margin" may not be the correct term.

But, the issue is as follows:

Command:

 ocrmypdf --force-ocr --output-type pdf input.pdf output.pdf 

With the default ocrmypdf, I get a text boundary that tightly hugs the font. When I then annotate the PDF with an underline, the underline slices through the very bottom of the text.

To put it another way: When I underline text via annotation, I get a strikethrough aligned at the very bottom of the text, inside the letters not below it.

I would like to ocr the PDF such that when I underline, it goes beneath the text. I assume (from looking at other PDFs created from other sources) that I need to somehow widen the box around the text. I know enough about the PDF spec to know that there are countless possible paths to do this.

So I am asking here.

CURRENT

DESIRED

[jbarlow83]

You're referring to the positioning of the text baseline and the underline. In a normal font, the font itself specifies where to put the underline.

Tesseract calculates the baseline of the recognized text, and in ocrmypdf v17+, then places the recognized 'Noto' font underneath. For various reasons the alignment of Noto to the recognized text isn't perfect, and getting underline right means the underline position in Noto has to be a position that is naturally for the bitmap image.

Of course, I can't tell if you used ocrmypdf v17+, and I can't tell if you have Noto installed (although most modern systems do). If you don't have Noto, we fall back to the Occulta font, which would be even more wrong, because it doesn't have real glyph metrics, just broad categories.

If you really need to get it right on a specific PDF, a tool like Foxit can select the recognized invisible text objects, and you could shift them down or up slightly, then that should reposition the underline.

[xave]

What I would like to do is write a script with my desired setup and run that on any PDF moving forward.

[jbarlow83]

If it worked on 16.x, it was a coincidence. 16.x has a number of text alignment issues that 17.x corrects.

I don't think it will ever be in Tesseract's scope to assign a font family to recognized text or infer font metrics. That's a layout recognition problem that is out of scope for it, and I think out of scope for most commercial OCR. Commerical OCR is probably your best option if getting this right matter - there are too many missing pieces in the open source stack to make it happen.

[xave]

16.x wasnt an accident. It did everything I wanted.

Anyway, I figured it out. Had to go into the PDF Spec itself, which, as I said in the opening is complicated.

Background
The uncompressed PDF has text blocks like this where Horizontal_X and Horizontal_Y are the bounding box locations for a line of text.

BT
  3 Tr 1 0 0 1 [Horizontal_X] [Vertical_Y] Tm
  ...
ET

We can reduce the Vertical_Y by 3.0 points. The diff looks something like this:

BT
  3 Tr 
- 1 0 0 1 286.08 973.96 Tm
+ 1 0 0 1 286.08 970.96 Tm
                 ^^^^^^
  [ <00540048...> ] TJ
ET

This causes the underline to drop below the text like I want. I did all of this in raw tesseract, but since your library is built on top of tesseract, you can expose this kind of thing in ocrmypdf.

Specifically, I used tesseract to OCR a page. qpdf to uncompress that output PDF, then a text editor vim to manually modify the document and view changes with a PDF Reader.

As one would presume, manually editing all of these blocks is error prone and brittle, so my next step is to programmatically interact with the PDF structure to automate this. But now we know exactly where, why, and how this mechanism manifests in the PDF file.

[jbarlow83]

That would likely misalign the selected text box compared to its image, and also may not work correctly for sloped text... and won't work if the font size is substantially different.

You certainly could modify the fpdf2 renderer code to introduce a vertical offset to all rendered text. It's open source, whatever floats your boat and solves your problem. But it's a hack, and so was the 16.x stuff. The point stands: Tesseract does not provide enough detailed font information to render an underline where it's supposed to go (and that is font-specific), so we have no way of doing placing it correctly.

[xave]

The PDF Annotation use case is straight forward and rarely involves sloped text. Font sizes tend to be stable on a given line as well. All you need is to offset it by anything at all. Open 10 random modern books and 10 random academic papers. The solution would work for all. I already did the work and provided evidence.