PDFRead 1.8.2 released!

[nrapallo]

Originally Posted by zerospinboson

Creating file ... failed, error details follow.

Traceback (most recent call last):
File "output.pyc", line 140, in generate_imp
File "win32com\client\__init__.pyc", line 95, in Dispatch
File "win32com\client\dynamic.pyc", line 98, in _GetGoodDispatchAndUserName
File "win32com\client\dynamic.pyc", line 78, in _GetGoodDispatch
com_error: (-2147221005, 'Invalid class string', None, None)

Creating Mobipocket ebook ... done.

can anyone tell me what might be going wrong here?

I see that you have an iLiad, and presume you are trying to produce a .prc file.

The only caveat here is that it needs some free software installed to produce the .opf file that is used by 'opf2mobi.exe' to produce the .prc.

Now, I looked at my documentation and I couldn't easily find reference to this. Sorry, I will make this more prominent now!

REQUIRED: You must have the eBook Publisher software previously installed to facilitate the conversions to .imp, .oeb and .prc.

BTW, the error you saw refers to a windows .dll interface call that failed (it was called from 'generate_imp' enroute to creating the .prc). You can install the (free) eBook Publisher software by going here. Then choose to download and install the current version ( Win_eBookPub_2.2.5.exe ).

p.s. there is a current limitation on image sizes (480 max. width) built into the 'opf2mobi.exe' program I am using. This causes larger white margins than it should. I will remove this restriction in the next release and replace 'opf2mobi' with html2mobi' to avoid the use of eBook Publisher when converting to .prc!

[nrapallo]

