What is EPUB all about?

[lizardcry]

Can someone point me to a resource / link that explains the benefits of EPUB versus Sony's lrf format, or otherwise just plain gets me up to speed on these formats. Much obliged.

[Slite]

Originally Posted by lizardcry

Can someone point me to a resource / link that explains the benefits of EPUB versus Sony's lrf format, or otherwise just plain gets me up to speed on these formats. Much obliged.

Check out the excellent Wikipages available here on a multitude of different subjects about and around e-books and readers:

Here is a link to the ePUB format part of it:

https://wiki.mobileread.com/wiki/EPUB

[Hadrien]

EPUB is an industry standard and an open standard, while LRF is a proprietary format.
Compared to the other reflowable formats, EPUB is more advanced, supporting CSS stylesheets, SVG images, a real multi-level table of contents etc...
But the most important point is that EPUB will be used at an industrial level by the publishing industry and available across a large selection of devices.
Currently, it's still early days for the format, and the number of devices/reading systems that support EPUB are limited, but it'll change in the upcoming months.

Take a look at our EPUB help page on Feedbooks: http://www.feedbooks.com/help/epub
Or at the official specs on the IDPF website: http://idpf.org

[pepak]

If I may modify the original question a bit: I create all books myself (right from buying the paper book to scan it). Once done, I store them in HTML format. For the purpose of reading them on my Sony Reader, I wrote a series of utilities (which mostly use Calibre to do the dirty job) to convert them. It makes little difference for me whether I convert to LRF or to EPUB.

In this situation, and with today's hardware (I use PRS-505) - does EPUB have any distinct advantage over LRF?

I mean, I chose LRF months ago because the reader rendered it a lot faster than PDF or RTF, because it had perfect support for UTF-8 (I use Eastern European charset) etc. Should I switch to EPUB now, what kind of advantages can I expect from it?

[Hadrien]

Originally Posted by pepak

If I may modify the original question a bit: I create all books myself (right from buying the paper book to scan it). Once done, I store them in HTML format. For the purpose of reading them on my Sony Reader, I wrote a series of utilities (which mostly use Calibre to do the dirty job) to convert them. It makes little difference for me whether I convert to LRF or to EPUB.

In this situation, and with today's hardware (I use PRS-505) - does EPUB have any distinct advantage over LRF?

I mean, I chose LRF months ago because the reader rendered it a lot faster than PDF or RTF, because it had perfect support for UTF-8 (I use Eastern European charset) etc. Should I switch to EPUB now, what kind of advantages can I expect from it?

One of the 3 standards in ePub, OPS is basically XHTML+CSS. An ePub file would be much closer to what you already store.
Files in ePub MUST be in UTF-8 actually, and you can embed the font directly inside the file too.

The main advantage is probably the fact that you won't really have to do a lot of format shifting in the upcoming years if you start using ePub rather than LRF. You can also use far more advanced layouts and formatting in ePub thanks to the CSS 2.0 support.

[pepak]

Originally Posted by Hadrien

The main advantage is probably the fact that you won't really have to do a lot of format shifting in the upcoming years if you start using ePub rather than LRF.

Actually, that's doesn't matter to me - the only place where I would put the LRF (or the EPUB) is the Reader itself. The source files would remain in HTML on my computer in either case. If I choose to switch to a new format, I can do it all with just one command.

My uncertainty whether to use LRF or EPUB is mostly about "which format is easier for my device's firmware" - speed of rendering, power consumption, stuff like that. Multilevel TOC would be a point in favor of EPUB, as would be CSS2 support, but not if it meant reduced lifetime on battery or prolonged page turns.

[pilotbob]

Originally Posted by pepak

My uncertainty whether to use LRF or EPUB is mostly about "which format is easier for my device's firmware" - speed of rendering, power consumption, stuff like that.

I would suggest creating the same ebook in both formats and see which works better. Let us know.

BOb

[pepak]

