LRF output

[kovidgoyal]

Released 0.3.18 which fixes Xenophon's bug, adds support for <blockquote> elements (See text section in updated demo file) and allows control of link recursion.

[Xenophon]

Thanks, Kovid. No more crashes; the converter seems to work fine. I did notice one bit of odd behaviour, however. The resulting lrf files have distinctly different behaviour when it comes to page turning. The lrf file made from the example html source I sent you takes about 10 seconds per page turn on the Reader. Others take the usual one second. But ALL of them take 10+ seconds to page forward onto the page that contains all the links from the ToC!

Any idea what's going on with this? I'd be very interested in an upgrade to html2lrf that makes the Reader happier with these files. Would it help if I also sent you the source for one of the ones that didn't slow down?

Xenophon

[kovidgoyal]

Interestingly, I found that with the grantville gazette, a reset of the reader made the page turns all 1s again. The TOC page turns seem to be simply because the reader can't handle the large number of links. Do you have an LRF file with a large number of links in the TOC that has a quick page turn to the TOC?

One thing that was different about the grantville gazette was the large number of empty <a name> elements throughout the text. These get mapped to empty textblocks by html2lrf. Perhaps the resulting large number of textblocks is what the reader finds hard to handle. I'll look into that.

[kovidgoyal]

I've added a patch to svn that fixes the slowdowns for me. Can you test it and let me know? Thanks. There was also a fix that will cause the TOC elements to link to the page before the actual chapter...this is the correct behavior as per the grantville HTML file. There was a bug in previous verions that caused the TOC links to point to the first page of the chapter.

[Xenophon]

Originally Posted by kovidgoyal

I've added a patch to svn that fixes the slowdowns for me. Can you test it and let me know? Thanks. There was also a fix that will cause the TOC elements to link to the page before the actual chapter...this is the correct behavior as per the grantville HTML file. There was a bug in previous verions that caused the TOC links to point to the first page of the chapter.

I'll give it a try. I should note that I actually thought that having the TOC links point to the first page of the chapter was a good thing rather than a bug. I think that the issue is that the next, prev, contents links that show up as their own page on the Reader are just the top line of the first page of the chapter in a web browser.

I'll let you know if the version in svn fixes the slowdown.

[kovidgoyal]

Originally Posted by Xenophon

I'll give it a try. I should note that I actually thought that having the TOC links point to the first page of the chapter was a good thing rather than a bug. I think that the issue is that the next, prev, contents links that show up as their own page on the Reader are just the top line of the first page of the chapter in a web browser.

It is a good thing for this particular HTML file. However that is because of a poor design choice in the HTML file. It specifies a page-break-before for all H1 elements, thus html2lrf puts in a page break after the first line. Since browsers are not affected by the page-break CSS properties whoever made this file, probably didn't realize the mistake.

[kovidgoyal]

Released v 0.3.19 with support for creating the external TOC (I've reversed my earlier decision not to do this upon further consideration). This version also contains completely reworked code for handling <a name> elements. This code hasn't been as thoroughly tested as the original, so there may be bugs.

[Xenophon]

The svn version does, in fact, fix the slowdown. I'll report the page-break issue to Arnold Bailey (Baen's web guy), and perhaps get a fix from that end, instead. Thanks for the quick turn-around on the fixes.

Xenophon

[kovidgoyal]

Glad to hear it...I read a lot of ebooks converted from HTML so getting this tool shipshape is a high priority for me.

[kovidgoyal]

Released 0.3.20 with bug fixes too numerous to elaborate. An upgrade is highly recommended.

[Xenophon]

For those of you converting Baen html files with html2lrf, here's a little trick that may help.

First, process the original html to remove the anchors for each paragraph that are used to show paragraph numbers on mouse over. Then, remove the "page-break-before:" from the css declaration in each htm file. Then, remove the "onmouseover" entry from each paragraph element in the htm files. Only after all of that should you convert it to an lrf.

The result of these changes is a clean lrf file, with no slow-downs in page changes. In addition, when you open it for the first time on the reader, it only takes about 10 seconds to process (as compared to the minute-or-so needed when you convert the original html). I've created a little sed script that automates all of this. Its contents are:

s/<a id=\"p[0-9]*\" name=\"p[0-9]*\"><\/a>//
s/ onmouseover=\"PNo([0-9]*)\"//
s/page-break-before://

You invoke it with the command-line:

sed -i old -f yoursedfilehere *.htm

from the directory where you've unpacked the sources.

Those of you on non-Unix hosts are on your own for how to do this, but perhaps this'll give you a good start.

Xenophon

[kovidgoyal]

Cool I'll add this to html2lrf as a commandline option so people can use it in windows too. Could you open a bug and attach the sed script so I dont forget.

Thanks.

EDIT: I doubt removing the onmouseover is neccessary since it's essentially ignored by html2lrf

[Dave Berk]

When I try to run the program in Ubuntu Feisty i get:

dave@aurora:~$ prs500 info
Traceback (most recent call last):
  File "/usr/bin/prs500", line 8, in <module>
    load_entry_point('libprs500==0.3.20', 'console_scripts', 'prs500')()
  File "/usr/lib/python2.5/site-packages/libprs500-0.3.20-py2.5.egg/libprs500/cli/main.py", line 235, in main
  File "/usr/lib/python2.5/site-packages/libprs500-0.3.20-py2.5.egg/libprs500/cli/main.py", line 100, in info
  File "/usr/lib/python2.5/site-packages/libprs500-0.3.20-py2.5.egg/libprs500/prs500.py", line 164, in run_session
  File "/usr/lib/python2.5/site-packages/libprs500-0.3.20-py2.5.egg/libprs500/prs500.py", line 260, in open
libprs500.errors.DeviceBusy: Device is in use by another application:
Underlying error:Failed to set device configuration to: 2. Error code: -1

But the only applications I have open are a terminal (to run prs500) and opera browser..
Any help?

[allovertheglobe]

Originally Posted by simple dave

When I try to run the program in Ubuntu Feisty i get:

dave@aurora:~$ prs500 info
Traceback (most recent call last):
<snip>
libprs500.errors.DeviceBusy: Device is in use by another application:
Underlying error:Failed to set device configuration to: 2. Error code: -1

But the only applications I have open are a terminal (to run prs500) and opera browser..
Any help?

Had the same problem, most likely a permissions issue, try:
sudo prs500 info
(Using SUDO will require you to enter your password once for that session)

[allovertheglobe]

First, Thanks for html2lrf!

Second, is there some sort of simple, comprehensive feature list of the supported HTML anywhere? I couldn't find one on the website. I plan on writing a little program that outputs HTML files, and I want to be sure I would be able to upload that result to the PRS500. For instance which version of (X)HTML? CSS support? Anchor support? Image support, what formatting works? etc.

Any pointers would be appreciated to cut down the trial-and-error to a minimum...

Tia,
P.

(BTW, Kovid, my browser keeps having an issue with your site's certificate: "Website certified by an unknown Authority"... Could not verify this certificate for unknown reasons)
Edit: Nevermind, just went through it again and saw that you issued it yourself. No problem. Noticed you're a local of the greater LA area like myself )