I have implemented some enhancements and fixed minor bugs in PDFRead 1.8.2 (see post#1 above)

Changes in this release:

Changelog [2008-04-16] 1.8.2 (by NR)

• added an 'imgdir' In Format where you can select any image in a directory and have all images (files) in that directory loaded. This is similar to an 'imglist' but creates its own list of filenames without needing a (previously created) text file.
• for .prc output, removed current limitation on image sizes (480 max. width) and now use a modified 'html2mobi.exe' program. This should no longer causes large white margins. Cybook Gen 3 users are cautioned that images larger than 480x640 may crash your ereader. Please limit the Size H: and V:!
• remembers last 'Output' directory upon startup, but you will need to edit destination filename or may overwrite previous output. To reset it, just type 'default'.

[donovand]

Hi There,

I'm on a Mac, and the version of 1.8 is only a windows executable. Can you please post a mac-friendly version?

Thanks!

[nrapallo]

Originally Posted by donovand

Hi There,

I'm on a Mac, and the version of 1.8 is only a windows executable. Can you please post a mac-friendly version?

Thanks!

The latest source code is up at the PDFRead Dev Hub here.

I will now add the source to post#1 for easy access for all.

The Windows GUI and Installer is NOT mac-friendly, but the source code is python which can be made to work on Mac OS X using the detailed installation instructions in the manual (index.html). For further information, read PDFRead on Mac OS X by sammykrupa

Otherwise, if you can run Windows emulation on your mac, then that would be the route to take (especially if creating .imp formats).

[donovand]

Awesome! I'll be sure and check that out. I tried version 1.7 (command line) for my prs500 last night, but it didn't seem to work properly. It made the .png's but then the .lrf was empty. Interestingly, 1.6 worked fine.

I'll give 1.8 a whirl and see if the mac issues with 1.7 have been fixed.

Is 1.8 a fork? Why does the sourceforge page still only have up to 1.7?

Great software btw.... it's the best workaround for viewing non-optimal pdfs that I've found. Keep up the good work!

[nrapallo]

Originally Posted by donovand

Awesome! I'll be sure and check that out. I tried version 1.7 (command line) for my prs500 last night, but it didn't seem to work properly. It made the .png's but then the .lrf was empty. Interestingly, 1.6 worked fine.

I'll give 1.8 a whirl and see if the mac issues with 1.7 have been fixed.

Is 1.8 a fork? Why does the sourceforge page still only have up to 1.7?

Great software btw.... it's the best workaround for viewing non-optimal pdfs that I've found. Keep up the good work!

This is a sample call from the command line:

Command Line
============

"C:\Program Files\PDFRead\bin\pdfread" -p prs505 -i pdf -t "My Title"  -a "My Author" -c "My Category" -f "lrf" "E:\My Input.pdf"

I have set up the version 1.8 source code at the PDFRead Dev Hub here.

The sourceforge page is "stuck" at version 1.7 since I don't have all the permissions necessary to update it properly, despite being a developer there! I have left comments/messages there to check the new version 1.8 here at mobileread.com.

I'm not sure if PDFRead is truly multi-threaded. Give it a try.

[donovand]

Thanks for the link to the Dev Hub. I posted a ticket about the "debug" feature not working properly.

I had the same problem with 1.8 that I had with 1.7, namely that pdfread was generating empty .lrf files. I tracked it down to an outdated libpng. pngnq wasn't working (silently dying while running inside the python script) and therefore the "page.png" files were not being downsampled and moved to N.png files. I would suggest adding some error checking code there (in the downsample function of the BaseOutput class) instead of relying on the existence of page-nq8.png implicitly like that.

FYI an .dmg installer for a libpng that works is here

Sorry for the confusion regarding "fork"... I meant a fork of the source code (i.e. you are taking over an abandoned or otherwise unsupported project) as opposed to multi-threading. But you answered my question anyway.

[nrapallo]

Originally Posted by donovand

Thanks for the link to the Dev Hub. I posted a ticket about the "debug" feature not working properly.

The 'debug' feature was 'fixed' in the latest release so that if PDFRead 'sees' the existence of a file named 'debug' in the current directory of the GUI (defaults to 'C:\Program files\PDFRead') or inside its subdirectory 'bin', then it leaves the resulting files used to create the selected ebook format. It does not 'retain' the intermediary files used throughtout the conversion process i.e page*.*. BTW, if you're quick enough you can open the temporary folder assigned and copy the intermediary files elsewhere, prior to the end of the conversion.

I had the same problem with 1.8 that I had with 1.7, namely that pdfread was generating empty .lrf files. I tracked it down to an outdated libpng. pngnq wasn't working (silently dying while running inside the python script) and therefore the "page.png" files were not being downsampled and moved to N.png files. I would suggest adding some error checking code there (in the downsample function of the BaseOutput class) instead of relying on the existence of page-nq8.png implicitly like that.

FYI an .dmg installer for a libpng that works is here

Thanks for your bug-tracking services . Is your fix related to the Windows side or the Mac side? The link provided appears to indicate Mac side, but I will see if I can incorporate the newer version anyway. I mean, if it doesn't break something else...

Sorry for the confusion regarding "fork"... I meant a fork of the source code (i.e. you are taking over an abandoned or otherwise unsupported project) as opposed to multi-threading. But you answered my question anyway.

While I have had some sporadic contact with the original developer, I am pretty much 'going-it-alone'. BTW, thanks for your comments and insights.

[donovand]

Originally Posted by nrapallo

The 'debug' feature was 'fixed' in the latest release so that if PDFRead 'sees' the existence of a file named 'debug' in the current directory of the GUI (defaults to 'C:\Program files\PDFRead') or inside its subdirectory 'bin', then it leaves the resulting files used to create the selected ebook format. It does not 'retain' the intermediary files used throughtout the conversion process i.e page*.*. BTW, if you're quick enough you can open the temporary folder assigned and copy the intermediary files elsewhere, prior to the end of the conversion.

I realized after I read this that the libpng bug was creating page.png's and not N.png, so it looked like all the temporary files were being deleted. Now I understand that there are two types of temporary file: the final images (that get put into the eBook) and the intermediate files getting to that image. I hereby recind my ticket.

Thanks for your bug-tracking services . Is your fix related to the Windows side or the Mac side? The link provided appears to indicate Mac side, but I will see if I can incorporate the newer version anyway. I mean, if it doesn't break something else...

You're welcome. Glad to help. Sorry I wasn't clear about that.... I was testing on the Mac. That being said, if a windows person had an old version of libpng, then I suspect they might have a similar problem.

[nrapallo]

Originally Posted by donovand

I realized after I read this that the libpng bug was creating page.png's and not N.png, so it looked like all the temporary files were being deleted. Now I understand that there are two types of temporary file: the final images (that get put into the eBook) and the intermediate files getting to that image. I hereby recind my ticket.

I have already responded and resolved your ticket; to both our satisifaction it would seem.

You're welcome. Glad to help. Sorry I wasn't clear about that.... I was testing on the Mac. That being said, if a windows person had an old version of libpng, then I suspect they might have a similar problem.

So does PDFRead 1.8.2 (minus the GUI) work on a Mac now? If so, did you have to do anything, other than normal, to get it working?

I do have a lingering 'bug' where several images are converted and one of those images mysteriously does not appear in the final ebook created. Now I know what the culprit could be. The image gets processed, but then (silently) doesn't get created. Sounds like your original problem!

[donovand]

Originally Posted by nrapallo

I have already responded and resolved your ticket; to both our satisifaction it would seem.



So does PDFRead 1.8.2 (minus the GUI) work on a Mac now? If so, did you have to do anything, other than normal, to get it working?

I do have a lingering 'bug' where several images are converted and one of those images mysteriously does not appear in the final ebook created. Now I know what the culprit could be. The image gets processed, but then (silently) doesn't get created. Sounds like your original problem!

I would say yes, PDFRead 1.8.2 works on the Mac, once you make sure pngnq works. Other than that, I didn't have to do anything else (other than follow the mac instructions for previous versions). I haven't noticed the missing page problem myself, but I have only done a few small tests at the moment. If you have a pdf that fails consistently and you would like me to check it on the mac, then let me know.

[nrapallo]

Originally Posted by donovand

I would say yes, PDFRead 1.8.2 works on the Mac, once you make sure pngnq works. Other than that, I didn't have to do anything else (other than follow the mac instructions for previous versions).

Great information for those using Mac OS!

I haven't noticed the missing page problem myself, but I have only done a few small tests at the moment. If you have a pdf that fails consistently and you would like me to check it on the mac, then let me know.

Actually, it wasn't a pdf but an early test of the 'imglist' input format. I basically tried to display some book covers, but could not get one of them to convert. I am attaching the zipped test file so that you can try to see if your Mac OS counterparts do a better job of converting it.

BTW, it is Cover05.jpg that mysteriously looks like it is processed, but doesn't show up in the resulting ebook. Does it happen to you too?

p.s. these were random book covers and does not indicate my reading preference

[nrapallo]

Originally Posted by nrapallo

The latest source code is up at the PDFRead Dev Hub here.

I will now add the source to post#1 for easy access for all.

The Windows GUI and Installer is NOT mac-friendly, but the source code is python which can be made to work on Mac OS X using the detailed installation instructions in the manual (index.html). For further information, read PDFRead on Mac OS X by sammykrupa

Otherwise, if you can run Windows emulation on your mac, then that would be the route to take (especially if creating .imp formats).

Originally Posted by donovand

FYI an .dmg installer for a libpng that works is here

Originally Posted by donovand

I would say yes, PDFRead 1.8.2 works on the Mac, once you make sure pngnq works. Other than that, I didn't have to do anything else (other than follow the mac instructions for previous versions). I haven't noticed the missing page problem myself, but I have only done a few small tests at the moment. If you have a pdf that fails consistently and you would like me to check it on the mac, then let me know.

Per the above, PDFRead 1.8.2 can be made to work on Mac OS X.

Thanks go out to sammykrupa and donovand for discovering this!

[donovand]

Originally Posted by nrapallo

Great information for those using Mac OS!



Actually, it wasn't a pdf but an early test of the 'imglist' input format. I basically tried to display some book covers, but could not get one of them to convert. I am attaching the zipped test file so that you can try to see if your Mac OS counterparts do a better job of converting it.

BTW, it is Cover05.jpg that mysteriously looks like it is processed, but doesn't show up in the resulting ebook. Does it happen to you too?

p.s. these were random book covers and does not indicate my reading preference

Weirdness. I get the same result. It just doesn't seem to like that image for some reason.

Also, I'm finding that the even pages for the prs505 profile (default is landscape rotation) are getting stretched out. Is there some way to fix this with settings? I turned off cropping, and that seems to help a little, but I suspect it has to do with where the pages are being split.

[nrapallo]

Originally Posted by donovand

Weirdness. I get the same result. It just doesn't seem to like that image for some reason.

Yes, weird. I tried updating the pngnp.exe executable and the libpng13.dll, but could not get it to convert! Oh well, I hope this doesn't show up in normal conversions.

Also, I'm finding that the even pages for the prs505 profile (default is landscape rotation) are getting stretched out. Is there some way to fix this with settings? I turned off cropping, and that seems to help a little, but I suspect it has to do with where the pages are being split.

If you use the 'debug' option to leave behind the temp folder, you will notice that the resulting .png's all retain the proper aspect ratio (i.e. are not stretched), but then the resulting .lrf is stretched. I noticed this when I uploaded the same ebook in multiple formats here.

I think the problem is in the pylrs code written by Mike Higgins (Falstaff) or how the pylrs code is interfaced from the output.py module in PDFRead.

About where the split occurs for the even page being stretch, I don't think that is the cause. Try the 'Portrait-full' layout mode and you will find the same thing with just one image. It's stretched!

Weird squared!