Guess I will stay with LRF. I have just converted a book to EPUB using the default settings of HTML2EPUB, and I am quite disappointed. The speed is pretty good, except that the Reader does not parse the whole file at once - instead it "reformats" the book every time I try to follow a link. Apparently only some parts of my CSS file get interpreted (e.g. blockquotes are beautifuly formatted according to my specs while regular paragraphs are not). It seems images are displayed in full size while in LRF generated from the same HTML file the images are resized to fit the screen. But the most serious issue is that in EPUB, certain national characters are not displayed correctly - but they work perfectly in LRF. It may be that HTML2EPUB incorrectly detects encoding (the incorrect characters seem to be those few which are different in Windows-1250 and ISO-8859-2), I don't know. Still, the poor formatting and very poor performance with links seem like a serious problems with the Reader itself.

[DaleDe]

Originally Posted by pepak

Guess I will stay with LRF. I have just converted a book to EPUB using the default settings of HTML2EPUB, and I am quite disappointed. The speed is pretty good, except that the Reader does not parse the whole file at once - instead it "reformats" the book every time I try to follow a link. Apparently only some parts of my CSS file get interpreted (e.g. blockquotes are beautifuly formatted according to my specs while regular paragraphs are not). It seems images are displayed in full size while in LRF generated from the same HTML file the images are resized to fit the screen. But the most serious issue is that in EPUB, certain national characters are not displayed correctly - but they work perfectly in LRF. It may be that HTML2EPUB incorrectly detects encoding (the incorrect characters seem to be those few which are different in Windows-1250 and ISO-8859-2), I don't know. Still, the poor formatting and very poor performance with links seem like a serious problems with the Reader itself.

Thanks for posting. This is exactly the kind of information that needs to come to light. This is the first release of the ePUB product and it is clear that this version is not done yet. This kind of feedback is needed for all of us to see a better product in the future. You should provide the feedback to adobe in more detail as to exactly what is wrong as they are the authors of this software.

Dale

[vivaldirules]

Not mentioned yet in the thread but elsewhere, I would add that the firmware that currently runs on the Sony 505 does not display the text from epub files as fully justified - they are only left-justified. And columns of text that would probably appear nicely in a Sony LR* format file appear as a long, run-on sentence in epub format on the Reader. If Sony would fix this, then epub would be an added benefit to 505 owners because it might mean a lot more titles available for their Readers. Until Sony fixes the problem, I find these problems just too annoying and will stick with the Sony format.

[Hadrien]

I did such a list too on my blog: http://blog.feedbooks.com/?p=74

The Good

ePub support: Now that the PRS-505 supports this new e-book standard, it is much more future-proof than any other similar device on the market. Sure, ePub as a standard will evolve in the upcoming years, but in its current form, ePub is already very flexible (thanks to the OCF-OPF duo) and much more standard than the rest of the e-books formats on the market (XHTML, DTBook, CSS…). It’s good to finally get a mobile device with almost full ePub support (previous reading system usually didn’t supported the CSS part of the standard).

Improved PDF support: The previous version of the PRS-505 firmware and the PRS-500 both had terrible PDF support compared to the rest of the e-ink readers because of a grey-ish background and bad font rendering. You’ll instantly notice the difference: the background is now almost white and the fonts are much more crisp. While you were limited to large fonts on the previous firmware, you can now use much smaller fonts too.

PDF reflow: As an e-book format, PDF is always quite problematic for the average end-user. Most of them don’t quite understand why correctly displaying a letter sized document on a 6″ screen is almost impossible. Hopefully, they’ll be able to reflow those files now, although the results could look better.
Digital Editions: The official Sony Library software is awful and is probably one of the worst problem with the PRS products. Hopefully, we can now use Digital Editions to manage those files (at least if you’re using Windows) or the good old UMS support.
New DRM support: Thanks to the new DRM system from Adobe, it’ll be possible to borrow books from various online libraries or to buy books from all sorts of online retailers rather than strictly on the Sony e-book store.
To compete with Amazon, Sony needed to open their product to every online retailer out there, and they did the right move.

Speed: In the menu or while reading a book, you’ll notice a speed improvement with the new firmware.

