crop: problems under Win

[kpym]

I just checked the new crop command and observed the following:

• Using the negative value, like pdfcpu crop '-10' in.pdf out.pdf do not works for me in GitBash under Windows, but it works under PowerShell. The error message is : flag provided but not defined: -10. The result is the same with double quotes.
• Croping a pdf that has a crop box different from the media box do not work as I expected. The new crop being relative to the media box, it is not relative to what we see on the screen. I think that the crop command should be relative to the what we see on the screen, i.e. to the crop box (which in many cases defaults to the media box). In the current version if we run first crop '20' and then crop '10' the second command enlarge the (visible) page. Another option is that the crop command sets both media box and crop box even in the "reduction" case (which is already the case for the enlargements).

[hhrutter]

OK I have to and will check your Windows issue.

The crop command is designed to define a crop Box for the media Box in effect for a given page.
This maybe achieved by absolute or relative positioning.
When using relative positioning passed percentages relate to the parent Box which for the crop Box is the media Box as defined in the PDF spec.

This is the - rather mechanical - way this pdfcpu operation is setup right now - no magic implied and the user has to know what s/he/they is/are doing.

Your usecase seems to be valid in terms of a desktop app where you repeatedly play around cropping a page but on the cli?
I don't know, I will think about it 🤔

[kpym]

The problem is not if I apply multiple times the crop, because in this case I know what I do. The problem is if I try to crop a pdf that do not have crop box = media box (which is not "visible") for example if somebody else has cropped the pdf before me.

Is there some reason to keep the media box different from the crop box in the high level command crop ?

[hhrutter]

The new box and crop commands assume the user knows about the media Box involved which you can always inspect via pdfcpu box list or pdfcpu info -pages 1-

Does the following describe your use?

Somebody gives you a PDF then you open it in Adobe Reader and decide you want to crop the content by a margin of 1cm without even thinking about what the media Box looks like?

[kpym]

The new box and crop commands assume the user knows about the media Box involved which you can always inspect via pdfcpu box list or pdfcpu info -pages 1-

In my point of view box is for pdf experts that know that there are different boxes. The crop users are people that only want to enlarge or reduce the visible content without knowing anything about the different boxes behind the scene.

If you know how to use box you do not need crop.

Does the following describe your use?
Somebody gives you a PDF then you open it in Adobe Reader and decide you want to crop the content by a margin of 1cm without even thinking about what the media Box looks like?

Yes, this is what I'm talking about. There are many reasons to modify a pdf outline without being pdf expert: pick up a logo, modify from letter to A4, ...

[hhrutter]

Under Windows you have to use double quotes for string parameters.
Aside from this the trick is to use -- to signal the termination of the flag section of a command.
I modified the usage sections to reflect this.

This is how you should execute the command mentioned above on the Win cmdline:
pdfcpu crop -- "-10" in.pdf out.pdf

[kpym]

I dont think that simple vs double quote is a Windows problem. Under Windows we can use cmd, PowerShell, GitBash, wt (the new Windows terminal)... So it depends. I think that this is more Bash problem vs Windows problem.

By the way, probably the usage message could be (with [common flags] and [--] added):

pdfcpu crop [common flags] [-p(ages) selectedPages] [--] description inFile [outFile]

By closing this issue, does this means that for you keeping mediabox untouched for positive values and modifying it for negative ones is the normal behavior ? Do you have an argument to adjust only the cropbox when shrinking (apart from the fact that we can leave it like this) ?

Thanks one more time for your work and considering my questions.

[hhrutter]

I am not an expert on the standard DOS-style Windows command line.
I just noticed that double quotes work whereas single quotes don't.

As far as -- is concerned you really only need it when you have a command line arg that potentially starts with a single dash (-).

In the case of:

pdfcpu crop [-p(ages) selectedPages] -- description inFile [outFile]

the description is a required argument that's why it is safe to also mandate the --.
If -- was optionally I may crash and then wonder why - right?

BTW I just had to push another commit because of a redundant usage: in the crop usage string.

The closing of this issue was triggered by the git commit comment but I'd like to keep it closed anyway.
Please do me a favour and open a separate issue for the remaining issue you have with the crop command.
I am still unclear and need to decide how and if a crop behaving differently fits in the big picture.

Thank you!