PRS-500 LRF ObjectInfo format

[AndyQ]

I've got BBeB Binder now to handle images (one image only per page) at the moment and I kind of understand the basic layout for this (24 bytes with a int value of 1 followed by and int value of the block id).

However looking at some other books which have text and images withina page, this structure gets increasingly complex and I have no idea what the values mean (plus it seems to differ depending on what type of objects are on the page).

So, does anyone know the format of the LRF ObjectInfo stream, and also what this is used for?

Cheers
Andy

[kovidgoyal]

Have you seen
http://www.sven.de/librie/Librie/LrfFormat

[AndyQ]

I have indeed but it doesn't describe the ObjectInfo object stream format.

I've also looked throught the lrf2lrs code, the LRFParser code, and other OS code and none have a definition of the format. The closest I got was the java based BBeBook code - but whilst I've got it working now (in a rudimentary fashion), some other books I've looked at have much more involved streams which I can't make head nor tail of!

[kovidgoyal]

Hmm 'fraid my knowledge of the LRF format is limited to the header. Are you trying to write an lrf parser and/or conversion tool?

[AndyQ]

Yup, I'm helping with the BBeB Binder tool which converts from HTML/Text to LRF. It can also read LRF and convert that the HTML.

As mentioned above, I've managed to get text and image elements displayed on a page but I'm sure I'm not doing things quite right - or am missing some bits.

I'm also not actually sure what this Object is used for

[kovidgoyal]

Hmm well best of luck. If you want embedded images, I would generate a few simple one page files with embedded images using the librie toolbar and reverse engg from there.

[scotty1024]

Originally Posted by AndyQ

I have indeed but it doesn't describe the ObjectInfo object stream format.

I've also looked throught the lrf2lrs code, the LRFParser code, and other OS code and none have a definition of the format. The closest I got was the java based BBeBook code - but whilst I've got it working now (in a rudimentary fashion), some other books I've looked at have much more involved streams which I can't make head nor tail of!

BBeBook generates fully resize-able LRF files. I haven't analyzed the Sony Reader files to see if it allows more sophistication in reflow. The Librie allowed for very little sophistication.

One helpful key to understanding LRF maybe to understand that LRF is, in its simplest form, binary encoded XML. The XML tags have been parsed and replaced with numbers. The tag attributes are similarly parsed and converted to numbers with encoded values. This makes the LRF file smaller and quicker to parse for an embedded device.

I'm re-factoring BBeBook for 0.3 and it will make this even more clear.

[cmumford]

Originally Posted by scotty1024

BBeBook generates fully resize-able LRF files. I haven't analyzed the Sony Reader files to see if it allows more sophistication in reflow. The Librie allowed for very little sophistication.

One helpful key to understanding LRF maybe to understand that LRF is, in its simplest form, binary encoded XML. The XML tags have been parsed and replaced with numbers. The tag attributes are similarly parsed and converted to numbers with encoded values. This makes the LRF file smaller and quicker to parse for an embedded device.

I'm re-factoring BBeBook for 0.3 and it will make this even more clear.

Hi scotty1024. BBeB Binder was actually based on the source to BBeBook. We started with your BBeBook and BBeBObject classes, and are slowly moving toward our own as our understanding of the format increases.

You were creating two ObjectInfo objects, one that with a PAGE_LAYOUT payload, and another that with a PAGE_NUMBERS payload. The PAGE_NUMBERS payload seems pretty easy to figure out, but the PAGE_LAYOUT payload isn't fully defined. You create it by allocating a 24 byte array, but you only fill in the first 8 bytes, and leave the last 16 bytes all zeros.

From looking at other LRF's it appears that the PAGE_LAYOUT payload contains a uint32 counter value which contains the number of records, followed by that number of 24 byte records - only the first 8 bytes we currently understand. I haven't even tried yet to look at the last 16 bytes yet to see what it contains for other books.

I have found one other book that doesn't seem to fill in the PAGE_LAYOUT payload this way, but I'm wondering if this may be an improperly created eBook. I'm still trying to find out its origin.

[scotty1024]

Originally Posted by cmumford

Hi scotty1024. BBeB Binder was actually based on the source to BBeBook. We started with your BBeBook and BBeBObject classes, and are slowly moving toward our own as our understanding of the format increases.

Is that a royal "our" there?

The other pointers in the PAGE_LAYOUT are of course ignored when set to 0. The other pointers are used to setup the header and footer descriptors. THe Sony Reader seems to handle the header properly in the Sony Store books I've been reading so I may be adding support for it.

[cmumford]

Originally Posted by scotty1024

Is that a royal "our" there?

The other pointers in the PAGE_LAYOUT are of course ignored when set to 0. The other pointers are used to setup the header and footer descriptors. THe Sony Reader seems to handle the header properly in the Sony Store books I've been reading so I may be adding support for it.

We like to think so

No the "we" is Andy and I - want to join the project?

Those 24 bytes don't seem to be a simple array of object ID's from what I can tell. Have you come across any more information somewhere?

[scotty1024]

Sorry, Java is "fun", .Net is "work".

I wrote a non-resize book binder as well and it knows how to do the headers/footers etc... I need to analyze what the Sony Reader does with its books.

[igorsk]

I will try to look into it some time later, but I *think* ObjectInfo is optional. Did you try generating files without it?

[obelix]

Originally Posted by igorsk

I will try to look into it some time later, but I *think* ObjectInfo is optional. Did you try generating files without it?

ObjectInfo is definitely optional. In my Lrs to Lrf parcer ( http://www.msh-tools.com/ebook/MSH_LRSParser.zip ) (which is good for both Librie and Reader and supports resizable lrfs, headers/footers and buttons etc) this object is not used at all. As far as I know XYLogParcel also does not create this object by default.

Look at Lrf2lrs python program (yahoo librie group, or last version at this forum), by roxfan, Igor Skochinsky (aka igorsk): all LRF format is in there.

[igorsk]

Well, not all I skip over some things which are not important for decomilation (like ObjectInfo).

[scotty1024]

My guess would be its optional if you supply something else. I know if I left it out on the Librie the book was unviewable.