I have around 60 pages of a calculus book scanned, and I would like to add in the answers for each chapter’s questions after the last page for questions. When opening the original jpeg files I see the pixel dimensions are different, thus I use open up terminal and enter:
1) a@a-NC210-NC110:~/Desktop/Calc03Project$ sudo mogrify -resize 1200 -format jpg -quality 100% -verbose Calc03-05*.jpg
Calc03-050.jpg JPEG 2400x610 2400x610+0+0 8-bit DirectClass 381KB 0.080u 0:00.080
Calc03-050.jpg JPEG 2400x610=>1200x305 1200x305+0+0 8-bit DirectClass 156KB 1.080u 0:00.660
Calc03-051.jpg JPEG 2400x926 2400x926+0+0 8-bit DirectClass 608KB 0.140u 0:00.139
Calc03-051.jpg JPEG 2400x926=>1200x463 1200x463+0+0 8-bit DirectClass 246KB 1.670u 0:01.100
... (etc.)
　　When I reopen up the same jpg files with image viewer, it shows that all of them have the same pixel width. I then proceed to convert these files into separate pdf files with the following command (I have a netbook, so the convert command isn’t suitable):
2) a@a-NC210-NC110:~/Desktop/Calc03Project$ sudo mogrify -verbose -format pdf *.jpg
Calc03-048.jpg JPEG 1200x1526 1200x1526+0+0 8-bit DirectClass 767KB 0.150u 0:00.210
Calc03-048.jpg=>/tmp/magick-hBgCr0sL JPEG 1200x1526 1200x1526+0+0 8-bit DirectClass 758KB 0.240u 0:00.250
Calc03-048.jpg=>/tmp/magick-2-F0q41n JPEG 1200x1526=>83x106 8-bit DirectClass 4.1KB 0.000u 0:00.000
Calc03-048.jpg=>Calc03-048.pdf JPEG 1200x1526 1200x1526+0+0 8-bit DirectClass 770KB 0.390u 0:00.480
Calc03-049-050.jpg JPEG 1200x1492 1200x1492+0+0 8-bit DirectClass 776KB 0.320u 0:00.379
Calc03-049-050.jpg=>/tmp/magick-BO6Ftuq1 JPEG 1200x1492 1200x1492+0+0 8-bit DirectClass 831KB 0.350u 0:00.370
Calc03-049-050.jpg=>/tmp/magick-DDLMbjPF JPEG 1200x1492=>85x106 8-bit DirectClass 8.19KB 0.010u 0:00.009
Calc03-049-050.jpg=>Calc03-049-050.pdf JPEG 1200x1492 1200x1492+0+0 8-bit DirectClass 844KB 0.510u 0:00.570

Notice how on the third result line for each file a “=>83x106” is returned, while this was the original filesize, still this causes my “something’s wrong” alarm to go off. Resultingly, I import the newly formed file into gimp, and on the “import from pdf” opening screen Gimp shows “width(pixels): 400”.
Ahhh!! ;(...
So I then know my previous misgivings arising from “=>83x106” were accurate. Thus I delete all the pdf files, and retry with:
sudo mogrify -verbose -format pdf -resize 1200 -quality 100% *.jpg
Calc03-049-050.jpg JPEG 1200x1492 1200x1492+0+0 8-bit DirectClass 776KB 0.320u 0:00.339
Calc03-049-050.jpg=>/tmp/magick-zGwu26ca JPEG 1200x1492 1200x1492+0+0 8-bit DirectClass 831KB 0.350u 0:00.350
Calc03-049-050.jpg=>/tmp/magick-WtKuOIYg JPEG 1200x1492=>85x106 8-bit DirectClass 8.19KB 0.000u 0:00.000
Calc03-049-050.jpg=>Calc03-049-050.pdf JPEG 1200x1492 1200x1492+0+0 8-bit DirectClass 844KB 0.500u 0:00.510
Calc03-051.jpg JPEG 1200x463 1200x463+0+0 8-bit DirectClass 246KB 0.060u 0:00.059
Calc03-051.jpg=>/tmp/magick--HYekWWn JPEG 1200x463 1200x463+0+0 8-bit DirectClass 246KB 0.080u 0:00.140
Calc03-051.jpg=>/tmp/magick-GIwUmzov JPEG 1200x463=>106x41 8-bit DirectClass -0.000u 0:00.000
Calc03-051.jpg=>Calc03-051.pdf JPEG 1200x463 1200x463+0+0 8-bit DirectClass 250KB 0.200u 0:00.279
Again, you notice the same “=>85x106” note on every third line. When checking the width of the pdf page (pixels) via importing a file into GIMP, I then find a “width(pixels): 1200” reading, so to combine the different pdf files into one pdf file, I then enter:
3) pdftk *.pdf cat output CalcCh03.pdf
I then open up the file, and alas, the pages are still different widths.
Morbidly, I go back to the second step and try with a 640 width, which produces the same exact results.

