TeleRead: Bring the E-Books Home

Although there’s no doubt that ADE is not perfect, I would not yet start saying they are hindering eBooks.

The main question I have here is this, what is the HTML/CSS markup like?

Knowing how people traditionally markup HTML in web pages I can imagine that many of these books, both professional and otherwise are actually over complicating things.

On my experimentations so far I’ve found that if you keep your HTML/CSS code tight and simple then you won’t go far wrong. Sometimes you have to look a problems from the side, rather than front on, and in doing so you can still achieve nice results while using simple HTML/CSS.

EPUB is not here to replicate the paper book and trying to do so will only cause you headaches, though this doesn’t mean it can’t be close.

Let’s face it, your average novel is just straight forward text; headings, italics, indents, etc., all achievable with very simple code. Okay, tables are a little more complicated but as long as you don’t try to replicate what you would do in a paper version, then desirable output should still be attainable.

I’d suggest the fellow above go download the LIT version of this:
http://ebooktest.blogspot.com/2009/04/ah-gorgeous-lit.html

And compare it to the ePub version also available.

If he can’t see the LIT is superior, then, Next!

I missed this and meant to comment on it.

I’d encourage publishers to use ePub but work hard to educate Adobe and others on the need for better implementations. And if the standard itself can be improved, which it can be, then so much the better!

David, ReaderWorks already does the job well and fast. The LIT files turn out beautifully (if you’ve marked them up right) and MS Reader renders it beautifully AND it’s easy on the eyeballs (that ClearPrint thing is fantastic). It’ll be years before we see that kind of excellence in output in an EPUB file with gentle nudging from publishes and whatnot. I’m all for standardization, don’t get me wrong, but it occurs to me the efforts toward adopting EPUB is reinvention of the wheel–Especially when a superior (and easier) product (from producer to consumer) already exists.

The ePub format is off to a great start, with growing support from many members of the Epublishing community. But there is one iceberg that could sink the ePub movement: the failure of software and hardware makers to render ePub correctly.

Publishers do not want to make many versions of the same ePub ebook: one for the Sony Reader, one for Adobe Digital Editons, and so on. We have been there — lost in the labyrinth of a dozen formats — and we don’t want to go back.

Two ways to read ePub that are getting it mostly right are Stanza, and BookWorm. If other reading systems want my eyeball time, then they will need to improve their ePub support.

Michael Pastore
50 Benefits of Ebooks

Well, clearly there is a problem. However, without looking at the mark-up it is hard to say if the problem is in the authoring tool or Digital Editions.

This discussion is giving me flashbacks to 2003 when web standards were a hot issue. Back then, designers were beginning to realize that the old way of designing layouts for the web was seriously flawed. A standards-based design movement emerged to promote designing with valid XHTML/CSS and a separation of presentation and content.

If you were a web designer in that era you were in for quite a bit of pain (or experimentation, depending on your perspective), for a couple of reasons:

1) Designing web pages with XHTML/CSS requires quite a bit more precision and effort than the old way of designing page layouts with nested tables and font attributes. In many cases these challenges were compounded by design tools that were not up to the task of generating valid code.

2) While the web browsers of the era supported web standards, they didn’t all support the standards in quite the same way. Internet Explorer’s rendering of CSS in particular gave standards-based web designers fits.

At the time there were many who argued that web standards weren’t worth the effort and that we might as well continue coding web layouts the old fashioned way. Fortunately that worldview didn’t prevail. The XHTML and CSS standards weren’t the problem. Rather, the many inconsistent implementations of those standards (CSS in particular) were the problem.

So, what was the solution? Well, it didn’t involve abandoning CSS and taking the easy way out. Instead, there was the emergence of a huge community of bloggers and designers devoted to web standards. Designers worked through the various compatibility headaches together.

Over time the tools got better, browser support got better, and web designers got better and smarter. Without question, the web is a better place today because web-standards prevailed. And that happened because there was a strong community of talented web designers who realized the value of standards and weren’t about to give up.

I see the same situation with ePub. It’s important to remember that this is still a relatively young standard. You don’t get universal format support and foolproof authoring tools overnight.

This is all a very long way of saying that Mike’s experiments are the beginning of what might be a long process of working through these issues. In the meantime, there are places you can go for help. As Liza Daly tweeted earlier this week:

If you’re having trouble converting a file to ePub or getting it to look the way you want, join the ePub Community list: http://bit.ly/B26oC

Moriah: “if EPUB is built on the same platform LIT is, that it has A) taken so long and B) is so inferior in production”

That is an excellent question that I’d like to know the answer to, as well. I can take an expanded LIT file, add a few metadata files, zip the result, and end up with a nice ePub file. When people talk about the lack of ePub tools, I can only assume that the LIT tools must have licensing clauses preventing their use for ePub.

As for rendering, this is definitely an Adobe Digital Editions issue! It seems as though some people are missing the fact that Stanza avoided all of these issues by re-using the HTML engine that was well-tested and readily available.

You don’t really need to reverse engineer the LIT format. It is mostly a standard OEB ebook, which epub has evolved from. There are a few MS specific markup additions. The LIT file itself is similar to a Zip file, but uses a different compression algorythm and may or may not include DRM.

The real reason that most (not all) LIT ebooks look so nice is that MS worked to get the authoring tools created, provided some fairly good documentation on how an ebook should be formatted and most importantly, the MS Reader software was the only way to render those LIT ebooks.

MS exercised a lot of control over the entire process. We don’t have that with epub, which as we’re seeing, is both good and bad.

Yes, we desperately need more and better authoring tools that enforce best practices and generate strictly valid epub. There is enough wiggle room in the epub spec that you can generate valid, but crappy ebooks.

