k2pdfopt: optimizes PDFs for viewing on e-readers

[aanno]

Dear willus,

I have tried to compile v2.36 from your sources. However:

$ cmake .
-- The C compiler identification is GNU 6.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.8")
-- Found PNG: /usr/lib64/libpng.so (found version "1.6.26")
-- Could NOT find JPEG (missing: JPEG_LIBRARY JPEG_INCLUDE_DIR)
-- Could NOT find JPEG (missing: JPEG_LIBRARY JPEG_INCLUDE_DIR)
-- Could NOT find Jasper (missing: JASPER_LIBRARIES JASPER_INCLUDE_DIR JPEG_LIBRARIES)
-- Found ghostscript executable
-- Checking for module 'mupdf'
-- No package 'mupdf' found
-- Checking for module 'ddjvuapi'
-- No package 'ddjvuapi' found
-- Willuslib sources: ansi.c;array.c;bmp.c;bmpdjvu.c;bmpmupdf.c;dtcompre ss.c;filelist.c;fontdata.c;fontrender.c;gslpolyfit .c;linux.c;math.c;mem.c;ocr.c;ocrjocr.c;ocrtess.c; pdfwrite.c;point2d.c;render.c;strbuf.c;string.c;to ken.c;wfile.c;wgs.c;wgui.c;willusversion.c;win.c;w inbmp.c;wincomdlg.c;winmbox.c;winshell.c;wmupdf.c; wmupdfinfo.c;wpdf.c;wsys.c;wzfile.c

-- Summary --

General:
C-flags: ' -DUSE_CMAKE -Wall' (-DCMAKE_C_FLAGS="...")
Build type: (-DCMAKE_BUILD_TYPE="...")

Install:
Prefix: '/usr/local' (-DCMAKE_INSTALL_PREFIX=...)
Doc path: '' (-DDOC_PATH=...)

-- Configuring done
CMake Error at willuslib/CMakeLists.txt:27 (add_library):
Cannot find source file:

ocrjocr.c

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx


CMake Error: Cannot determine link language for target "willuslib".
CMake Error: CMake can not determine linker language for target: willuslib
-- Generating done
-- Build files have been written to: /home/tpasch/scm/k2pdfopt_v2.36

Is there something to overcome this problem?

Cheers,

aanno

[eschwartz]

AFAIK the CMake files were provided by someone else a long time ago and never updated... willus doesn't use a build system.

However, there is a worked example of building it by hand (using system libraries) in the AUR, if you are an Arch Linux user. It is linked from the k2pdfopt homepage.

[gerhaher]

Hi!

I´ve recently discovered this excellent program, so I'm still in the learning phase.

I've got a problem with the 2 columns to the right in the attached document. As you can see the program doesn't understand that the blue-shadowed text is one block.

I've tried dabble with different commandos like -crgh, -gtc, -gtr. But nothing works.

Thanks.

[willus]

Originally Posted by gerhaher

Hi!

I´ve recently discovered this excellent program, so I'm still in the learning phase.

I've got a problem with the 2 columns to the right in the attached document. As you can see the program doesn't understand that the blue-shadowed text is one block.

I've tried dabble with different commandos like -crgh, -gtc, -gtr. But nothing works.

Thanks.

k2pdfopt doesn't have any intelligence at all in terms of trying to group together regions with shaded backgrounds. That might be something I could work on at some point. For now, if you want to fix it, you have two options that I can think of: 1. You can protect the shaded region with a box (see this help page), but the boxed region will not be broken into separate columns, or 2. You can use crop boxes on that page:

k2pdfopt -cbox1 0.4in,0.54in,2.39in,9.73in -cbox1 2.85in,0.56in,4.61in,5.24in -cbox1 2.8in,5.91in,4.85in,4.29in ...

This will give you what you want, and you can use the k2pdfopt GUI to determine the crop boxes (see attached--click the "select" button to graphically select each cropbox). The "1" after each "-cbox" specifies the exact page to apply it to. The three crop boxes go around the first column, the shaded region and then the region below the shaded region. Sorry there's not an easier / smarter way at the moment.

[willus]

Actually, let me think on it some more. There may be a couple of other options. One would be to put a line underneath the shaded region. I'll try a couple more things.

[willus]

So a line underneath the shaded section worked very well (added with Foxit Reader similar to the instructions on this page). Running k2pdfopt with the -col 4 option then correctly interpreted the page. See attachments I checked the algorithm for the column detection, and it doesn't presently have an option where a large vertical gap between regions (see attached "gap_example") would be a signal to treat them each as an individual set of columns. That might be something to consider for a future version.

[miomaz]

I don't know if you take suggestions, but it would be a nice addition to the crop function:

in some pdfs there is more whitespace towards the neck of the 'book' meaning that e.g. for even pages there is more white space on the right and for odd pages there is more on the left page.

It would be cool if there'd be an option to specify the to-be cropped region of pages in dependance to the page number. The simplest way would be an option for the user to distinguish between even and odd pages. A general solution would be if the user could specify a formula e.g. 2*n = [2,4,6,...] or 2*n - 1 = [1,3,5,...] which determines which pages should be cropped in which way. If multiple crop regions are specified which are assigned to the same page, the one declared first could take precedence. Negative page numbers could be ignored.

Just a thought. In any case thanks for this tool, it really has helped me over the years.

[willus]

Originally Posted by miomaz

I don't know if you take suggestions, but it would be a nice addition to the crop function:

in some pdfs there is more whitespace towards the neck of the 'book' meaning that e.g. for even pages there is more white space on the right and for odd pages there is more on the left page.

