View Single Post
Old 10-24-2007, 12:51 PM   #16
jbenny
Addict
jbenny has a complete set of Star Wars action figures.jbenny has a complete set of Star Wars action figures.jbenny has a complete set of Star Wars action figures.jbenny has a complete set of Star Wars action figures.
 
Posts: 323
Karma: 358
Join Date: May 2007
Device: Tablet PC and Nokia N800
Quote:
Originally Posted by kovidgoyal View Post
I don't mean just rendering performance, I also mean pagination performance. I know for example that SONY's LRF layout routine is extremely fragile. I can easily create LRF files that are correct, but cause the reader to reset because it runs out of memory. And LRF is really, really simple compared to HTML.

And pagination takes a hell of along time for larger books. You wont notice this if you use connect, but if you transfer directly to a reader, then the hit is significant. I've often had to wait for upto 15mins for the reader to finish pagination.
If you can borrow a Nokia N800, take a look at the performance of FBReader when paging and displaying any of the ebook formats is supports. I haven't noticed it being slow at all, regardless of book length. I know FBReader doesn't currently support CSS or tables, but still, I've read some very long ebooks with it.

Another example is the trusty old Ebookwise 1150. You can select from two different font sizes on the device and the resulting repagination takes almost no time at all. The older RocketBook supported even more font choices.

I'm not sure what Sony is doing with pagination for the various font sizes, but that would seem to be specific to that format and that hardware. I don't see anything in the OPS spec that mentions anything like this. Now, if a particular hardware vendor decides to do something similar for some reason (I can't see why), that is outside the spec. Perhaps you can elaborate on exactly what is going on when an ebook is repaginated on a Sony and why it is done this way.
jbenny is offline   Reply With Quote