PDFRead 1.8.2 released!

[AnthonyPaulO]

Hi!

I like that it opens up the explorer shell, pretty nice, it sure woke me up lol!

As far as a white png being generated from the pdf (bug), this wasn't the case... I checked the generated png's and nothing, they were fine, no blanks. Also, it's interesting that when I load it up in the mobi-reader the blank pages don't appear, it displays just fine... only inserts blanks on the Kindle 2.

Regarding unpaper, I checked out some other unpaper options like pre-wipe, post-size, and no border...

--pre-wipe is a problem to use because you have to specify a region (or multiple regions) in absolute pixels that's not relative to the edges so it would be a real pain to have to do that for every pdf. It's already somewhat of a pain to specify relative pixels for the unique margins of every different PDF file but I think we can live with that.

--post-size - not sure what happened here, don't recall exactly what it was but the gist of it is that I tried the setting a few times and the first time the image quality was pretty bad, fonts were extra big and bleeding, so I switched off the image dilation and that worked but I didn't see any difference in margins so I stopped playing with it.

--no-border wasn't good for me in conjunction with the --pre-border settings because it negated it for some reason, even though --pre-border isn't a border, so I don't know what's going on here. In any case, no need for it.

I sent you an email with the files so you can fool around with them.

Regards,

Anthony

[nrapallo]

Originally Posted by nrapallo

The .jpg quality is currently poor due to Mobiperl's desire to downgrade the images to the 63K Palm limitation. I really should fix that!

OK, I really don't like the .jpg quality compromise imposed by Mobiperl's html2mobi, so now, my modified copy of html2mobi reduces the .jpg quality only if the size is less than 61000*3 (= 183k) instead of just 61000.

It's a hack that may render the .prc unreadable on Palm PDA's or even the Cybook Gen 3. In those cases, use mobi2mobi with the --gen3imagefix switch as inducated in post #1 above.

If you need this functionality for the .prc generation (AnthonyPaulO - hint, hint), overwrite the current NRhtml2mobi.exe in the bin directory of the PDFRead install directory with the contents of the below zip. You won't be disappointed.

EDIT: This updated NRhtml2mobi.exe (based on Mobiperl v0.0.41) is now available here and no longer attached here!

I attached a test.prc without .jpg quality reduction AND showing how landscape-half doesn't interfere with readability when sentences are split in the middle i.e. the overlap helps avoid this!

[AnthonyPaulO]

Hi!

I replaced the exe in my bin directory and had no issues, though I can't see any difference in the resulting output (perhaps they don't apply to my case) but then again I'm in a dark room viewing it by the light of my laptop screen.

After fooling around with landscape mode, there's still something about it that makes me prefer portrait. I also noticed that with the increased number of pages (due to landscape halving the pages) I get double the blank pages as well.

The blanks are driving me nuts lol! So in order to get to the bottom of this, I've tried using different readers to see whether they did the same thing. Stanza pooped out when I loaded the file, would only display the first page and it seems to think that it's a one-page only ebook. MobiReader worked great, no blank pages inserted anywhere, but there was a page where it merged two pages into one for some reason (check the attachment). My Kindle 2 shows the auto-generated TOC just fine, but then I press next-page and poof! blank page. It seems that a blank page is inserted every two pages (Nick : I didn't expect this to happen on the page after the TOC though since the TOC isn't an image like the rest of the ebook and my assumption had been that this blank-page bug is somehow associated to these images. Maybe something is being placed at the beginning of every other image? Perhaps by focusing on this part of the .prc generation process -- right after TOC up to the first page -- we might notice something that could be triggering this blank-page business.)

So now I'm on a crusade to figure out what the heck is going on with these blank pages. Is there some metadata in the generated .prc file that's making Mobireader wrap two pages into one? A page-break or equiv that's making Kindle insert a blank page every two pages? Or maybe the implementation of the readers are buggy (ie. MobiReader, Kindle, Stanza, etc...)? So I guess I should dig deeper but looking at the perl code for Html2Mobi is making me dizzy since I don't know perl. I would fire off an email to the Kindle dev team but before I do I just want to make sure it's a Kindle issue. Anybody else out there experiencing this kind of behavior after converting their PDF's?

Nick : You know more about the process than anyone here, would you have some insight into where to look for the cause of the blank page insertion?

Regards,

Anthony

[nrapallo]

Originally Posted by AnthonyPaulO

Hi!

I replaced the exe in my bin directory and had no issues, though I can't see any difference in the resulting output (perhaps they don't apply to my case) but then again I'm in a dark room viewing it by the light of my laptop screen.

The new .exe should create larger more crisper .jpgs than the previous NRhtml2mobi.exe.

After fooling around with landscape mode, there's still something about it that makes me prefer portrait. I also noticed that with the increased number of pages (due to landscape halving the pages) I get double the blank pages as well.