Any solutions? I don’t have $1000USD for the adobe photoshop pro software package, so that isn’t an option.

Andrew Comly
andrew.comly@gmail.com

a few things
you should NEVER NEVER need to use "sudo" for files in YOUR HOME folder
almost NEVER should you need to do that

you do NOT need root authority in YOUR home folder

second
the "Desktop" folder is not really a normal everyday folder .
And in some Desktop managers you ARE mostly forbidden do use it as a normal folder

it is advisable to NOT use the "Desktop" folder
it is more and more just a DECORATIVE folder as a "starting place" when you log in
And there might be unintended problems from time to time if the "Desktop" folder is used


you likely have a
~/bin , or ~/Documents
or make a folder
~/projects




A pdf in gimp can be almost any size ( like a svg )
that 400 Pixel per inch is a default

one of the size issues is ALL and i mean ALL of the jpg's are ALL in one folder
and your commands are using ALL ( even the OLD versions) of jpg's in that one folder

the mogrfy command uses ALL the jpg's in the folder
if you make NEW jpg's
the next mogify command will use the NEW and the OLD jpg's

-- all of them , not just the NEW ones

save them in different folders


and NOT on the Desktop

1 members found this post helpful.

I follow John VV's advice and create and put all the files in a folder /home/a/Documents/Calc03Project. I then chmod the output jpg files with a chmod 777 *.jpg. Next, I repeat the above steps without the “sudo” prefix, first as below:
a@a-NC210-NC110:~/Documents/Calc03Project/1200Produce$ mogrify -verbose -format pdf -resize 1200 -quality 100% *.jpg
Calc03-000.jpg JPEG 1200x1696 1200x1696+0+0 8-bit DirectClass 900KB 0.140u 0:00.139
Calc03-000.jpg=>/tmp/magick-qdBbfbBd JPEG 1200x1696 1200x1696+0+0 8-bit DirectClass 897KB 0.210u 0:00.220
Calc03-000.jpg=>/tmp/magick-hNZWlftU JPEG 1200x1696=>75x106 8-bit DirectClass 4.1KB 0.010u 0:00.000
Calc03-000.jpg=>Calc03-000.pdf JPEG 1200x1696 1200x1696+0+0 8-bit DirectClass 905KB 0.330u 0:00.290
Calc03-001.jpg JPEG 1200x1696 1200x1696+0+0 8-bit DirectClass 801KB 0.120u 0:00.120
Calc03-001.jpg=>/tmp/magick-2STxheBB JPEG 1200x1696 1200x1696+0+0 8-bit DirectClass 799KB 0.200u 0:00.200
Calc03-001.jpg=>/tmp/magick-66pcTdej JPEG 1200x1696=>75x106 8-bit DirectClass 4.1KB 0.010u 0:00.000
Calc03-001.jpg=>Calc03-001.pdf JPEG 1200x1696 1200x1696+0+0 8-bit DirectClass 807KB 0.330u 0:00.280

Again, notice the same old annoying “>75x106 8-bit ” code in the third line.

I then move the above pdf files into a subfolder ToBind. I check permissions with ls -la and it shows the product pdf files are “-rw-rw-r-- 1 a a 903885 10月 11 11:25 Calc03-043.pdf”, thus I run “chmod 777 *.pdf” just to be on the safe side.

