FBReader is inadequate since it does not support HTML tables. Only Openberg is adequate for rendering pages since it is based on Firefox as its plugin.

>you’re objecting to the fact that different rendering engines produce different results, well, that’s just a fact of life. Web developers have been dealing with this problem for years, and it’s not likely to get better any time soon.

On the web this problem is getting better with a release of every new version of any major browser. In epub space this proble is getting worse with release of any new reader.

>The current epub spec, despite its shortcomings (which are likely to be addressed in subsequent versions), strikes me as a perfectly reasonable first pass at defining a file format designed primarily to support books as we know them today — an ordered, linear collection of pages — containing text and images; in electronic format. It does not attempt, nor should it, to revolutionize the concept of a book.

Epub format was proposed and in some circles accepted as a kind of standard for electronic publishing. I dispute that epub deserves such status. To propose as a standard some format which is designed to support books as we know them today is wrong. Nobody knows what electronic publishing will evolve into and how electronic publications will look like. In this unsettled situation those who propose some kind of standard should leave as much as possible space for experimenting, should strive to provide maximum flexibility.

IDPF does not go in this direction. They propose utterly restrictive format and say that it is right to adopt it now. I dispute this. It is wrong to adopt epub now for many reasons. First, its unflexibility and restrictiveness, second, appalling state of reader software. Only Openberg is based on browser engine which rendering power can be believed into (but it is immature and it is doubtful even if its developers will release a version compatible with Firefox 3 when the latter ships); the other readers are based on something nobody knows what. The common denominator of what can be displayed reliably on epub readers is very low (no html tables, no css positioning). On the web situation is quite different: although there are differences between browsers, the common denominator of what can be displayed reliably in major browsers is quite high.

Proper display is possible only in quality browsers or in software based on quality browser engine.

You’re talking in generalizations here. Can you give us some specific examples of what you consider to be adequate and inadequate readers? Are you talking about desktop reader applications, embedded reader applications (like those found in dedicated e-reader devices), browser plug-ins, or all three?

If, on the other hand, you’re objecting to the fact that different rendering engines produce different results, well, that’s just a fact of life. Web developers have been dealing with this problem for years, and it’s not likely to get better any time soon. HTML and CSS are large, complex beasts, and in many cases the specs leave implementation details open to interpretation. You can probably expect to experience more inconsistencies as browsers/readers begin to implement new versions of these specs.

Although OPS does not “bless” any particular audio/video format, they may certainly be used in OPS Publications.

Well, but will anybody provide plugins for epub readers for rendering those formats? Most probably there will be no plugins

As far as I know, Openberg Lector on Firefox handles media just fine. Lector handles the .epub file and the Gecko rendering engine handles the rest. What’s the problem?

Openberg Reader, not rich in features…

Openberg Lector is an immature product. Give it some time.

…and not supported in Firefox 3

Firefox 3 is beta software. It shouldn’t come as any surprise that some plug-ins designed for Firefox 2 don’t work on Firefox 3 — yet. Once again, give it a little time. The root of most of your objections appears to be your frustration with the fact that these applications don’t do what you want them to do RIGHT NOW. Patience is a virtue.

You seem to believe that books and web sites are synonymous. I disagree with this assertion. Both have their place, but they’re two different things. The current epub spec, despite its shortcomings (which are likely to be addressed in subsequent versions), strikes me as a perfectly reasonable first pass at defining a file format designed primarily to support books as we know them today — an ordered, linear collection of pages — containing text and images; in electronic format. It does not attempt, nor should it, to revolutionize the concept of a book.

You also seem to believe that the solution to underpowered readers it to embed a custom reader in the content. Again, I disagree with this assertion. I think users want a consistent user interface, and I doubt they’d warm to the idea of having to use a different reader for every publisher’s content.

Finally, let’s not confuse platforms, applications, and file formats — they’re three completely different things. If you want to go it alone, define your own file formats and build an application that supports them; if you want that application to run in multiple environments, develop it on a portable runtime platform like Java or Adobe AIR; if you want to publish content that will be supported by multiple applications, choose a file format that is widely supported by existing software.

As soon as you have something more complicated than simple sequence of <p> tags in the page, getting things displayed properly is quite complex. Proper display is possible only in quality browsers or in software based on quality browser engine.