The Bad

Lack of justified text: While we can display advanced ePub files on the PRS-505, with embedded fonts, CSS, SVG and even XSL-FO, Adobe doesn’t provide any sort of support for justified text yet. Justification and hyphenation are the two main reasons why I’m still using PDF files on my device. Sure, it should be fairly easy to add support for justified text in the future, but it doesn’t make any sense to support something as advanced as XSL-FO first.

Page numbers in the right column: I love how DE rely on a real page system as opposed to the progress bar that we usually get with Mobipocket support. Increasing or decreasing the size of the font, won’t change the total number of pages or your current page number. Publishers can even link those page numbers to the real pages of a paper edition.
Unfortunately, Sony/Adobe decided than those page numbers should also be displayed in the right column. If you don’t have a CSS margin in your book (using @page or XSL-FO won’t work), you’ll end up with those same page numbers displayed OVER your text.
To-do list for the next firmware upgrade: an option to turn this on/off.

Only 3 font sizes: While LRF files were limited to 3 different font sizes due to technical limitations, we should be able to select any font size for ePub files. Unfortunately, Sony decided to limit this choice to 3 different font sizes. It doesn’t make any sense, and once again, should be fairly easy to fix.

Ugly PDF reflow: Sure, I don’t expect PDF reflow to be perfect. But what’s the point of dividing a word on 2 different lines without any sort of hyphenation rules or even a proper hyphen character ?

The Ugly

No PRS-500 support, AT ALL: While I can understand why, for technical reasons it might be hard to add ePub support on the PRS-500 (limited CPU and RAM resources), Sony could at least fix the PDF support on the PRS-500 (background and font bug).

No support for DE on OS X & Linux: In order to use DE on your computer, you need an upgraded driver for the PRS-505. The driver is strictly available on Windows: for those of you using OS X or Linux, you won’t be able to buy DRMed books or to use Digital Editions to manage your files.

XML flow size limit: That’s probably the worst problem with the current mobile version of Digital Editions.
While it is correct according to the ePub specs to use a single XML flow for your whole book, Adobe recommended in their best practice guide to divide your book into multiple XML flows. If your book is divided into multiple chapters, of course, this is a best practice: parsing and processing a large XML flow can be very difficult in a mobile environment.
But how can you properly divide Ulysses or any book from Proust ? Those books do not even use page breaks. To create a book with multiple XML flows for such books, you’d have to add page breaks in the middle of the text.
On the desktop version of Digital Editions, if one of your XML flow is larger than 300k (unencrypted), you get a warning message but it still works. Open the same file on the PRS-505 and you get a cryptic “Paging Error” message.
With the current software, it’s simply impossible to display Ulysses without butchering the text (page breaks where there should be none).

[kovidgoyal]

Originally Posted by pepak

Guess I will stay with LRF. I have just converted a book to EPUB using the default settings of HTML2EPUB, and I am quite disappointed. The speed is pretty good, except that the Reader does not parse the whole file at once - instead it "reformats" the book every time I try to follow a link. Apparently only some parts of my CSS file get interpreted (e.g. blockquotes are beautifuly formatted according to my specs while regular paragraphs are not). It seems images are displayed in full size while in LRF generated from the same HTML file the images are resized to fit the screen. But the most serious issue is that in EPUB, certain national characters are not displayed correctly - but they work perfectly in LRF. It may be that HTML2EPUB incorrectly detects encoding (the incorrect characters seem to be those few which are different in Windows-1250 and ISO-8859-2), I don't know. Still, the poor formatting and very poor performance with links seem like a serious problems with the Reader itself.

Try the --encoding option for html2epub. Also images not being resized is a html2epub vs. html2lrf thing, though I thought DE would automatically resize images bigger than the screen.

As for the links, that happens when the epub contains several HTML files (typically because the total content length is > 300K). But yeah DE is very unstable when processing links. I've seen epub files that crash when you click on an intext link and work when you use the same link from the TOC. I expect this will not get better until the next generation of hardware which for SONY at least will hopefully be sometime soon.