I open several of the output files in Gimp and it shows that some are >300 wide and some 5000 wide. This is not reassuring, but I am a patient person and I know how easy it is for a computer to have a glitch or bug, etc. So I rescale in Gimp (to width 1200), then export to a new folder (same file name), I then close and re-import the same pdf file into gimp(to check that GIMP saved correctly) where it sometimes shows a width of 1200, and sometimes shows a width noncongruent with what I just set, proving that GIMP isn't overwriting correctly. This really prooves the existence of a bug, because there is no way I didn't just reset those pdf files width to 1200 in Gimp 3 seconds ago. What a buggy mess.

Anyway, I then run “pdftk *.pdf cat output CalcCh03.pdf” and get the same output: a pdf file with pages of different widths.
a@a-NC210-NC110:~/Documents/Calc03Project/1200Produce/ToBind$ pdftk *.pdf cat output CalcCh03.pdf
a@a-NC210-NC110:~/Documents/Calc03Project/1200Produce/ToBind$

Is resizing jpg pages into 1200 width then turning them into pdf pages in order to produce an ebook that has congruent widths something that computers simply can't do yet? Do I have a false expectation on what a computer is capable of? Anyone have an estimate to how many years in the future a computer will be able to do this?

Andrew

i would break it up into two parts
and NOT use gimp to "test " the size
gimp can and will make it any size you want

resaving a jpg as a jpg is NEVER a good idea

1 members found this post helpful.

I follow John VV's advice and execute in two parts, first as follows:

a@a-NC210-NC110:~/Documents/Calc03Project/1200Produce$ mogrify -verbose -format png -resize 1200 *.jpg

Calc03-000.jpg JPEG 1200x1696 1200x1696+0+0 8-bit DirectClass 900KB 0.130u 0:00.129
Calc03-000.jpg=>Calc03-000.png JPEG 1200x1696 1200x1696+0+0 8-bit DirectClass 1.876MB 2.370u 0:02.370
Calc03-001.jpg JPEG 1200x1696 1200x1696+0+0 8-bit DirectClass 801KB 0.120u 0:00.129
Calc03-001.jpg=>Calc03-001.png JPEG 1200x1696 1200x1696+0+0 8-bit DirectClass 1.528MB 2.320u 0:02.330

I then move the above pdf files into a subfolder ToBind. I check permissions with ls -la and it shows the product pdf files are “-rw-rw-r-- 1 a a 903885 10月 11 11:25 Calc03-043.pdf”. I leave it as is. I then enter the second command John so graciously provided:

a@a-NC210-NC110:~/Documents/Calc03Project/1200Produce$ cd ToBind
a@a-NC210-NC110:~/Documents/Calc03Project/1200Produce/ToBind$ mogrify -verbose -format pdf *.png
Calc03-000.png PNG 1200x1696 1200x1696+0+0 8-bit DirectClass 1.879MB 0.200u 0:00.199
Calc03-000.png=>Calc03-000.pdf PNG 1200x1696 1200x1696+0+0 8-bit DirectClass 1.892MB 1.530u 0:01.480
Calc03-001.png PNG 1200x1696 1200x1696+0+0 8-bit DirectClass 1.528MB 0.190u 0:00.199
Calc03-001.png=>Calc03-001.pdf PNG 1200x1696 1200x1696+0+0 8-bit DirectClass 1.544MB 1.490u 0:01.440


Notice above how finally there is no annoying “>75x106 8-bit ” above. Certainly John VV's method is a step above my original methods, and I will make this my new procedure for future projects. Finally, I then run “pdftk *.pdf cat output CalcCh03.pdf”.

Unfortunately, I still get the same output: a pdf file with pages of different widths for p50 - 63.
a@a-NC210-NC110:~/Documents/Calc03Project/1200Produce/ToBind$ pdftk *.pdf cat output CalcCh03.pdf
a@a-NC210-NC110:~/Documents/Calc03Project/1200Produce/ToBind$

I later went back to 1200Produce and first chmod 777 to change the permissions of the png files, then 1)"mogrify -verbose -format png -resize 1200 *.jpg" and then changed the permissions of the product pdf files and then 2)"mogrify -verbose -format pdf *.png", which still has the same pdf file with smaller pages for p50 - 63.

Am I using the wrong way to go about this? Could python help?

Andrew

