OpenBerg FireFox extension for ePub

[wallcraft]

I had never heard of this until a recent comment by Tamas Simon on a teleread post, but OpenBerg Lector is an e-book reader extension to FireFox that supports .epub. Adobe Digital Editions can display ePub in a browser, but it isn't currently cross-platform like FireFox. So far I have had mixed success (i.e. mostly failures) using this, but I am not convinced that all the problems are with OpenBerg. At a minimum this provides another target for compatibility testing.

[sic]

so we have
- Adobe Digital Editions - based on Webkit
- OpenBerg (in progress) based on Mozilla/Gecko
- dotReader (in progress) based on Mozilla/Gecko

looks like reflow means... HTML

which makes me think... What the heck is all this IDPF standard about?
Why should we restrict ourself not to use flash, JavaScript, embedded comments, whatever in ebooks when they're based on browser technology anyways?

FYI I'm Tamas Simon, alias Sic

[Hadrien]

Originally Posted by wallcraft

I had never heard of this until a recent comment by Tamas Simon on a teleread post, but OpenBerg Lector is an e-book reader extension to FireFox that supports .epub. Adobe Digital Editions can display ePub in a browser, but it isn't currently cross-platform like FireFox. So far I have had mixed success (i.e. mostly failures) using this, but I am not convinced that all the problems are with OpenBerg. At a minimum this provides another target for compatibility testing.

Now that I've fixed my files, OpenBerg works great.
Much much faster than DE. Too bad you don't get a page view, and support for page break instead of a web like view.
Here's the screenshot I uploaded on the other thread: https://www.mobileread.com/forums/att...7&d=1190910224

[kovidgoyal]

Originally Posted by Hadrien

Now that I've fixed my files, OpenBerg works great.
Much much faster than DE. Too bad you don't get a page view, and support for page break instead of a web like view.
Here's the screenshot I uploaded on the other thread: https://www.mobileread.com/forums/att...7&d=1190910224

Its the support for pageviews that makes DE slow. With an inherently reflowable base format like HTML, the viewer has to load the entire document and lay it out before being able to render the first page. I faced the same problem with writing my LRF viewer.

[Hadrien]

Originally Posted by kovidgoyal

Its the support for pageviews that makes DE slow. With an inherently reflowable base format like HTML, the viewer has to load the entire document and lay it out before being able to render the first page. I faced the same problem with writing my LRF viewer.

Yes, once loaded everything is fine. But when you resize the window or change the font size it gets really slow. On VERY long books, this can take dozens of seconds.

I still believe though that the software could be faster... It doesn't take that long to open a LRF file on your Sony the first time. DE is really slow compared to this.

[kovidgoyal]

resizing window/chaging font size means the layout has to be redone. If you load books to the reader via the Connect software the laying out is pre done and cached in the reader's XML database. Also HTML is a much more complex markup language to layout than LRF.

[Hadrien]

Originally Posted by kovidgoyal

resizing window/chaging font size means the layout has to be redone. If you load books to the reader via the Connect software the laying out is pre done and cached in the reader's XML database. Also HTML is a much more complex markup language to layout than LRF.

Yes, more complex because of CSS support too.
Dividing the books into more files might be a solution to avoid a long waiting time on DE, but it also means that it'll take longer when you get from one chapter to another...

[kovidgoyal]

Actually this issue is a big problem. Considering that DE or something like it has to run on an embedded device, the performance penalty is going to be a major issue. That's one of the good things about LRF. Because it's so simple, a renderer that performs reasonably in a embedded context can be written.

Splitting a book into multiple files wont help if you want to have the number of pages in the book displayed, as for that it would have to parse all the files anyway. Ofcourse, if you feel the reader can do without that then the rendering in the existing DE will be fast enough as it wont have to do pre layouting.

The other partial solution is to pre-cache the layout information like the SONY Reader does. But the problem with that is you wont give the user full control over font sizes, since you can only pre-cache for a limited number of font sizes.

[Yoric]

Its the support for pageviews that makes DE slow.

