(PDF) inconsistent page.cropbox reference point, when mediabox is shifted

[openandclose]

(1)
From The Glossary page,
I expect that when given /MediaBox [ 36 45 607.5 765 ],

>>> page.cropbox
Rect(36.0, 0.0, 607.5, 720.0)

but actually:

Rect(36.0, 45.0, 607.5, 765.0)

If also explicitly given /CropBox [ 36 45 607.5 765 ],
cropbox is as documented.

(2)
So currently there are three rect coordinates used in PyMuPDF.

coord A: as in PDF data

with  y axis inverted,
coord B: top-left aligned, x0 = y0 = 0, as in page.rect
coord C: only top aligned, it seems used only in page.cropbox.

Which coordinates should be used in set_cropbox?

Currently putting coord A returns documented result,
but it is hard to make sense of it.

(3)
Also update the doc for set_mediabox.
(Now RuntimeError: mediabox must start at (0,0),
since (perhaps) b469ab9, 'upload v1.18.7', fitz.i).

To Reproduce (mandatory)

test PDF and test python files are attached.

sample-shifted_medeabox.pdf (only MediaBox defined)
sample-shifted_medeabox2.pdf (MediaBox and CropBox defined)
check_box.py.txt

Your configuration (mandatory)

Linux 5.15.2
Python 3.9.7
PyMuPDF 1.19.3

[JorjMcKie]

Thanks for the report.
There indeed exists an inconsistency. If the page definition has no explicit /CropBox definition, then either the an empty or infinite rectangle should be returned, or, as is intended, the /MediaBox value.

It must be noted however, that all rectangles except the mediabox, must be specified with y-values counting from top to bottom. So in this case, Rect(36.0, 0.0, 607.5, 720.0) is the correct value and should have been returned in both cases.

The page rectangle in contrast always has a top-left point (0, 0) and (if unrotated) the same width and height as the cropbox.
Therefore take this rectangle out of the discussion.

I will correct this in the next version.

[JorjMcKie]

I cannot recall what motivated me to prohibit mediabox origins other than (0, 0).
This is an expert function anyway, so one must hope that this guy knows what is going on ...
I think I will take out that restriction again.
What I will keep however is putting mediabox = cropbox on changes to mediabox.
I also saw that no validation takes place on changes to the cropbox. I need to make sure that this rectangle stays inside the mediabox.

[openandclose]

Thank you for the fast reply (as always).

It's already quite hard for me to just think about non (0, 0) top-left mediabox,
so I understand the difficulty to get .cropbox and .set_cropbox right in this case,
while also following upstream MuPDF idiosyncrasies.

For .set_mediabox, things get even more difficult,
and personally it may be easier to use (if I use) if there are some restrictions
(like 'cannot move top-left' or 'getting cropbox right is user's job'),
especially since MuPDF and PyMuPDF don't have APIs for BleedBox and ArtBox.

Anyway just an opnion from an PDF amateur,
I'm fine with what you'll do and if it takes time.

[openandclose]

This is unrelated, very confusing to bring it in,
(so readers don't need to reply),
but just for reference, to think in broader perspective.

There is a controversy over cropbox intepretation at this basic level
(between ghostscript and MuPDF).
https://bugs.ghostscript.com/show_bug.cgi?id=702183

[JorjMcKie]

I'm fine with what you'll do and if it takes time.

Already did the change and tested it.

As a side note: changing those diverse XXX-boxes is for people with advanced PDF skills. There is good reason, why MuPDF always simplifies a page rectangle thus that top-left is (0, 0).
A more complete list of reasons would include that MuPDF is for a dozen of document types other than PDF. Not all of them have coordinate systems starting from the bottom-left point like PDF ...

As per the other boxes (ArtBox, etc.) there always is the option to use the lower level interface doc.xref_get_key() / doc.xref_set_key(). It would also be no big deal to support properties and methods like page.artbox / page.set_artbox() ... but who would be interested?
There are more important things that would enrich PyMuPDF's features, e.g. introducing an Image class for supporting more than just those Pixmap objects. Or digital signing.

[openandclose]

Just for BleedBox and ArtBox.

If .set_mediabox also explicitly moves CropBox somehow, like:

pdf_dict_put_rect(gctx, page->obj, PDF_NAME(MediaBox), mediabox);
pdf_dict_put_rect(gctx, page->obj, PDF_NAME(CropBox), mediabox);

I thought it was hard to get away with ignoring BleedBox and ArtBox.

But again, I don't have strong opinion.

---

(aside)

but who would be interested?

While the library end-users can do as they like,
intermediate application developers must consider BleedBox and ArtBox.

And currently it is non-trivial to process these boxes using .xref_get_key etc.,
with page attributes inheritance and indirect object.

[JorjMcKie]

While the library end-users can do as they like, intermediate application developers must consider BleedBox and ArtBox.

Hm, I read this like you would advocate for providing this feature ...?

The logic would be similar to the relation between cropbox and mediabox, only this time, cropbox is the default.

[JorjMcKie]

If .set_mediabox also explicitly moves CropBox somehow, ...

Yes, it really is not difficult. Also setting the /Cropbox to any new MediaBox value makes things a lot easier, AOT no hassle with error returns etc.
I may choose to delete the /CropBox item instead - saves a few bytes in file size and does the same job.

[openandclose]

Hm, I read this like you would advocate for providing this feature ...?

Yes, but please treat it as it is (one meek nudge in an off-topic thread).

Yes, it really is not difficult.

I think I understand a bit.
I've been worrying only seeing it from surface spec descriptions,
but from the implementation perspective, if it makes things simpler,
I understand that's the way to go.

[JorjMcKie]

controversy over cropbox intepretation at this basic level
(between ghostscript and MuPDF).

I have read it. Like every spec, the PDF is not 100% correct / free of inconsistencies, in addition to several overly / unnecessary complex regulations (like incremental file loading or storing tables or Marked Content).
There are also things actually contradictory like the sequence of specifying the corners of a quad (the spec: says "counterclockwise", but in reality it is in a zigzag sequence). Etc.

Second, for me the critical wording is that "outside this boundary [i.e. the MediaBox] can safely be discarded without affecting the meaning of the PDF file." Given this and the definition of the CropBox, the CropBox cannot be thought of as extending beyond the boundaries of mediabox. In addition, the MediaBox is the default CropBox.

This for me is justification enough to impose the requirement "cropbox in mediabox" must be true.
The rest of this discussions seems to be more academic than anything else (difference between cropping and clipping and what not).

[JorjMcKie]

Fixed in v1.19.4 currently being uploaded.