Add new pdf-rotate action

[goebbe]

This pull request adds a new action "pdf rotate".

If at least one pdf-file is selected, it allows rotating the pdf clockwise by 90 degrees, i.e. it changes the orientation.
Use case:

• This can be useful e.g. when printing slides into PDF(s) - since landscape mode (for slides) is not always supported by cups-filter.
• The rotation of the PDFs will affect how a pdf-thumbnails are orientated and how PDFs are displayed, e.g. in Evince.

This is my first git pull request - so please point out any shortcomings.
I hope the pull request is fine.

[goebbe]

Is there anything missing on this pull request, from my side?

[rcalixte]

Is there anything missing on this pull request, from my side?

There seems to be a few excess files included.

Other than that, I was hoping for some feedback from the community. On my end, I wondered about the differences between QPDF and something like PDFtk. You could possibly get away without needing a shell script too. There's a lot to think about here.

[goebbe]

@rcalixte Thanks for the fast reaction!

For qpdf: pdftk and qpdf both seem to be commonly used (and recommended) tools for rotating PDF(s).
Difference:
pdftk is a java package and draws in more java-dependecies
qpdf has a more selfexplanatory syntax (my opinion)

Also qpdf can replace the existing file, using the --replace-input option, while with pdftk I have to handle a temporaty outputfile.

Here is a direct comparison:
qpdf "$file" --replace-input --rotate=+90
vs.
pdftk "$file" cat 1-endright output temp.pdf && mv temp.pdf "$file"
Possibly the last command could be simplified, it's the first time I used pdftk. But "cat 1-endright output"?? seriously. ;-)

Honestly, both get the job done fast and nicely, so I wouldn't mind switching to pdftk.

Please let me know if I should provide a version without a seperat script. I just replicated the structure of existing actions for a start - but I see your point. :-)

[goebbe]

If the other pdf-related actions already use pdftk - then this would be a good argument in favour of pdftk.
I just checked the available spice actions that manipulate PDF(s): I found one other action that uses pdftk.

PDFtk seems to be like "a classic", there is a commercial/pro version, the author seems to be an authority concerning the manipulation of PDFs. Mainly written in Java. Licence is GPL2 - I could not find a public repo/ issue tracker.
https://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/

QPDF is an actively maintained/ developed project with a public repo on github. They release regularly, there seems to be an active community. The project is written mainly in C++. Licence is Apache. Good documentation.
https://github.com/qpdf/qpdf?tab=readme-ov-file

With respect to functionality, there is a huge overlap. Both tools provide command line tools to manipulate PDFs and can merge, split, rotate, encrypt ...

Personally, I would go for qpdf for the public repo/ issue tracker alone, and I like the syntax better - but in the end I have no strong opinion.

@ScarletEmanu What do you think about qpdf vs. pdftk?

[goebbe]

You could possibly get away without needing a shell script too.
I thought about that, but I do not want to lose the ability to rotate more than one PDF (i.e. rotate a selection of files).
If I am not mistaken, I have to loop over the files - and I would rather not inline the following:

echo "$@" | while read -r file
  do
    qpdf "$file" --replace-input --rotate=+90    
done

Do you have a pointer/ examples? Looking thought the repo I did not find any.

[rcalixte]

Do you have a pointer/ examples? Looking thought the repo I did not find any.

It's not a hard requirement so don't feel stressed or pressured to implement it that way. I was thinking it would work like the send-to-printer action that can take a single or multiple files as a parameter but if it is processing them differently, maybe that won't be the case.

If the other pdf-related actions already use pdftk - then this would be a good argument in favour of pdftk.

I don't have a preference for either though you make a compelling case for QPDF over PDFtk.

[goebbe]

Thanks for merging!

[rcalixte]

Thanks for merging!

Thanks for your contributions and patience!

[goebbe]

It's not a hard requirement so don't feel stressed or pressured to implement it that way. I was thinking it would work like the send-to-printer action that can take a single or multiple files as a parameter but if it is processing them differently, maybe that won't be the case.

qpdf does not seem to be able to handle a list of files directly - so there seems to be no way around looping. :-(

I experimented with inlining the loop on the Exec line - but I did not get this to work with more than one file selected.
This may be due to my limited knowledge about Exec and passing/ treating the list of files in this context.