PRS-500 HTML2LRF

[kovidgoyal]

Another problem I'm afraid

java -jar ./BBeBook.jar Test.xml
Error parsing metadata: internal error in parseEpilog
org.xmlpull.v1.XmlPullParserException: internal error in parseEpilog
        at org.xmlpull.mxp1.MXParser.parseEpilog(MXParser.java:1655)
        at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1393)
        at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)
        at BBeBook.parseConfig(BBeBook.java:729)
        at BBeBook.makeBookFromXmlConfig(BBeBook.java:665)
        at BBeBook.makeBook(BBeBook.java:604)
        at BBeBook.main(BBeBook.java:292)
No <Output> in config file.

cat Test.xml
<File>/home/kovid/documents/ebooks/temp/Test.html</File>
<Output>/home/kovid/documents/ebooks/temp/Test.lrf</Output>
<Icon>/home/kovid/work/prs-500/libprs500/lrf/cover.jpg</Icon>
<Title>Test.html</Title>
<Author>Unknown</Author>
<Label>Test.html</Label>
<BookID>20e4e18dfae3d1b38df3bce24863b74d</BookID>

EDIT: Nevermind, it just needed to be wrapped in a document element

[scotty1024]

Originally Posted by kovidgoyal

Is this intentional? Or will it be fixed in a future version. I'm asking all these questions because I'm planning to integrate BBeBook into libprs500 and I need a stable commandline interface.

I'll be replacing the command line processor shortly.

On the Mac/Windows you can access Test.xml as test.xml.

[kovidgoyal]

Thanks, that'll be good. You may want to use the GNU command line conventions.

-c arg
--long-command=arg

http://www.gnu.org/prep/standards/st...ine-Interfaces

[kovidgoyal]

Are you planning to add support for non GIF thumbnails?

[scotty1024]

I've decoded how to do non-GIF thumbnails but found they generally produced the smallest icon so the software resizes and converts most formats to GIF.

If you can't feed it a 1024x768 JPEG and have it convert that into a LRF GIF icon please let me know.

[kovidgoyal]

Hmm if i feed it a JFIF (.jpg) file via the <Icon> directive, it sets the thumbnail_type bytes (2 bytes at 0x4e) to 0x14 (i.e. GIF) but the actual thumbnail data has a JFIF header and is identified as a JPEG by imagemagick.

[scotty1024]

Originally Posted by kovidgoyal

Thanks, that'll be good. You may want to use the GNU command line conventions.

-c arg
--long-command=arg

http://www.gnu.org/prep/standards/st...ine-Interfaces

I appreciate your enthusiasm and your taking the time on all this but yes, I do grok GNU command line processing. My personal work flow uses the ebook.xml path as I have an OEBF convertor as well. You've given me a lot of feedback on what you need, it is all reasonable and I will be addressing it shortly.

[kovidgoyal]

Thanks for taking the time to address my concerns. I just thought you may not be used to the GNU conventions, since BBeBook seems to have been developed on a non GNU platform. At any rate there's no rush as with the patch to the command line processor, I can easily use the xml interface in my code.

[scotty1024]

I've been GNU'ing for 21 years now.

[kovidgoyal]

Cool 21 certainly beats my 10...sorry to be such a pest, but here's what seems to be a rather serious bug. The generated LRF file seems to be invalid (Gives an error in the Connect Reader).

java -jar ../BBeBook-0.2.jar leaves.xml

The generated leaves.lrf is different from the original included in the source tarball. The generated one gives an error in the Connect Reader the original does not. The files are attached. Essentially the difference between the files is that in the generated one the toc object id is 0x32 instead of 0x33 and a whole bunch of bytes that were different values in the original are set to 0x32 in the generated version.

If the original leaves.lrf was generated by BBeBook-0.2, I'm at a loss.

[melchioe]

Originally Posted by unkilbeeg

Hmmm. Frustrating. So far I've had no luck in finding a way to create LRF files.

HTML2LRF doesn't seem to work very well under wine, at least not here. It creates an LRF file that contains a title page, but no text. My test file is from a Baen HTML download. Admittedly Baen's HTML is U.G.L.Y. Even after considerable cleanup, however, the resulting LRF file is exactly the same. Empty except for the title page.

I'm operating under Windows and I get the "empty except for title page" issue as well, and I concur that it seems to add another blank page per html file.

I've run gutlrf with success (which calls HTML2LRF to produce the lrf file), but when I use GutenMark to convert text to HTML, the resultant file does
not come out well with HTML2LRF. I was convinced I was doing something wrong, but I'm no longer sure. I do know that the Gutenmarked files display beautifully in both IE and firefox. I've run tidy, and I've split the html into chapters, and banged my head against the wall...

Anyone have any idea of what HTML2LRF is looking for in the html format? I'm thinking there is something missing from both the gutenmark files and the baen files.

-e-

[FangornUK]

What sort of problem are you having with GutenMark & HTML2LRF? Works fine for me on Gutenberg text files with HTML2LRF and even handles those difficult formatted plays. Here's what I do to convert them:

Gutenmark.exe file.txt >new.html

(Using splitboot.pl in my gutlrf.pl scripts)

splitbook.pl -c h1 new.html

HTML2LRF can't handle HTML files above 600k in size so you need to use splitbook.pl to split the files.

P.S. Just a comment on this thread, can the BBeBook discussions go into a different thread? It seems to have taken over this HTML2LRF thread.

[ReadWrite]

java -jar ../BBeBook-0.2.jar leaves.xml
[/code]
The generated leaves.lrf is different from the original included in the source tarball. The generated one gives an error in the Connect Reader the original does not. The files are attached. Essentially the difference between the files is that in the generated one the toc object id is 0x32 instead of 0x33 and a whole bunch of bytes that were different values in the original are set to 0x32 in the generated version.

If the original leaves.lrf was generated by BBeBook-0.2, I'm at a loss.[/QUOTE]

GREAT JOB with the decoding!
Minor bug fix to solve 0x32 problem.
The 0x32 is the id value that is not being updated/incremented.
In BBeBObject.java, line 22; make globalBBeBObject static:

private static short globalBBeBObject = 0x32;// Magic.. Ask Sony why all LRF files start here

Not sure this is the most efficient solution, since statics usually mean sloppy programming, but it is the easiest short-term solution.

Keep up the good work.

[kovidgoyal]

Thats certainly and efficient short term fix! Thanks, now I can add BBeBook to libprs500. Hopefully scott1024 will fix it properly once he's done refactoring.

[John Wheater]

Originally Posted by scotty1024

I call this application BBeBook. It is far from perfect/complete in its understanding of LRF, but It is written 100% in Java and needs no dll's from Sony. It is Unicode clean.

Scotty1K - could you give a chap a clue how to use this package? I'm running Windows XP - is that OK?