Actually, the next version of OpenBerg Lector will support pageview. We expected to release this version by the end of August but we found a large bug in this feature, so the release was pushed back to whenever we find the time to fix it. That's one of the main problems with 100% volunteer-based projects: real work has to come first.

[Hadrien]

Originally Posted by Yoric

Actually, the next version of OpenBerg Lector will support pageview. We expected to release this version by the end of August but we found a large bug in this feature, so the release was pushed back to whenever we find the time to fix it. That's one of the main problems with 100% volunteer-based projects: real work has to come first.

Ok that's great news indeed... How fast can you render the paginated view for the moment compared to DE ?

[DaleDe]

Originally Posted by Yoric

Actually, the next version of OpenBerg Lector will support pageview. We expected to release this version by the end of August but we found a large bug in this feature, so the release was pushed back to whenever we find the time to fix it. That's one of the main problems with 100% volunteer-based projects: real work has to come first.

Page View enhances the user experience and makes the ebook like a real book. Support for this really needs widow and orphan control set to look and work nice.

page view is a computer hog when it comes to sizing the book which is why mobipocket avoids this. As was pointed out earlier changing fonts can really mess this up. However, I believe a good reader can mitigate the problem. My eb1150 builds two sizes into the original release of the document (using tables mapping the locations I believe) which solves the problem completely unless you want a different sized font.

Personally I think epub generation should precompile a couple of page sizes into the document but a good reader can almost do the same thing. Books are seldom read in one session so when the user starts up the first time there can be a hit while the paging is done but this data should be stored away in a file that also keeps just things as bookmarks and current read location. Then, subsequent startups will be fast since this data is already present. If the user choose to change the font size then there would be a one time hit while the new data was calculated and added to the metadata file. I think this would be a good compromise between user features and performance. The reader should not repaginate for changes to the window size but should allow the user to choose to repaginate (reflow).

Dale

[andym]

Originally Posted by sic

so we have
- Adobe Digital Editions - based on Webkit
- OpenBerg (in progress) based on Mozilla/Gecko
- dotReader (in progress) based on Mozilla/Gecko

looks like reflow means... HTML

which makes me think... What the heck is all this IDPF standard about?
Why should we restrict ourself not to use flash, JavaScript, embedded comments, whatever in ebooks when they're based on browser technology anyways?

FYI I'm Tamas Simon, alias Sic

Erm who says you can't?

[andym]

Yoric

Nice work. Works well on OS X. Looking forward to Rector - though I think it's a shame you aren't calling it Hannibal (as in Hannibal Lector :-)).

What would be great when you get the time would be a way to have an easy way to override the stylesheet settings - especially line-height and margins.

(Oh and I guess a Windows Mobile version is a fantasy?)

[DaleDe]

Originally Posted by wallcraft

I had never heard of this until a recent comment by Tamas Simon on a teleread post, but OpenBerg Lector is an e-book reader extension to FireFox that supports .epub. Adobe Digital Editions can display ePub in a browser, but it isn't currently cross-platform like FireFox. So far I have had mixed success (i.e. mostly failures) using this, but I am not convinced that all the problems are with OpenBerg. At a minimum this provides another target for compatibility testing.

Will openberg run is seamonkey? What kind of installation script does it require?

[Yoric]

Originally Posted by andym

Yoric

Nice work. Works well on OS X. Looking forward to Rector - though I think it's a shame you aren't calling it Hannibal (as in Hannibal Lector :-)).

Thanks

What would be great when you get the time would be a way to have an easy way to override the stylesheet settings - especially line-height and margins.

That's somewhere on the schedule. Actually, for margins, there's some of it already coded in the next version.

(Oh and I guess a Windows Mobile version is a fantasy?)

We had someone working on a Windows Mobile port, but he stopped giving signs of life some time ago. It is possible that Lector will work on Windows Mobile using Minimo, but as we have no Windows Mobile device to test it, that's not a priority. Of course, if a volunteer were to come by and help us with it, the story would be different.