It would be cool if there'd be an option to specify the to-be cropped region of pages in dependance to the page number. The simplest way would be an option for the user to distinguish between even and odd pages. A general solution would be if the user could specify a formula e.g. 2*n = [2,4,6,...] or 2*n - 1 = [1,3,5,...] which determines which pages should be cropped in which way. If multiple crop regions are specified which are assigned to the same page, the one declared first could take precedence. Negative page numbers could be ignored.

Just a thought. In any case thanks for this tool, it really has helped me over the years.

This feature has been available since v2.13. See the command-line usage on the -cbox option. E.g.

k2pdfopt -cbox2-e .2s,.2s,.7s,.7s -cbox1-o .1s,.2s,.7s,.7s ...

... will crop the even (2-e) and odd (1-o) pages differently.

[gerhaher]

Hi Willus!

When I convert A (for a Kobo Aura) I get B: the first two lines are divided into two columns. First I try to set the -col option to 1, but it doesn't help.

When I change -gtr to 0.0009 I get a better result: C.


However, I wonder why it didn't work with just changing to -col 1? Why did it think there were two columns? In your Help-pages you have written: "Setting to 1 will turn off multiple-column detection, i.e. k2pdfopt will not look for multiple columns."

Thanks!

[willus]

Originally Posted by gerhaher

...
However, I wonder why it didn't work with just changing to -col 1? Why did it think there were two columns? In your Help-pages you have written: "Setting to 1 will turn off multiple-column detection, i.e. k2pdfopt will not look for multiple columns."...

This is not a column issue. It's an issue caused by the large double-row letter that leads off the text, which confuses k2pdfopt in this case (under the default settings) into not being able to correctly determine the rows of text because it doesn't see a clean break between the first two rows. It then incorrectly treats those two rows of text as a single row of text and tries to re-flow that "double row" of text. You cleverly adjusted a setting to fix this, but k2pdfopt still doesn't correctly separate out the stylized first letter--it just breaks it in half. This is the best it does for now, without adding more intelligence for detecting this special case.

Your case probably just barely exceeded some internal threshold for detecting that first letter with the default settings. From my notes for v2.20 in the history file:

While not a perfect work-around, large, stylized first letters which frequently begin a book chapter (typically the height of 2 or 3 normal-sized text rows) are now detected when wrapping text lines so that the lines adjacent to them are more-or-less correctly wrapped. Still needs improvement.

[killout]

Hello, Willus.
I'm trying to achieve the following:
Take A4 pdf, remove margins, and slice it to make height and witdth of the page exactly as ipad air 2 screen in landscape mode.
I spent several hours playing with options, but it doesn't work as expected. For some reason output pdf is not fitting ipad screen, and have some random page size.
I'm trying:
./k2pdfopt -n -wrap- -col 1 -vb -1 -t -h 1536 -w 2048 -dpi 264 file.pdf
k2pdfopt v2.36 (w/MuPDF,DjVuLibre,OCR) (c) 2016, GPLv3, http://willus.com
Compiled Nov 26 2016 with Gnu C v4.8.5 for Linux on x64.

Could you please advice what should be correct command for slicing pdf pages to ipad air 2 screen using your cool powerful tool?
Thank you for creating it!

[willus]

Originally Posted by killout

Hello, Willus.
I'm trying to achieve the following:
Take A4 pdf, remove margins, and slice it to make height and witdth of the page exactly as ipad air 2 screen in landscape mode.
I spent several hours playing with options, but it doesn't work as expected. For some reason output pdf is not fitting ipad screen, and have some random page size.
I'm trying:
./k2pdfopt -n -wrap- -col 1 -vb -1 -t -h 1536 -w 2048 -dpi 264 file.pdf
k2pdfopt v2.36 (w/MuPDF,DjVuLibre,OCR) (c) 2016, GPLv3, http://willus.com
Compiled Nov 26 2016 with Gnu C v4.8.5 for Linux on x64.

Could you please advice what should be correct command for slicing pdf pages to ipad air 2 screen using your cool powerful tool?
Thank you for creating it!

try:
k2pdfopt -mode fitwidth -w 1536 -h 2048 -dpi 264 file.pdf

[killout]

Originally Posted by willus

try:
k2pdfopt -mode fitwidth -w 1536 -h 2048 -dpi 264 file.pdf

This is close to what I'm trying to achieve, but I do not need rotation of pages, and
./k2pdfopt -mode fitwidth -ls- -w 1536 -h 2048 -dpi 264 -p
for some resaon doesn't work as expected: pages are not 3:4 proportions

[willus]

Originally Posted by killout

This is close to what I'm trying to achieve, but I do not need rotation of pages, and
./k2pdfopt -mode fitwidth -ls- -w 1536 -h 2048 -dpi 264 -p
for some resaon doesn't work as expected: pages are not 3:4 proportions

Can you post an example of your source PDF and the output your getting? The command you list above (not counting the "-p") worked fine for me (output is 5.82 x 7.76 in). See attached.

[killout]

Hello, Willus.

So this is what I executed:
./k2pdfopt -mode fitwidth -ls- -w 2048 -h 1536 -dpi 264 ansible-for-devops-sample.pdf

And in the attach is what I got. They output does has proportions,what I want, width: 2048, height: 1536, so I can read on ipad in landscape mode.The thing is large white margins, which I would like to get rid of, by enlarging content to the size of ipad screen, so desired output pdf is 2048*1534, but with no margins. Is it possible to do?