Quote:
Originally Posted by kovidgoyal
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.