You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This gives the two opposite corners of the glyph, but these do not define the bounding box when the text matrix (or the CTM) contains rotation, in which case it's necessary to use all four corners. To illustrate, take this PDF (please) and visualize what pdfminer.six gives (yes, the code is very long! it's at the bottom...):
It should probably look like this:
This is also true for images (and maybe other things). You can fairly easily detect whether the bounding box needs to be calculated with all four corners because either b or c in the transformation matrix are negative (this means that when Y increases, X decreases, or vice versa, and thus the upper left / bottom right corners will be further left / further down), for example: https://github.com/dhdaines/playa/blob/main/playa/utils.py#L272
pdfminer.six
reports the boundaries of glyphs inLTChar
like this:This gives the two opposite corners of the glyph, but these do not define the bounding box when the text matrix (or the CTM) contains rotation, in which case it's necessary to use all four corners. To illustrate, take this PDF (please) and visualize what
pdfminer.six
gives (yes, the code is very long! it's at the bottom...):It should probably look like this:
This is also true for images (and maybe other things). You can fairly easily detect whether the bounding box needs to be calculated with all four corners because either
b
orc
in the transformation matrix are negative (this means that when Y increases, X decreases, or vice versa, and thus the upper left / bottom right corners will be further left / further down), for example: https://github.com/dhdaines/playa/blob/main/playa/utils.py#L272Code to generate samples above:
The text was updated successfully, but these errors were encountered: