The bboxes are not in the regular PDF coordinate system (top left = 0, 0), so I change those to get a more typical x0, y0, x1, y0 coordinate system.

There are some mistakes in the above phrase:

• The regular PDF coordinate system, if we can use that term, has its origin at the bottom left corner. Top left is commonly the origin of bitmaps. "regular" is difficult since the PDF coordinate system may theoretically be laid out between any opposite corners, but most PDFs comply with the convention.
• Bounding boxes are given as 4 coordinates as stored in the document, with values relative to the PDF coordinate system. In PDF, rotation modifies the coordinate system, so raw PDF coordinates always refer to the non-rotated page.
• Supposedly you mean x0 y0 x1 y1, not x0 y0 x1 y0.

If you only work with pypdfium2 functions, you needn't worry about coordinate conversion at all and can just use pdf coordinates as-is, i. e. you simply pass the result of get_rect() to get_text_bounded() unchanged and it will be correct.

If you want to draw to a bitmap, then yes, you will need to translate from PDF to bitmap coordinates. Either manually or via FPDF_PageToDevice(). However, this is currently your task as caller. This is mainly a bindings infrastructure project. For PDF background, refer to the specification. Note that there have been various similar reports in the past.

And an important note on FPDF_PageToDevice(): the rotation parameter is only for additional rotation on rendering, not page rotation, i.e. you should pass 0 here.

@mara004 First of all, I did search around for open and closed issues, my bad if I missed something. Also my bad for having a typo in the post.

bbox coordinates are required to sort the text into reading order - it is not uncommon that extracted text is returned out of reading sequence. Another typical example is skewed documents where simple logic like sort first by y-axis and then by x-axis is useless. bboxes need to be adjusted based on information of the document layout, before they can be sorted.

Only by having correct bbox-coordinates one can then sort the bboxes and words in them to get a coherent raw text output, even if the bboxes do capture the words perfectly. Additionally if one wishes to use the bboxes and words as ground truth for ML applications, the bboxes have to be converted into a more typical coordinate system where x0/y0 is the upper left corner of an image. COCO format is an example of this.

So if the document is rotated, it is much easier to rotate the bboxes first and then pass the output through code that takes care of sorting.

As far as I know, pypdfium2 currently ranks 2nd in terms of accuracy and speed of text extraction after PyMuPDF. Unlike PyMuPDF which is AGPL licensed, pypdfium2 is actually free & open source and a better choice imo if the scope of the project can change over time. Just a point of view as to the benefits of this library compared to other alternatives in the OSS space.

Here's an example: Red boxes are drawn by using bbox values as is, blue is after rotation.

First of all, I did search around for open and closed issues

Related issues are #228 and #214.

Thanks for elaborating on the use case. Don't misunderstand me, I agree that coordinate normalization is vital for some use cases. However, I don't currently have time/interest to dive into this topic, and there are higher priority tasks ATM (mainly consolidating tests and existing helpers).

FPDF_PageToDevice() can already translate coordinates, but the issue we had in #228 is that it only provides int output, resulting in a loss of precision, which is a problem if you do not target a fixed-size bitmap.
I think the best solution would be if pdfium could provide a new set of functions to normalize coordinates bitmap-independently with floating-point output, maybe even with configurable origin (bottom left or top left).