Thread: PRS-500 LRF ObjectInfo format
View Single Post
Old 01-06-2007, 01:18 PM   #8
cmumford
Connoisseur
cmumford began at the beginning.
 
cmumford's Avatar
 
Posts: 69
Karma: 34
Join Date: Dec 2006
Location: Dallas, TX
Device: PRS-500
Quote:
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.
cmumford is offline   Reply With Quote