On the other end, none of the current epub readers do a good enough job with rendering. I’m sure things will improve.

Personally, I think that the current epub spec left too much as “recommended” instead of “required”. In a later version of the spec, hopefully this will change.

Between Joseph’s comment and Logan’s, it occurred to me that this EPUB candle needs to be burned on both ends, consumer and producer, at the same time.

Obviously I don’t know much of the history behind the LIT, but I DO know that as both a producer and consumer, the production tool is easy sleazy and the product is beautiful to look at (and easy on the eyes).

Joseph,

Personally, I think that the current epub spec left too much as “recommended” instead of “required”. In a later version of the spec, hopefully this will change.

From your fingers to God’s ears.

Great to see that Peter is on top of things. His last point about “auto” being allowed to be treated the same as “0″ is a good example of the “wiggle room” that I was talking about that causes problems.

I just finished an informal test, using Moriah’s epub. ADE does the best job displaying it, followed by FBReader, then Azardi R2 and dead last is Stanza (Windows).

The two surprises to me were FBReader and Azardi. FBReader has come a long way with epub support. It still has a ways to go, but the recent versions are substantially better with epub. I am surprised that Azardi displayed things worse than FBReader, given its reason for being (a strict, compliant epub renderer).

A few comments to Moriah: You don’t seem to be taking full advantage of what you can do with epub. For example, epub supports font embedding. Comparing with the PDF version, the epub would be greatly enhanced if you used the same fonts you used in the PDF.

You may also want to use another creation tool for the type of control you want to achieve. Calibre is fine for the average user who wants to convert ebooks between one format and another. I don’t think it is suited as a publishing tool for getting professional results.

I can’t comment on InDesign, as I can’t afford it (unless someone wants to give me a copy). You might try that eScape plugin for Open Office (I haven’t gotten around to that yet), or even markup things with a text editor. It isn’t very hard. Notepad++ is a good text editor for this type of thing.

David, please don’t get me wrong, I’m not tolerating EPUB’s deficiencies. But I am taking the same approach as what I do with web design; keeping things simple whenever possible, and by simple I don’t me ugly – or at least I hope my files are not ugly

I’m not sure how those examples showing the poetry were marked up but, I’ve had no problems so far when I implement the same feature.

I still get the impression that people are trying to do pixel perfect layouts. People had the same layout challenges with web design back in the early 2000’s, it still happens now, although I think most designers have come to terms with the differences between print and web.

Creating beautifully formatted eBooks is great when they are read on the desktop, but what happens when you throw the thing at an iPhone — we can’t possibly expect to keep that same layout.

As several of the posts above point out, LIT is essentially OEB which is the starting point for ePub. Do straight forward LIT to ePub conversions render as well in existing ePub Readers as the original LIT in MS Reader? If not, then how about Calibre’s LIT to ePub conversion? If this does not work well then Calibre can probably be improved to make this work (unless the ePub Readers are broken).

LIT isn’t enough on its own for an ePub subset that is known to work well, but it might be a starting point for such a subset.

I had a reply yesterday that Teleread sent to Electron Hell, so I’m really pissed off about investing time in Comments here, OK?

>>>I just finished an informal test, using Moriah’s epub. ADE does the best job displaying it, followed by FBReader,

What FBReader? I D/Led the one available and it couldn’t do the Pro Abyss. I gave it mine and everything was crap.

Now if THIS Comment goes to Electron Hell, Teleread has seen the last of me in Comments, goddammit.

The key issue with epub is that the IDPF went feature bananas choosing to support everything costing it the ability to get anything just right.

if you look at lit you will see that it’s a lot simpler and based on the older web standards.

Theres this myth that the code behind the web have become simpler and more rigid this is actually not the case the standards have been adopted to allow every hack and nonconformist behavior, epub is born in the new ago of non restrictive spcifications while lit was born back when standards were simpler to implement but did not support anything everyone wanted.

the basic jar like container is the same and the old html4.0strict with css used in lit is for the most part embedded in the much much more complex xhtml1.1 with css2.1 but lit is OEB complient in the same way that ASCII is UTF-8 complient.

Joseph Gray: “You don’t really need to reverse engineer the LIT format. It is mostly a standard OEB ebook, which epub has evolved from. There are a few MS specific markup additions. The LIT file itself is similar to a Zip file, but uses a different compression algorythm and may or may not include DRM.”

***blinks***

Most of what makes LIT files look good is in how the renderer renders the OEBPS 1.0 markup contained in the LIT archive, but it is certainly not a ZIP archive or anything close. It’s an MS-specific archive format which contains many many bells and whistles to help renderers do things like quickly start rendering from any arbitrary point in the book and render arbitrarily long streams. This is why e.g. LIT on PocketPC has no 300k stream maximum like the Sony Reader version of AdobeDE has for EPUB files.

There’s no LIT-specific documentation available that I know of, but LIT is an extension of the ITOL/ITLS format, which you can find quite a bit about. The LIT extensions which have been reverse engineered are expressed code-wise in the calibre LIT extraction and generation code. (I’ll get around to writing up some documentation at some point…)

@Joseph Gray: Ok, a bit of a misunderstanding it seems. After writing the calibre LIT extraction and generation code, most of what “LIT” is to me is the archive. The markup is almost just OEBPS 1.0, so I don’t usually think of that as “LIT.” As someone mostly interested in using existing tools to produce well-formatted books, what you think of when considering “LIT” appears to be primarily the markup, rendering details, etc. Fair enough.

And the documentation is definitely still present, but contains no information on LIT-the-archive-format, which is what I was referring to.