This shouldn't happen with any mode; perhaps the screen size needs to be changed. Try reducing it by one or two pixels each direction and seeing if that "cures" it.

The blanks are driving me nuts lol! So in order to get to the bottom of this, I've tried using different readers to see whether they did the same thing. Stanza pooped out when I loaded the file, would only display the first page and it seems to think that it's a one-page only ebook. MobiReader worked great, no blank pages inserted anywhere, but there was a page where it merged two pages into one for some reason (check the attachment). My Kindle 2 shows the auto-generated TOC just fine, but then I press next-page and poof! blank page. It seems that a blank page is inserted every two pages (Nick : I didn't expect this to happen on the page after the TOC though since the TOC isn't an image like the rest of the ebook and my assumption had been that this blank-page bug is somehow associated to these images. Maybe something is being placed at the beginning of every other image? Perhaps by focusing on this part of the .prc generation process -- right after TOC up to the first page -- we might notice something that could be triggering this blank-page business.)

So now I'm on a crusade to figure out what the heck is going on with these blank pages. Is there some metadata in the generated .prc file that's making Mobireader wrap two pages into one? A page-break or equiv that's making Kindle insert a blank page every two pages? Or maybe the implementation of the readers are buggy (ie. MobiReader, Kindle, Stanza, etc...)? So I guess I should dig deeper but looking at the perl code for Html2Mobi is making me dizzy since I don't know perl. I would fire off an email to the Kindle dev team but before I do I just want to make sure it's a Kindle issue. Anybody else out there experiencing this kind of behavior after converting their PDF's?

Nick : You know more about the process than anyone here, would you have some insight into where to look for the cause of the blank page insertion?

Regards,

Anthony

OK, there are no page-breaks between pages/images. I use the max. screen size for images, so when two pages display on one, then both of those images combined are less than the height of just one page. It could happen at the end of a chapter, if the page is not "full", but it's not by design.

FYI, this is a sample of the html produced by PDFRead and used to generate the .prc using my modified NRhtml2mobi.exe:

<html>
 <head>
  <title>1</title>
  <meta name="author"    content="2">
  <meta name="genre"     content="3">
  <meta name="category"  content="3">
  <meta name="generator" content="PDFRead v1.8.2b">
  <style>p {text-indent:0em; margin-left:0em; margin-right:0em; margin-top:0em; margin-bottom:0em; text-align:right}</style>
 </head>
 <body>
  <h2 align="center">1</h2>
  <h2 align="center">by</h2>
  <h2 align="center">2</h2>
  
  <p style="page-break-before: always">
  <mbp:pagebreak />
  <p><a name="img0"></a><img src="0.png"/></p>
  <p><a name="img1"></a><img src="1.png"/></p>
  <p><a name="img2"></a><img src="2.png"/></p>
  <p><a name="img3"></a><img src="3.png"/></p>
 </body>
</html>

I can't see why/where the blank pages would/could be there. Could you try uploading you resulting .prc here for others with a Kindle 1 or 2 to try and reproduce that behaviour.

More investigation will lead to the culprit, but sorry, I don't have any Mobipocket .prc/.mobi hardware reader to test this stuff on and further investigate.

[AnthonyPaulO]

Hi!

Nick : I've done as you asked and reduced the resolution to see if the blank pages would stop appearing. I reduced it from 600x800 to default, no difference either in the size of the output (I measured the same line of text with a ruler on my Kindle) or blank pages. Reduced further to 500x700, still no difference in either, which is strange... I would have imagined the output would look smaller. Reduced to 400x600, still no difference. Reduced to 300x500, no difference but I can see the quality is deteriorating... I probably didn't notice this before because of the low-light here. 200x400 and we see a difference in both the size (quality is bad of course) and for the first time, no blank pages. I must confess that at this point I'm confused as to what the V/H res options are doing.

I've attached the .prc files in a zip file, perhaps some people out there can test the default.prc file on their readers and check to see if they see blank pages as well.

Regards,

Anthony

[nrapallo]

Originally Posted by AnthonyPaulO

Hi!

Nick : I've done as you asked and reduced the resolution to see if the blank pages would stop appearing. I reduced it from 600x800 to default,

No, the default is the usable max screen dimensions. Horizontal resolution (Hres) is 520 and Vertical resolution (Vres) is 640 per the Mobipocket Profiles I listed here or in post #1 above. I opened up your 400-600.prc and exploded it using my Mobi2IMP just to see the .html and images (see attached .zip). I saw that all your images were less than 600 pixels tall and the html doesn't look strange. This is what I got using Mobi2IMP:

<html><head><meta http-equiv="Content-Type" content="text/html; charset=windows-1252" /><title>400-600</title><meta content="Adam Nathan" name="author" /><meta content="Programming" name="genre" /><meta content="Programming" name="category" /><meta content="PDFRead v1.8.2" name="generator" /><style>p {text-indent:0em; margin-left:0em; margin-right:0em; margin-top:0em; margin-bottom:0em; text-align:none}</style><STYLE type="text/css">p {text-indent:0em; padding-top:0em; padding-bottom:1em} header {display:none; display:oeb-page-head}</STYLE></head>
<BODY style="margin-left:2%; margin-right:2%; text-align:justify">
<h2 align="center">400-600</h2><h2 align="center">by</h2><h2 align="center">Adam Nathan</h2><ul><li><a href="#0000000641">A Look at the Past</a><li><a href="#0000000687">Enter WPF</a></ul>

<p style="page-break-before: always">

<p style="page-break-before:always"> 
<p><a name="0000000641"></a><a name="img0"></a><img src="record-2.JPG" />
<p><a name="0000000687"></a><a name="img1"></a><img src="record-3.JPG" />
<p><a name="img2"></a><img src="record-4.JPG" />
<p><a name="img3"></a><img src="record-5.JPG" />
<p><a name="img4"></a><img src="record-6.JPG" />
</body></html>

no difference either in the size of the output (I measured the same line of text with a ruler on my Kindle) or blank pages. Reduced further to 500x700, still no difference in either, which is strange... I would have imagined the output would look smaller. Reduced to 400x600, still no difference. Reduced to 300x500, no difference but I can see the quality is deteriorating... I probably didn't notice this before because of the low-light here. 200x400 and we see a difference in both the size (quality is bad of course) and for the first time, no blank pages. I must confess that at this point I'm confused as to what the V/H res options are doing.

See above re: Hres and Vres as they are entered in the GUI as Size: H: and V:.

I've attached the .prc files in a zip file, perhaps some people out there can test the default.prc file on their readers and check to see if they see blank pages as well.

Regards,

Anthony

This didn't help me find anything special; perhaps it's a Kindle 2 issue. Try using H: 520 and V: 640 and use that "debug" trick to leave the exploded temp directory with the .html and images. Try using Mobipocket Creator or Calibre to create a new .prc and see if that one works! That, to me, could indicate that Mobiperl's code may be incompatible with the Kindle 2!

[AnthonyPaulO]

Hi!

Nick : Sorry for the confusion, what I meant was that I rendered at 600x800, then blanked out the H/V res text-boxes so that it would render at the default, then 500x700, etc...

I checked the html, I don't see the reason for it either. As for incompatability with Kindle 2, I hope not! Maybe some readers would shed some light on this by testing the default.prc on their Kindle devices (both 1 and 2) and tell me if they see any blank pages.

Will be digging deeper tonight. Thanks for the help so far Nick!

Regards,

Anthony

[AnthonyPaulO]

Hi!

