View Single Post
Old 02-13-2015, 01:37 PM   #981
willus
Fuzzball, the purple cat
willus ought to be getting tired of karma fortunes by now.willus ought to be getting tired of karma fortunes by now.willus ought to be getting tired of karma fortunes by now.willus ought to be getting tired of karma fortunes by now.willus ought to be getting tired of karma fortunes by now.willus ought to be getting tired of karma fortunes by now.willus ought to be getting tired of karma fortunes by now.willus ought to be getting tired of karma fortunes by now.willus ought to be getting tired of karma fortunes by now.willus ought to be getting tired of karma fortunes by now.willus ought to be getting tired of karma fortunes by now.
 
willus's Avatar
 
Posts: 1,303
Karma: 11087488
Join Date: Jun 2011
Location: California
Device: iPad
Quote:
Originally Posted by dhdurgee View Post
I did give it a try with the above options and agree that it is producing a good, if not totally optimal version. I am a bit surprised at the growth in size, from less than 8mb to over 25mb, is there a way to address that?

Regarding further cropping, it appears from inspecting the original that although there is a consistent footer, except where I have inserted blanks to keep the even/odd pages correct, the header area that I crop out manually only appears at the beginning of articles. Thus the PDF pages are either first page of an article, subsequent pages of an article or inserted blanks.

Is the tool up to such a detailed classification of pages? If so, perhaps this can be further cleaned up.

I also notice that the table of contents got a bit mangled, but other than that a casual check seems to show a good job done on articles themselves.

Thank you for your assistance with this.

Dave
Regarding the size of the converted file (in bytes), you can try using 2-column mode (-mode 2col) which uses native PDF output and therefore preserves the size much better, but it may result in slower rendering (and sometimes out-of-memory errors) on your reader, and it also will not re-flow text from wide/single columns. You might try -ppgs to mitigate slower rendering. On the plus side, this does prevent the TOC from being mangled. Or you can reduce the number of bits per pixel from 4 to a smaller number, e.g. 2 (-bpc 2). You can even combine the two methods, using -mode 2col -n- -bpc 2, which will use 2-column mode (preventing any text re-flow) but still do bitmapped rendering rather than native (the -n- turns off the native output feature of 2-column mode).

At this time you can use crop boxes (-cbox) to crop individual sets of pages differently, e.g.

-cbox5,10,20-29 .11in,.04in,5.35in,8.99in


Would crop pages 5, 10, and 20-29 starting at .11 inches from the left, 0.04 inches from the top, to a width x height of 5.35 in x 8.99 in. But for me it wouldn't be worth it go to that kind of trouble just for casual reading.

If you want to get really fancy, you can use the -p option to only process certain source pages (different ways) and then re-assemble all of the converted parts with something like PDFtk or jpdftweak. But again, for me, it wouldn't be worth it for casual reading.
willus is offline   Reply With Quote