k2pdfopt: optimizes PDFs for viewing on e-readers

[willus]

Rip8--unfortunately k2pdfopt does not transfer the hyperlinks to the converted files at this time. I'll make a note of your request.

[phate89]

Hi. I have a very weird problem.
I'm using this command to split files in half:
k2pdfopt -grid 2x1x0 -mode crop -p 2-4 "input.pdf" -n -o "output.pdf"
It gives me a very well split pdf with pages in half.
The problem is that if i open the pdf in calibre I see them attached. They are logically bound in some way. If i open them with adobe reader I see them splitted how they want.
The problem is that if i convert them from pdf to other formats I get compressed images with the 2 pages joined.
How can I avoid that? I can't understand why it does that
Thanks in advance!

[willus]

Did you try the -ppgs option? This post-processes with Ghostscript and sometimes helps with problems like this. The issue is that k2pdfopt is taking the original PDF and adding cropping commands to show cropped portions of each page (it does this in “native” mode), and it sounds like some software doesn’t respect that or ignores that. You could turn off native mode also (-n-) but that will bitmap each page and may not be what you want.

[phate89]

I understand now.. that option didn't do anything. I went with non-native option (it's still a scanned pdf afterall with images so no problem).
it seems is a known problem of the pdf reader they use and it's there since a long time:
https://bugs.launchpad.net/calibre/+bug/881717
thanks for the help!

[stillstill]

Hello,

Is there any possible way to remove hyphen when in the original pdf we have a line ending with a word and hyphen (without a space between them):

This is an original example where we do not need to pre-
serve the hyphen in the word "preserve" if it is not broken
in two lines in the output file. The algorithm/rule is simple.
If we have any character (not a space) preceding the hyphen,
it means we have a word break between the lines.

And in opposite - this is an original example where we need
to keep the dash in the destination file.

If the line ended with a word and dash like this -
that would mean we still need to preserve this dash in the
destination (since there is a space preceding the dash)

Not sure if that's possible at all, could not find any set of parameters
that would work like this...

Thank you very much.
Using KPW2, if that matters...

[stillstill]

Originally Posted by stillstill

Hello,

Is there any possible way to remove hyphen when in the original pdf we have a line ending with a word and hyphen (without a space between them):

This is an original example where we do not need to pre-
serve the hyphen in the word "preserve" if it is not broken
in two lines in the output file. The algorithm/rule is simple.
If we have any character (not a space) preceding the hyphen,
it means we have a word break between the lines.

And in opposite - this is an original example where we need
to keep the dash in the destination file.

If the line ended with a word and dash like this -
that would mean we still need to preserve this dash in the
destination (since there is a space preceding the dash)

Not sure if that's possible at all, could not find any set of parameters
that would work like this...

Thank you very much.
Using KPW2, if that matters...

Attaching the screenshots - original and converted, problematic place is red marked.

[willus]

K2pdfopt should remove hyphens (-hy option) by default. Do you have the source PDF or a sample of it that I could test out?

[willus]

I converted your bitmap to a pdf at 150 dpi and then processed it with k2pdfopt using the default parameters. It eliminated 3 of the 4 hyphens. See attached.

[MarjaE]

Hi,

If I'm using k2pdfopt -mode copy to convert a png map to pdf and moderately compress it, is there any way to compress less aggressively?

I've tried adjusting -dr 2, -dr 4, -odpi, -w and -h, etc. but it always outputs the same compression and file size, which is much too aggressive for me.

[willus]

MarjaE — try using -idpi -1 — that will force the input and output dpi to remain the same and thus k2pdfopt will not change the resolution of your .png file:

k2pdfopt -mode copy -idpi -1 myfile.png

By default, the input dpi is 2x the output dpi (-idpi -2), which results in k2pdfopt resampling your image at half the resolution if supplied with a .png file unless you are careful to specify output resolution, width, and height all together.

If you specify -odpi on the above command also, it will set the size of the PDF page.

[MarjaE]

Thank you, that worked.

[stillstill]

Originally Posted by willus

I converted your bitmap to a pdf at 150 dpi and then processed it with k2pdfopt using the default parameters. It eliminated 3 of the 4 hyphens. See attached.

Attaching original and output. 3 hyphens have not been removed in the first page of the output. Converted using the following options:

-dev kp2 -fs 12 -o C:\Users\demo\Downloads\%b_k2opt -nt -80 -ocrlang lit -ocr t -as -p 7 -cbox- -ibox- -cbox 0.3066in,0.1775in,4.147in,6.423in

additional options:
-f2p -1 -bp-- -fc-

Any ideas how to improve the hyphens detection?...
Thank you

[willus]

Originally Posted by stillstill

Any ideas how to improve the hyphens detection?...

Improving hyphen detection for this case would require a code modification. I'll make a note of it and maybe add an extra command-line option to tweak hyphen detection in the future. These hyphens are a bit "stubby" and also tilted somewhat, which is odd.

[stillstill]

Originally Posted by willus

Improving hyphen detection for this case would require a code modification. I'll make a note of it and maybe add an extra command-line option to tweak hyphen detection in the future. These hyphens are a bit "stubby" and also tilted somewhat, which is odd.

Zoomed in, and, indeed - they are tilted a bit. IMHO the easiest logic would be just if we have any dash-like symbol at the end of line, that is not preceded with space it should be interpreted as a hyphen. And I believe the hardest part is to detect that dash-like symbol, especially if we have slightly different types of it (like slight tilting, symbol width, line width...) due to variety of fonts used.

Anyway I really do appreciate your talent and hard work on this truly ingenious tool helping millions mobile readers.

[willus]

Originally Posted by stillstill

Zoomed in, and, indeed - they are tilted a bit. IMHO the easiest logic would be just if we have any dash-like symbol at the end of line, that is not preceded with space it should be interpreted as a hyphen. ...

FYI the current detection algorithm is looking at the graphic, not the characters. It is looking for the "shape" of a hyphen. Thanks for the nice comments--I'm not sure k2pdfopt is helping millions, though--the download count is at 700k. Not that I'm complaining.