I'm pretty sure I solved this. The only thing left to test is if it works in Lubuntu. Actually my netbook is a dual boot: Lubuntu 13.04 & Debian 7.0-LXDE. The following script worked in Debian. Debian 7.0-LXDE's default for pdfimages, that is the default output file type is PPM, not PBM like it is for pdfimages command in lubuntu. Again, the key is to output to PPM, not PBM:

Starting with a single pdf:
pdfimages -j FILENAME.pdf TARGETNAME && mkdir complete jpg pdf ppm && mogrify -verbose -format ppm -resize 1240 *.jpg && mv *.ppm ppm && mv *.jpg jpg && cd ppm && mogrify -verbose -format pdf *.ppm && pdftk *.pdf cat output NewPDF.pdf && mv NewPDF.pdf .. && cd .. && mv ppm/*.pdf pdf && mv -t complete jpg pdf ppm

Or if your starting with multiple jpgs:
mkdir complete jpg pdf ppm && mogrify -verbose -format ppm -resize 1240 *.jpg && mv *.ppm ppm && mv *.jpg jpg && cd ppm && mogrify -verbose -format pdf *.ppm && pdftk *.pdf cat output NewPDF.pdf && mv NewPDF.pdf .. && cd .. && mv ppm/*.pdf pdf && mv -t complete jpg pdf ppm

I'll test it in Lubuntu this weekend, and hope to post a YouTube tutorial very soon also.

I just verified with 2 trial runs that I can do this in lubuntu, the commands I use are as follows:

[starting with multiple pdf original scan files]
1) pdftk *.pdf cat output e.pdf
2) pdftoppm -aa yes -aaVector yes -freetype yes -r 400 e.pdf e && mkdir pdf ppm pbm jpg complete
3) echo “Verify that output images don't need rotating.”
4) mogrify -quality 100 -verbose -format ppm -resize 1920 *.ppm && mogrify -quality 100 -verbose -format ppm -resize 1920 *.jpg; mv *.pdf pdf; mv *.ppm ppm; mv *.pbm pbm; mv *.jpg jpg; echo Please open ppm folder and verify ppm images width
5) cd ppm && mogrify -quality 100 -verbose -format pdf *.ppm && pdftk *.pdf cat output eNotebook.pdf && mv eNotebook.pdf .. && cd .. && mv ppm/*.pdf pdf ; mv -t complete ppm pdf pbm jpg

Notice how in 2 above I switched from pdfimages to pdftoppm. This is because on several trials the pdfimages command would rotate random pages within the source pdf file. And yes, I did previously verify that all pages within the source pdf file were right side up. Moreover, some pages would come out as jpg with the -j option, and when I figured that out and replace "-j" with a "-p", some pages would be in ppm and some would be in pbm. Now that's too much extra work for me. The command pdftoppm really does a better job. The -r option is essential for decent resolution, without it pdftoppm's default is 150, which simply is too low for a notebook.

In steps 4 & 5 above, on previous attempts I noticed how resolution was lower than the original source pdf files, then I looked up on the web(somewhere) that the default quality for mogrify is only 75%, which does turn over what John VV advised above. I feel that one really does need the -quality 100 option.

Since for most part I need this to scan my notebook pages, and my handwriting is in cursive and is rather small, I switched to 1920 width, and FYI the original scan pdf files were scanned with at least resolution of 400dpi.

For a continuous command I use the following, starting with multiple pdf files(original scan):
pdftk *.pdf cat output e.pdf && pdftoppm -aa yes -aaVector yes -freetype yes -r 400 e.pdf e && mkdir pdf ppm complete && echo Please verify that output images don't need rotating && mogrify -quality 100 -verbose -format ppm -resize 1920 *.ppm; mv *.pdf pdf; mv *.ppm ppm; echo Please open ppm folder and verify ppm images width && cd ppm && mogrify -quality 100 -verbose -format pdf *.ppm && pdftk *.pdf cat output eNotebook.pdf && mv eNotebook.pdf .. && cd .. && mv ppm/*.pdf pdf ; mv -t complete ppm pdf

Learning how to do things on Linux is quite tough, certainly freedom can only come at a great personal sacrifice. I hope this information can help others create their own eNotebooks. We are lucky we don't have to sacrifice our blood like George Washington and the other founders of the USA and merely have to sacrifice our time/brainpower.

This thread is hereby solved, and I will try to make a tutorial in the next two weeks.
Andrew