Suppose some epub pages in which has some elements with static, some with absolute and some with fixed positioning, and some html tables. Will it be correctly displayed in current epub readers? - No!
FBReader supports neither css positioning nor tables. Digital Editions probably supports it, but DE is based on totally unknown rendering engine and it means that if someone wants to publish for DE he should support a new HTML rendering engine with its own bugs to search workarounds for.

>Although OPS does not “bless” any particular audio/video format, they may certainly be used in OPS Publications.

Well, but will anybody provide plugins for epub readers for rendering those formats? Most probably there will be no plugins, and no multimedia as a consequence.

>it certainly is possible to build plug-ins for web browsers that can render EPub

But until now there is only Openberg Reader, not rich in features (no contents in menu or sidebar, no library view, no search) and not supported in Firefox 3. In this situation if someone publishes epub, that epub will almost certainly not read in browser-based reader, but in not so based DE or FBReader.

It seems to me that IDPF made a huge mistake by thinking about epub apart from browser. Since developing quality engine for rendering HTML and CSS is a gigantic task, any format based on HTML should rely on modern browsers or browser engines for its display. By extension, any format which allows multimedia in addition to HTML/CSS should rely on current browser plugins.

Some people don’t seem to care about having an integrated dictionary for e-reading and some can’t be without one. I’m more in the later camp.

The dictionary formats used by Microsoft Reader and Mobipocket Reader are both well documented. The easiest thing to do would be to adopt one of these, thus gaining an instant selection of commercial dictionaries for purchase. If that option is not possible or desireable, then certainly some similarly structured XML format can be invented for epub reader use. Or, even one of the existing XML dictionary formats that the Open Source community has developed (at least two that I know of) can be used.

Sure, there are a few things that cause problems in different browsers. But this is not a fault with epub. The browser quirks were there long before epub and there are well documented ways to deal with these quirks. Going forward, even Microsoft has promised to better comply with standards. I see this as a non-argument as far as epub is concerned.

As for some people’s insistance on multimedia in ebooks, while I can see some use for it in certain cases, for general use, I feel about it the way Rod Serling did when commenting on early TV:

“It is difficult to produce a television documentary that is both incisive and probing when every twelve minutes one is interrupted by twelve dancing rabbits singing about toilet paper.”

About web browsers, it certainly is possible to build plug-ins for web browsers that can render EPub. I discussed this in a prior comment.

I think that in its current, not modified, state epub is not suitable for digital publishing. I would not recommend to adopt it to anyone. Why?

1) it is weak and not flexible. No scripting, no flash, no multimedia. It means that if you adopt epub now, you will be forced to abandon it as soon as some other publishers will adopt some more powerful platform (for example, Adobe AIR) for their projects.
2)There are no readers based on quality browser engine. That means that to publish the same content at first on web and then as epub you should support in addition to Internet Explorer, Safari, Firefox and Opera all reader engines such as Digital Editions, dotReader, FBReader who have their own bugs. Even if there will emerge some reader based on quality browser engine (maybe Openberg if it will be mored developed), existence of those other readers not so based will create wrong expectations that epub publication will be rendered correctly in all readers which most probably will not be the case. That means that a publisher should either distribute its own reader or direct readers to some quality reader, and this is quite complicated.

I took a look at your site and the presentation is quite nice. From my perspective, it is a shame that I can’t download these nicely formatted ebooks to read away from my PC. I’ll have to find them elsewhere.

“but we also need legions of independent developers building APIs and authoring tools and Reading Systems and open-sourcing all of them.”

I agree with you 100% on this. How about sharing some of those tools that you have developed?

Not directly, but your original post panned epub rather severely. It certainly leaves the impression that you had no use for epub.

>For those who like to read offline, I highly recommend supporting your local public library or bookstore.

Sounds like I hit a nerve Thankfully, there are many other sources of ebooks to be enjoyed offline, both free and commercial. I patronize them, as do quite a few others.

Those issues aside, now that we know that you are using epub internally, perhaps you would share some of your experiences as to creating and using that format? I’m sure we’d all like to hear about some of the tools and processes that you have developed.

As for content, all of our content is free and no account is required to read it. For those who like to read offline, I highly recommend supporting your local public library or bookstore.

So, as long as people have to come to your site to read, your ok with epub? You’re barking up the wrong tree. Sure, we all read some things on the web, but I think most readers want the ability to take content offline and carry it with them to read.