getPixmap should take a clip parameter. about pymupdf HOT 8 CLOSED

I understand where you are aiming at. Some clarification is necessary though:

I think the following is clear - but please confirm:

• a specified clip means a rectangle which will be transformed together with the rest of the page
• the clip should be intersected with page.bound() before being processed

To decide:

• Either: the pixmap has the size of (transformed) clip and only contains clip content
• Or: the pixmap has the original (transformed) page size, but is empty (white) except for the clip area

from pymupdf.

The clip rect passed in should be pre-transformed as you described.

as for if the clip should be intersected with page.bound(), I guess that depends on the choice of the 2nd part of the question. Should the pixmap has the size of the clip area or the size of the page.

I assume the clip passed in is always a subset of the page.bound.

Actually, I wonder how does fz_new_draw_device_with_bbox of mupdf treat pixmap with the clip parameter. Does it require that the pixmap of the page bound size?

If the pixmap has to be the page size, then the saving is mostly on mupdf render/run part. The saving on pixmap size will not be possible.

I'd prefer the 1st option if possible, i.e. the pixmap reture is of the size of the clipping rectangle. That will save some memory at the end.

And since the pixmap returned is not created by the user, the user will always have to crop to the clipped rect before make use of the pixmap.

from pymupdf.

Thank your for for rapid answer.
I already have a working version.

What I am doing right now is what you also prefer:

1. intersect clip with page.bound() - just to correct any nonsense input
2. take the fitz.Rect-version of clip as basis r for what follows
3. transform r and clip with the matrix
4. create pixmap with transformed clip as IRect
5. render the page

Below is the result of clip = fitz.IRect(0, 0, width, height/2) and transforming it with fitz.Matrix(2, 2).preRotate(90). Please send me a note if you are fine with this.
Because of transformation, the IRect of the resulting pixmap in this case (correctly) is fitz.IRect(-842, 0, 0, 1191). One may or may not like it this way.
My question is, whether we should translate the IRect coordinates such that no negative values occur? Has no effect on produced image.

from pymupdf.

A normal IRect for pixmap origined at (0,0) is least surprise for the users.

And can you confirm that the 2nd half of the page can be clipped properly? clip = fitz.IRect(0, height/2, width, height/2).

from pymupdf.

Yes, that works, too ... of course with clip = fitz.IRect(0, height/2, width, height) - otherwise the rectangle area would be zero.
Here is the complete code I used - fairly raw of course, needs to be packaged into getPixmap, etc.

import fitz
doc = fitz.open("pymupdf.pdf")
m = fitz.Matrix(2,2).preRotate(90)
p = doc.loadPage(22)
r = p.bound()
ir = r.round()
clip = fitz.IRect(0, 842/2, 596, 842)
r.intersect(clip.getRect())
r.transform(m)
clip = r.round()
dl = fitz.DisplayList()
p.run(fitz.Device(dl), fitz.Identity)
pix = fitz.Pixmap(fitz.csRGB, clip)
pix.clearWith(255)
dv = fitz.Device(pix, clip)
dl.run(dv, m, r)
pix.writePNG("lower.png")
pix.x = 0  # just to prevent programmer's suprise
pix.y = 0  # ...

from pymupdf.

Great work!

from pymupdf.

just uploaded the updates responding to this issue. Documentation has also been updated accordingly. PyPI hosted docu will follow in a minute.

from pymupdf.

@mozbugbox - thank you very much for input, attentive reading the documentation and the many ideas for improvements!

from pymupdf.