Does anyone have any details for how the layout data is stored in \database\cache\media.xml under the xdbLite/records/xs1:text/xs1:layouts/xs1:layout nodes?

I have a little pet project that would benefit from being able to read this information on the desktop, but before I go digging into this mime encoded blob and see how it's crafted, I thought I'd ask if someone else has a clue how the data is stored.

Thanks!

It's pretty complex and it's specific to a file format (i.e., txt, rtf, lrf all use it differently). Basically it describes the position in file at which every page starts. Naturally, it depends on the actual font and rendering algorithm used. Even a slight disrepancy can lead to the "missing lines" problem that many people had when replacing fonts on the device but forgetting to replace them on the PC.
If you still want to know the details I will try to describe them. I don't really see how it will be useful to you since you'll need to reproduce the LRF rendering very closely to how Reader does it and that's not trivial...

It's pretty complex and it's specific to a file format (i.e., txt, rtf, lrf all use it differently). Basically it describes the position in file at which every page starts. Naturally, it depends on the actual font and rendering algorithm used. Even a slight disrepancy can lead to the "missing lines" problem that many people had when replacing fonts on the device but forgetting to replace them on the PC.
If you still want to know the details I will try to describe them. I don't really see how it will be useful to you since you'll need to reproduce the LRF rendering very closely to how Reader does it and that's not trivial...

Yeah, I assumed it wouldn't be enough to recreate the output. Basically, in my project it would be useful if I could get at "page x starts at y bytes into the file".

Any hints as to the format you could give would be much appreciated. If it makes your life any easier, I really only care about the lrf format.

It's pretty complex and it's specific to a file format (i.e., txt, rtf, lrf all use it differently). Basically it describes the position in file at which every page starts. Naturally, it depends on the actual font and rendering algorithm used. Even a slight disrepancy can lead to the "missing lines" problem that many people had when replacing fonts on the device but forgetting to replace them on the PC.
If you still want to know the details I will try to describe them. I don't really see how it will be useful to you since you'll need to reproduce the LRF rendering very closely to how Reader does it and that's not trivial...
A much more interesting goal would be to understand enough about what's in there to let calibre fetch the information back for books it has previously downloaded to the reader. That way, those of us with non-Windows boxen would only have to eat the format-time once on the reader. Calibre could store it with the book and re-load it on subsequent downloads.

Now that would be spiffy! :2thumbsup

In fact, if someone out there has enough information on the subject, I'll be happy to file an enhancement request.

Xenophon

A much more interesting goal would be to understand enough about what's in there to let calibre fetch the information back for books it has previously downloaded to the reader. That way, those of us with non-Windows boxen would only have to eat the format-time once on the reader. Calibre could store it with the book and re-load it on subsequent downloads.
Now that would be spiffy! :2thumbsup
In fact, if someone out there has enough information on the subject, I'll be happy to file an enhancement request.

For that, storing the binary blob should be enough I think.

A much more interesting goal would be to understand enough about what's in there to let calibre fetch the information back for books it has previously downloaded to the reader. That way, those of us with non-Windows boxen would only have to eat the format-time once on the reader. Calibre could store it with the book and re-load it on subsequent downloads.

Now that would be spiffy! :2thumbsup

In fact, if someone out there has enough information on the subject, I'll be happy to file an enhancement request.

Xenophon

Do you often download the same book to your reader multiple times?

Do you often download the same book to your reader multiple times?
Yes. I shuffle what's on the reader fairly regularly, especially since I've gotten tired of waiting for the reader to scan its way through a GB or so on an SD card. Also, the reader loses track of that data lots of times when it crashes, so I'd like to be able to put the relevant bits into the layout nodes again rather than eat yet another re-format. And it would also help in multi-reader households like mine -- lots of stuff that I've read that my wife hasn't read yet. This could save her waiting for the format too.

Also, I re-read favorites a fair bit, because my main sources of fiction don't put out enough new content (that I can afford) to keep me in fresh reading material.

Finally, we could (somehow) store the information with the lrf files here on MobileRead too. That would benefit everyone who doesn't use Windows, by letting us avoid the first re-format as well.

(OK, I know, it wouldn't help anyone who changes font sizes or sticks a different set of fonts on their reader. But still...)

Xenophon
'

Hmm, well saving the layout formats is certainly possible. But it would be way down my TODO list :)

If you still want to know the details I will try to describe them. I don't really see how it will be useful to you since you'll need to reproduce the LRF rendering very closely to how Reader does it and that's not trivial...

Are you still willing to document what you know of the format?

Thanks!

Yes, but not anytime soon, sorry.