Nick : I'm writing an article on media conversions for the Kindle and would like to devote some of it to your PDFRead application if that's okay with you. I was wondering something though... would it be possible to expand the program a bit so that it would take HTML files as well? In other words, since PDFRead is essentially a two step process (or three with unpaper) where you 1) extract HTML from PDF and 2) create .prc file from HTML, would it be possible to allow for people who already have the HTML (extracted from, let's say, a .CHM file or saved via a web-browser) and have them skip step one and perform only step two? This should get double the audience for your app!

Regards,

Anthony

[nrapallo]

Originally Posted by AnthonyPaulO

Hi!

Nick : I'm writing an article on media conversions for the Kindle and would like to devote some of it to your PDFRead application if that's okay with you.

That's fine with me!

However, please review the first post in this thread where I refer to the previous version's thread, PDFRead 1.7 released, as that was where this software "matured". I enhanced a good thing, with PDFRead 1.8, because I especially wanted to get it to allow colour images to be processed and retained. ashkulz had already written the colour support routines but never ended up releasing his code. We had exchanged some emails about adding colour that could be used by the REB 1200 (his ebook reader and mine). That's where I got involved, in fact, before I joined mobileread. It was ashkulz who pointed me this way in late 2007...

I was wondering something though... would it be possible to expand the program a bit so that it would take HTML files as well? In other words, since PDFRead is essentially a two step process (or three with unpaper) where you 1) extract HTML from PDF and 2) create .prc file from HTML, would it be possible to allow for people who already have the HTML (extracted from, let's say, a .CHM file or saved via a web-browser) and have them skip step one and perform only step two? This should get double the audience for your app!

Regards,

Anthony

As far as I know, there is no perfect .pdf to .html/.txt routine for all types of .pdf ebooks (Word/text based or scanned images). Mobipocket Creator's import function handles Word/text based .pdfs quite well, but not .pdf's containing just a bunch of scanned book page images. The only option to get those converted to .html/.txt is OCR.

PDFRead, is an alternative method for (reading on small screen ebook readers) the latter type of .pdf's (scanned images). Everything gets converted to images and .html is only used to bind them together sequentially to create an ebook. There is no text/OCR conversion done.

CHM are compiled html and are easily exploded in near perfect .html requiring only minor TOC/index editing to be done. They are not image based, but text based.

PDFRead specifically helps read, in ebook form, all image based .pdf/.djvu/.jpg/etc... documents. It's very focused in its intent and purpose. I wouldn't want it to do other types of conversion, especially when you have the grand-daddy of all converters, Calibre, being so well developed and maintained right here at mobileread.com.

I also have written/maintained software that converts .prc/.mobi/.pdb/.lit to my reader's .imp format. Any text/chm/html ebooks would be converted using these software packages (Mobi2IMP/Lit2SB) while all image based ebooks would be converted by PDFRead.

Does that make some sense?

[AnthonyPaulO]

Hi!

Okay, I see what you're saying, and you're right... PDFRead makes absolute sense for scanned images while MobiCreator is best suited for text based content. I'll have to take that into account for my article. You mention Calibre, what is it? There doesn't seem to be much of a "What is Calibre" section on their website, but from what I see it's an ebook management system, is that right? There are 3 output format, EPUB, LRF, and MOBI... is MOBI and PRC interchangeable? In other words, can I take a file and rename it from .mobi to .prc and it should work, and vice-versa?

Regards,

Anthony

[nrapallo]

Originally Posted by AnthonyPaulO

Hi!

Okay, I see what you're saying, and you're right... PDFRead makes absolute sense for scanned images while MobiCreator is best suited for text based content. I'll have to take that into account for my article. You mention Calibre, what is it? There doesn't seem to be much of a "What is Calibre" section on their website, but from what I see it's an ebook management system, is that right?

Check the Calibre dedicated forum here on mobileread.com. It is also an ebook creation/conversion system.

There are 3 output format, EPUB, LRF, and MOBI... is MOBI and PRC interchangeable? In other words, can I take a file and rename it from .mobi to .prc and it should work, and vice-versa?

Regards,

Anthony

Yes, .mobi is the new .prc and they are "renameable"/interchangeable.

[Thorkin]

I'm having a strange problem and I can't figure out the cause. I'm trying to convert this pdf book into an ebook for my kindle. Problem is, it seems to be refusing to generate a .prc file; it goes through the entire process of generating the individual pages in the temp folder, then hangs for a bit at "creating mobileread ebook," then the temp folder pops open with all the individual images and an html file linking them, but no .prc file is ever formed. Any idea what might be causing this? Thanks!

[nrapallo]

Originally Posted by Thorkin

I'm having a strange problem and I can't figure out the cause. I'm trying to convert this pdf book into an ebook for my kindle. Problem is, it seems to be refusing to generate a .prc file; it goes through the entire process of generating the individual pages in the temp folder, then hangs for a bit at "creating mobileread ebook," then the temp folder pops open with all the individual images and an html file linking them, but no .prc file is ever formed. Any idea what might be causing this? Thanks!

That signifies to me that there is an error encountered during the creation of the .prc due to a number of reasons, but most likely linked to memory issues or .pdf encoding. See if you can create a .prc from the resulting .html and images using Mobipocket Creator or Calibre.

Try a range of pages, like 1 to 10, and see if that works using PDFRead's internal .prc creation.

Also, try converting the .djvu file instead. I tested it with both and there were some missing pages when I used the .pdf file (some of the first 10 pages didn't come through).

[astromusic]

Nick, I am having the exact same problem. I get the individual png images, and the html, but no PRC being created.

Do I need to have ebook Publisher installed, even for converting to PRC? The top post implies that I need it only for some other formats. Could that be the problem?

BTW, I tried just a couple of pages, so that should not have been the issue.

EDIT: The same document, when tried in Landscape-half mode produced a PRC just fine. Seems to be some problem in the Portrait mode. The Portrait mode was not too legible anyway, so this is not an issue for me.

[nrapallo]

Originally Posted by astromusic

Nick, I am having the exact same problem. I get the individual png images, and the html, but no PRC being created.

Do I need to have ebook Publisher installed, even for converting to PRC? The top post implies that I need it only for some other formats. Could that be the problem?

BTW, I tried just a couple of pages, so that should not have been the issue.

EDIT: The same document, when tried in Landscape-half mode produced a PRC just fine. Seems to be some problem in the Portrait mode. The Portrait mode was not too legible anyway, so this is not an issue for me.

Thanks for your update.

Originally, the ETI eBook Publisher was used to create the .opf that was utlimately used to generate the .prc using Mobiperl. However, I changed that by using html2mobi instead of opf2mobi (so as to by-pass the need for eBook Publisher).

Glad to hear IT wasn't the cause!