Is ePub “ugly”?
by Liza Daly
There’s been some healthy discussion, instigated by Mike Cane, about whether ePub can provide a visually-appealing reading experience. I recommend the related discussion on TeleRead, especially the comments.
There’s a lot of finger-pointing going on, but my feeling is that it reduces down to two statements:
- Reading systems need to fully support HTML/CSS. Realistically this means they must be based on WebKit or a similar mature HTML rendering engine. A home-grown engine like Adobe Digital Editions is often a source of frustration for ePub producers and readers.
- ePub producers need to take responsibility to understand how to correctly mark up their books. The best thing you can do when getting started is minimize your use of styles and custom formatting. Later, bring on an HTML/CSS expert to help fine-tune the layout.
Where I disagree with Mike is the idea that a beautiful ebook needs to precisely mimic its print equivalent. For born-digital works this obviously doesn’t apply at all, and the ability to read an ebook on devices of varying screen sizes and capabilities means that pixel-perfect rendering isn’t even desirable. Anybody with an ereader who’s tried to read PDFs on them is familiar with this problem.
What does need to improve are the defaults. This is where Apple tends to excel, by providing beautiful interfaces out-of-the-box.
But I also recently worked on a project to replace an unmaintainable website that was generated by Apple’s web-building software. It looked great in Safari but was totally unusable for the visually-impaired community, a substantial fraction of the target audience. I’m afraid an Apple ereading solution would be just as much of a beautiful cage.
Luckily, mature web browsers + high-quality HTML + reasonable CSS can produce some lovely results already. Here’s Mike’s test document in Bookworm’s new Reading Mode. I happen to think this looks nice.
But it’s much more important for ebook creators to proof the content rather than the layout. Check that the line breaks are right, that words aren’t run together, and that special characters are displayed properly. (The last Kindle book I purchased had numerous spacing errors — not bad enough to return it, but annoying for something that cost $6.00).
Comments
>>>Here’s Mike’s test document in Bookworm’s new Reading Mode. I happen to think this looks nice.
Let’s make it clear that’s the pro ePub, not mine.
And even there in Bookworm there’s a rendering mistake: Emerson is not in Small Caps.
Even though I dearly love EPUB, I’m beginning to wonder if the very fact that these formatting features are available to miss-apply might not be a fundamental misfeature. E.g. Mobipocket is disgusting and quirky at a technical level, but the severely limited formatting options mean that book producers are much more limited in how much they can get wrong.
Mike: That’s an error in the book itself, which lists his name as “EMERSON”.
A later chapter uses a properly capitalized name (“William Morris”) and that is indeed in small caps.
This reminds me of how, in the early days of the web, some designers insisted that it would never work for delivery of professional content because how could it look professional if you couldn’t even control the kerning?
Is an offset press ugly?
Asking if ePub is ugly is like asking if HTML, DocBook, .doc or .rtf is ugly. Sure, it’s plenty ugly, but it should only ever be seen by the inside of a rendering engine.
Adobe’s conversion of Alice in Wonderland is a fantastic example of what one can do with a bit of care.
ePub gives you plenty of rope to create documents that are visually stunning or visually stunted. What an individual typesetter or renderer chooses to do with that rope is another matter entirely.
I’m not terribly versed with EPUB, but as someone building a service that includes cloud-based story books, I gravitate towards @vandegrift’s comments about stripping away features in order to produce better results. Constraint-based design certainly isn’t native to publishing, but “built-in art direction” makes a lot of sense since it emphasizes the product more than the process and takes a lot of friction out the collaboration chain.
Wordpress and Tumblr have focused on beautiful presentation layers and simple workflows that make the gimpiest of content desirable.
I agree that design constraints can be good, and certainly are required when the reading device won’t support a given feature. No one can rightly complain that an eink reader doesn’t honor the CSS ‘color’ property, for example.
Aaron Miller makes a great point that the problem with ADE, in particular, is that its behavior is undocumented, and yet it’s being used as the reference implementation for ePub.
Thing is, my EPUB project was necessarily complicated by the fact that I have poetry. However, my CSS still only runs a few lines, whereas in the copy of Abyss Mike cracked, he has 4 pages of CSS. The fact that one CAN embed fonts using EPUB-compliant markup doesn’t mean one SHOULD embed fonts.
I don’t need EPUB to look as pretty as LIT (although I’d sure like it to). I do need it to render poetry (and, in Mike’s case, tables and fractions) presentably.
In my case, primarily it’s because I can’t get Stanza desktop to run well or I’d use that as default. I do not like using ADE for any of the ebooks I’ve got, no matter how lovely they may be. Now that I’ve downloaded the Sony desktop reader, I’m switching to that for my default.
@Moria Jovan: FWIW, the Sony desktop software uses an integrated version of ADE for rendering EPUBs… Is there some benefit to not just running ADE directly?
Marshall, it’s just easier on the eyes is all.
Anytime you try to force one medium into another, you are at risk of getting “ugly.” Just think about movies on video cassettes. Everyone of them had a warning that said “this movie has been edited to fit your screen.” Many, even on DVD, still have that warning.
We’ve made a huge error in thinking that reading=print. If it doesn’t completely mimic the print edition, it is ugly.
In reality, the designers who sought to control the layout most closely were the ones that produced the worst ePub layouts – true of Web design as well as eBooks. On my screen, 11px type might be perfect, but it is not perfect on a different screen resolution or for a senior reader who needs larger type. Specifying in pixels defeats the reading and assistive technologies built into the computer.
CSS is a partial answer to this when done correctly. It is better if I can apply my own CSS transform so that I read the work according to my own settings. Will I get the “benefit” of the designer’s well-thought-out precise design? No. But, I’ll be able to read it in a comfortable and enjoyable manner. If I want to have a typographer interfere with the way I read, I’ll buy the immutable paper version. Eventually technology will catch up with reading metrics that dependably display documents that look good on any screen. Until then, I’ll settle for documents that are dependably readable.
That is a problem. I find myself wondering if we’re in for a new era of CSS hacks to support multiple rendering engines.
This points to the importance of testing ePub documents on various devices. What we need is an ebook equivalent of BrowserCam.