booklet/nup: handle existing page rotation

[adamgreenhall]

When reading a pdf that has been rotated (either using pdfcpu or some other tool), PageDims (media box?) within pdfcpu doesn't seem to know about the rotation.

Example:

pdfcpu info test.pdf | grep "Page size"
           Page size: 612.00 x 396.00 points
pdfcpu rotate test.pdf 90 test-rotated.pdf
pdfcpu info test-rotated.pdf | grep "Page size"
           Page size: 612.00 x 396.00 points              <---- expecting 396.00 x 612.00 points

[hhrutter]

It is not that simple unfortunately.

pdfcpu info test.pdf returns a list of used page dimensions in the file.
If you have a file with 10 pages and the cover page has different dimensions than the rest you get
dumped out 2 page dimensions. Since this info is consolidated it cannot account for the page rotation which
applies to each and every page individually and even more the rotation is an inherited page attribute.

pdfcpu info -pages 1- test.pdf also returns the page boundaries for all pages which includes the dimensions,
but not the rotation in effect.

What's your specific use case?
There's room for improvement without doubt.

[adamgreenhall]

My use case is that I have a pdf that I'm trying to run through pdfcpu booklet, but it's rotated 90deg. As you might imagine, this causes problems. Trying to fix it by pdfcpu rotate or rotate in macos preview doesn't work.

Makes sense about the different pages having different dimensions/rotation.

[hhrutter]

I see. I need to go back and double check but I thought booklet was taking care of page rotation.
Any chance you can get me a sample?

[adamgreenhall]

So, I've been working on adding a few more booklet layouts for different orientations and bindings and which booklet layout you use depends on the page orientation (portrait or landscape) and the binding (long- or short-edge) you want. Like this:

So being able to correctly detect the real page orientation from the rotation would be really handy.

I'll send you an example pdf on slack.

[hhrutter]

OK, so any existing rotation value != 0 for input file pages needs to be taken into account during the rendering phase on the new page like it is done for stamping.

Unfortunately I was wrong. 😞 I thought that's already in there in: nup.go
Once it works for nup it will also work for booklets, since that command is just a variation of nup.

The general idea is to internalize the page rotation and carry it over into the content stream via a transform matrix.
See pdfcpu/stamp.go and the handling of wm.pageRot.

Since this is quite tricky it will not be part of the upcoming release that I am about to push.
Again 😞

[hhrutter]

This has been addressed with the latest commit.