Any update in working with comicbooks:
"Cannot yet convert the comic book. It can still split the image pdfs into two." When I just tried it out on a comicbook images combined to a pdf, it was able to crop it but not remove any of the dead white space/margins.
And is there a way to change the resolution/size of the cropping so it work for the Kindle 3?
Could you be a little clearer? Removing the dead white space/margins is what cropping means, so I don't know what you could mean by saying that it was able to crop but not do that. Do you mean that it split but didn't crop? Are these comics scanned? Scanned whitespace is not real whitespace so that won't get cropped.
BRISS might be a better tool for that if so.
Code
Processing input page : 486warning: masks can not have colorspace, proceeding anyway.
Copying output page : 964Error: .\stream\obj_dict.c(96) : fz_deepcopydict() - assert: not a dict (<n
il>)
Get this error when converting...
no parameters set, except -i -o
any clue ??
Quote frabjous
Could you be a little clearer? Removing the dead white space/margins is what cropping means, so I don't know what you could mean by saying that it was able to crop but not do that. Do you mean that it split but didn't crop? Are these comics scanned? Scanned whitespace is not real whitespace so that won't get cropped.
BRISS might be a better tool for that if so.
BRISS will not be a good program for this as the white space margins are not the same on each page.
Quote SunLight
BRISS will not be a good program for this as the white space margins are not the same on each page.
Well, BRISS does sort out pages into groups with similar margins and let you crop each group differently, but if actually every page is different, then yeah, it might not work. Have you considering trying something like the script I give at the bottom of
this thread using Ghostscript/calibre? (Though I doubt that'll work too well if it's a scan either.)
Please explain how page size participates in conversion? I have Kindle 3 and Sony 950, screen dimensions, especially screen heights are apparently different.
Does soPdf default to 6 inches?
Also, I don't see sopdf source download. on code.google.com.
Is source code still somehow available?
It would be possible to crop each page of a .pdf into 4 parts?
I would like to read on mi kindle 3 like the four steps per pages that it is shown in this video at time 2:30:
http://www.youtube.com/watch?v=co5bPVY95DY&feature=channelSoPdf works very well but the size of the letters continues to be too small for me.
Thank You very much
Quote pherodeon
It would be possible to crop each page of a .pdf into 4 parts?
BRISS can do that. It would be tricky trying to do with soPDF alone.
Quote frabjous
Yeah, there's a reason the Fit2xWidth option is default, though I don't really understand the naming conventions myself. Too bad theguru isn't around to ask...
I went ahead and compiled a 32 bit linux binary for Nathan's GUI. You'll find it, packaged with the sopdf binary, in Nathan's thread:
http://www.mobileread.com/forums/sho...4&postcount=36I'd appreciate it if you let me know if it works for you, since I've only tested it on one system.
I downloaded Kubuntu 10.04 earlier today, which actually wasn't too bad to download, though I haven't gotten around to installing it. I also installed Lubuntu 10.04 (though it's unofficial) on my Notebook. Nice and fast in general, though updates are taking forever today, yeah.
Thanks for this. Works great here.
Any chance you can get this in the OP so others don't have to wade through the thread?
It seems that there is some sort of memory leak in soPdf.
I'm trying to process
this PDF file with it (i believe this is a prepress of
this book; it contains text, not just scanned images). The file is not that huge, it is just 30MB/632pp.
However, when i'm trying to process it with soPdf with default parameters, soPdf eats about 20MB of RAM per page, up to 2GB (which is Windows limit for 32-bit processes i believe), when it dies with the following message:
Quote
penartur@X220 D:\penartur\Downloads\software\soPdf# soPdf.exe -i 361810.pdf -o "Abel, Bernanke. Macroeconomy.pdf"
soPdf ver 0.1 alpha Rev 12
A program to reformat pdf file for sony reader
Input : 361810.pdf
Output: Abel, Bernanke. Macroeconomy.pdf
Processing input page : 102warning: cannot realloc 16777216 bytes
Error: .\processPdf.cpp(403) : processErrorPage() - Cannot process page 102
Error: .\mupdf\pdf_page.c(241) : pdf_loadpage() - cannot load page resources
Error: .\mupdf\pdf_resources.c(430) : pdf_loadresources() - cannot load xobject resource
Error: .\mupdf\pdf_resources.c(165) : preloadxobject() - cannot load image resource 471
Error: .\mupdf\pdf_stream.c(510) : pdf_loadstream() - cannot load stream into buffer (471)
Error: .\stream\stm_misc.c(103) : fz_readall() - cannot resize scratch buffer
Error: .\stream\stm_buffer.c(83) : fz_growbuffer() - outofmem: resize buffer memory
As you can see, it only processed 1/6th of a book before its death; so, in order to process the entire book, one would need x64 binaries and 12GB or more of free RAM, which seems ridiculous... or to fix that memory leak someway.
