I just had a special case img2pdf seems to be unable to cope with (without help of other tools).
I today took 9 pictures of an article in a printed journal, keeping the journal flat on a table and using my mobile phone with the document function.
Problem: When holding the mobile phone in a horizontal way, it can't decide whether this is a portrait or landscape image. Therefore, the phone made 7 of 9 pictures in portrait, and 2 in landscape mode.
Now I wanted to convert these 9 jpegs into a PDF of the article, but did not find parameters for img2pdf, which produce a correct PDF:
with --auto-orient, the two pages are rotated in to landscape
with -r 0 , -r auto , -r none all PDF pages are in portrait orientation, but the image itself is still rotated for these two images.
An option is missing to have each image individually rotated to fit the page best.
regards
Hi,
I just had a special case img2pdf seems to be unable to cope with (without help of other tools).
I today took 9 pictures of an article in a printed journal, keeping the journal flat on a table and using my mobile phone with the document function.
Problem: When holding the mobile phone in a horizontal way, it can't decide whether this is a portrait or landscape image. Therefore, the phone made 7 of 9 pictures in portrait, and 2 in landscape mode.
Now I wanted to convert these 9 jpegs into a PDF of the article, but did not find parameters for img2pdf, which produce a correct PDF:
* with --auto-orient, the two pages are rotated in to landscape
* with -r 0 , -r auto , -r none all PDF pages are in portrait orientation, but the image itself is still rotated for these two images.
An option is missing to have each image individually rotated to fit the page best.
regards
You are correct in concluding that img2pdf currently is unable to apply rotation on a per-image basis.
But I'm also very hesitant about adding such a feature. The same argument that you made could not only be made for the image rotation but also for all the other settings which currently affect all the images at once. So should img2pdf add a way to also specify the following on a per-image basis?
colorspace
engine
first-frame-only
pagesize
imagesize
border
fitting
crop border
bleed border
trim border
art border
What makes rotation special compared to the other options above?
Even if we say we want this, what would the syntax be? Would you expect to be able to write something like:
--rotation 0,0,0,0,0,0,0,90,90
Or use an even more complicated but shorter syntax:
--rotation 1-7:0,8-9:90
Is that added complexity worth the cost of making the code harder to maintain and the --help output and the man page harder to read?
I'm a big fan of the unix philosophy: let each tool do one thing and let it do this one thing well instead of designing the single tool that can do everything. What stops you from creating two pdfs: one with images 1 to 7 and one pdf with images 8 and 9 rotated and then you concatenate both pdfs using pdftk or similar utilities?
You are correct in concluding that img2pdf currently is unable to apply rotation on a per-image basis.
But I'm also very hesitant about adding such a feature. The same argument that you made could not only be made for the image rotation but also for all the other settings which currently affect all the images at once. So should img2pdf add a way to also specify the following on a per-image basis?
- colorspace
- engine
- first-frame-only
- pagesize
- imagesize
- border
- fitting
- crop border
- bleed border
- trim border
- art border
What makes rotation special compared to the other options above?
Even if we say we want this, what would the syntax be? Would you expect to be able to write something like:
--rotation 0,0,0,0,0,0,0,90,90
Or use an even more complicated but shorter syntax:
--rotation 1-7:0,8-9:90
Is that added complexity worth the cost of making the code harder to maintain and the --help output and the man page harder to read?
I'm a big fan of the unix philosophy: let each tool do one thing and let it do this one thing well instead of designing the single tool that can do everything. What stops you from creating two pdfs: one with images 1 to 7 and one pdf with images 8 and 9 rotated and then you concatenate both pdfs using pdftk or similar utilities?
I wouldn't want something like --rotation 0,0,0,0,0,0,0,90,90
This means I had to pass the rotations manually.
I would like to have something like
--rotation fit
or
--rotation upright
telling img2pdf just turn every image into the orientation of the print format (PDF). If I order a portrait PDF, then turn all images which are wider than high.
Have a look at imagemagick. They do support a syntax like -r -90< , telling it to apply this only on images which are wider than high, thus effektively rotating selectively.
Maybe it's allready enough to just allow the same syntax and passs it through?
What stops you from creating two pdfs: one with images 1 to 7 and one pdf with images 8 and 9 rotated and then you concatenate both pdfs using pdftk or similar utilities?
Nothing, that's what I currently do – without img2pdf, because using imagemagick convert directly can automatically detect and selectively rotate. I then don't have the work to manually watch files and treat them manually.
But then, why should one use img2pdf at all, if it is easier and faster to apply imagemagick to all images separately and concatening the PDFs afterwards without the need to do filthy handwork to give parameters for every single page?
And yes, the unix philosophy is to do one thing right. The point is, that img2pdf is not doing it right. The result is simply wrong.
Another unix philosophy is to have exactly one tool for a given task. And if that task is easier and better with imagemagick + pdfunite, the unix philosophy is to drop img2pdf.
And if you're not willing to make things right, because it'd make the code harder to maintain just because of making it right, the code is questionabel anyways.
I wouldn't want something like --rotation 0,0,0,0,0,0,0,90,90
This means I had to pass the rotations manually.
I would like to have something like
--rotation fit
or
--rotation upright
telling img2pdf just turn every image into the orientation of the print format (PDF). If I order a portrait PDF, then turn all images which are wider than high.
Have a look at imagemagick. They do support a syntax like -r -90< , telling it to apply this only on images which are wider than high, thus effektively rotating selectively.
Maybe it's allready enough to just allow the same syntax and passs it through?
> What stops you from creating two pdfs: one with images 1 to 7 and one pdf with images 8 and 9 rotated and then you concatenate both pdfs using pdftk or similar utilities?
Nothing, that's what I currently do – without img2pdf, because using imagemagick convert directly can automatically detect and selectively rotate. I then don't have the work to manually watch files and treat them manually.
But then, why should one use img2pdf at all, if it is easier and faster to apply imagemagick to all images separately and concatening the PDFs afterwards without the need to do filthy handwork to give parameters for every single page?
And yes, the unix philosophy is to do one thing right. The point is, that img2pdf is not doing it right. The result is simply wrong.
Another unix philosophy is to have exactly one tool for a given task. And if that task is easier and better with imagemagick + pdfunite, the unix philosophy is to drop img2pdf.
And if you're not willing to make things right, because it'd make the code harder to maintain just because of making it right, the code is questionabel anyways.
Wow, your last comment became quite insulting towards the end. I'm grateful that you are reaching out to report something that you perceive as a problem. But you do understand that dissing my software will only make it less likely for me to spend my free time on something that you would like to have? I'm providing something here for free and you are also free not to use it if you don't like it. I'm not loosing anything if nobody uses my code, you realize that, right? Please try to use a better tone.
Have a look at imagemagick. They do support a syntax like -r -90< , telling it to apply this only on images which are wider than high, thus effektively rotating selectively.
Maybe it's allready enough to just allow the same syntax and passs it through?
You already discovered the --auto-orient option but I do not yet understand why what it does is not what you want. Lets create some example input:
The resulting PDF will have the first page in landscape and the second in portrait, automatically rotating it to accomodate for the different orientation of the input image. If you then go and print that, does the result look like you want it?
without img2pdf, because using imagemagick convert directly can automatically detect and selectively rotate. I then don't have the work to manually watch files and treat them manually.
If imagemagick is doing what you want I recommend you use it instead of img2pdf. No hard feelings.
But then, why should one use img2pdf at all
img2pdf has one thing that sets it apart from all the other tools (see the end of the README for a list): it is lossless. If you don't need it, then imagemagick might be a better tool for you.
The point is, that img2pdf is not doing it right. The result is simply wrong.
I do not see yet how it is wrong. I see that you are convinced that it is.
And if that task is easier and better with imagemagick + pdfunite, the unix philosophy is to drop img2pdf.
I wish I could. That would mean less work for me. If you know a tool which is able to convert nearly arbitrary raster images to PDF without loosing information, I'm all ears.
And if you're not willing to make things right, because it'd make the code harder to maintain just because of making it right, the code is questionabel anyways.
Do you want to submit a patch?
Wow, your last comment became quite insulting towards the end. I'm grateful that you are reaching out to report something that you perceive as a problem. But you do understand that dissing my software will only make it less likely for me to spend my free time on something that you would like to have? I'm providing something here for free and you are also free not to use it if you don't like it. I'm not loosing anything if nobody uses my code, you realize that, right? Please try to use a better tone.
> Have a look at imagemagick. They do support a syntax like -r -90< , telling it to apply this only on images which are wider than high, thus effektively rotating selectively.
> Maybe it's allready enough to just allow the same syntax and passs it through?
You already discovered the `--auto-orient` option but I do not yet understand why what it does is not what you want. Lets create some example input:
```
convert logo: landscape.png
convert logo: -rotate 90 portrait.png
img2pdf -S A4 -o out.pdf --auto-orient landscape.png portrait.png
```
The resulting PDF will have the first page in landscape and the second in portrait, automatically rotating it to accomodate for the different orientation of the input image. If you then go and print that, does the result look like you want it?
> without img2pdf, because using imagemagick convert directly can automatically detect and selectively rotate. I then don't have the work to manually watch files and treat them manually.
If imagemagick is doing what you want I recommend you use it instead of img2pdf. No hard feelings.
> But then, why should one use img2pdf at all
img2pdf has one thing that sets it apart from all the other tools (see the end of the README for a list): it is lossless. If you don't need it, then imagemagick might be a better tool for you.
> The point is, that img2pdf is not doing it right. The result is simply wrong.
I do not see yet how it is wrong. I see that you are convinced that it is.
> And if that task is easier and better with imagemagick + pdfunite, the unix philosophy is to drop img2pdf.
I wish I could. That would mean less work for me. If you know a tool which is able to convert nearly arbitrary raster images to PDF without loosing information, I'm all ears.
> And if you're not willing to make things right, because it'd make the code harder to maintain just because of making it right, the code is questionabel anyways.
Do you want to submit a patch?
Hi,
I just had a special case img2pdf seems to be unable to cope with (without help of other tools).
I today took 9 pictures of an article in a printed journal, keeping the journal flat on a table and using my mobile phone with the document function.
Problem: When holding the mobile phone in a horizontal way, it can't decide whether this is a portrait or landscape image. Therefore, the phone made 7 of 9 pictures in portrait, and 2 in landscape mode.
Now I wanted to convert these 9 jpegs into a PDF of the article, but did not find parameters for img2pdf, which produce a correct PDF:
An option is missing to have each image individually rotated to fit the page best.
regards
You are correct in concluding that img2pdf currently is unable to apply rotation on a per-image basis.
But I'm also very hesitant about adding such a feature. The same argument that you made could not only be made for the image rotation but also for all the other settings which currently affect all the images at once. So should img2pdf add a way to also specify the following on a per-image basis?
What makes rotation special compared to the other options above?
Even if we say we want this, what would the syntax be? Would you expect to be able to write something like:
Or use an even more complicated but shorter syntax:
Is that added complexity worth the cost of making the code harder to maintain and the --help output and the man page harder to read?
I'm a big fan of the unix philosophy: let each tool do one thing and let it do this one thing well instead of designing the single tool that can do everything. What stops you from creating two pdfs: one with images 1 to 7 and one pdf with images 8 and 9 rotated and then you concatenate both pdfs using pdftk or similar utilities?
I wouldn't want something like --rotation 0,0,0,0,0,0,0,90,90
This means I had to pass the rotations manually.
I would like to have something like
--rotation fit
or
--rotation upright
telling img2pdf just turn every image into the orientation of the print format (PDF). If I order a portrait PDF, then turn all images which are wider than high.
Have a look at imagemagick. They do support a syntax like -r -90< , telling it to apply this only on images which are wider than high, thus effektively rotating selectively.
Maybe it's allready enough to just allow the same syntax and passs it through?
Nothing, that's what I currently do – without img2pdf, because using imagemagick convert directly can automatically detect and selectively rotate. I then don't have the work to manually watch files and treat them manually.
But then, why should one use img2pdf at all, if it is easier and faster to apply imagemagick to all images separately and concatening the PDFs afterwards without the need to do filthy handwork to give parameters for every single page?
And yes, the unix philosophy is to do one thing right. The point is, that img2pdf is not doing it right. The result is simply wrong.
Another unix philosophy is to have exactly one tool for a given task. And if that task is easier and better with imagemagick + pdfunite, the unix philosophy is to drop img2pdf.
And if you're not willing to make things right, because it'd make the code harder to maintain just because of making it right, the code is questionabel anyways.
Wow, your last comment became quite insulting towards the end. I'm grateful that you are reaching out to report something that you perceive as a problem. But you do understand that dissing my software will only make it less likely for me to spend my free time on something that you would like to have? I'm providing something here for free and you are also free not to use it if you don't like it. I'm not loosing anything if nobody uses my code, you realize that, right? Please try to use a better tone.
You already discovered the
--auto-orientoption but I do not yet understand why what it does is not what you want. Lets create some example input:The resulting PDF will have the first page in landscape and the second in portrait, automatically rotating it to accomodate for the different orientation of the input image. If you then go and print that, does the result look like you want it?
If imagemagick is doing what you want I recommend you use it instead of img2pdf. No hard feelings.
img2pdf has one thing that sets it apart from all the other tools (see the end of the README for a list): it is lossless. If you don't need it, then imagemagick might be a better tool for you.
I do not see yet how it is wrong. I see that you are convinced that it is.
I wish I could. That would mean less work for me. If you know a tool which is able to convert nearly arbitrary raster images to PDF without loosing information, I'm all ears.
Do you want to submit a patch?