Open eBook shortcomings

ABOUT Open eBook shortcomings:

Following are two screen captures of one of the OEB official sample documents.

This is a screen capture of a portion of the official OEB demo document, which purports to display precise placement of text on screen.

This is a screen capture of the exact same page as it actually displays. The text placement malforms in all early browsers and in all the latest versions of non-Microsoft browsers.

The OEB Publication Structure does not support the GIF and animated GIF image file formats, which are extremely popular on the World Wide Web.

The OEB Publication Structure does not require or recommend support of the GIF format. This does not mean that eBook reader manufacturers who utilize Microsoft's Open eBook format cannot choose to support GIFs, but in practice, none do.

XML has been designed to work natively with Unicode, and the Open eBook Publication Structure reflects that. Unfortunately, there is a difference between a computing device understanding that a character is part of Unicode and that device being able to display that character on a screen. The Open eBook Publication Structure requires that compliant eBook reading systems understand when they have run into a Unicode character, but it does not require that the systems display all Unicode characters correctly (though, certainly, reading systems may choose to implement many of them). Instead, a reading system may signal to the user that it has run into a Unicode character it does not understand (by instead displaying a question mark or other symbol).

Working with OEB requires significant understanding of text markup, which has proven difficult for many authors and publishers who think in terms of the appearance of the printed page.

Display of OEB-formatted files, even with current-generation stylesheets, demonstrates the same deficiencies that Web designers have been complaining about for years: lack of sophisticated typography, lack of control of screen sizes and resolutions, and limited control of element placement on the screen.

Moreover, since the OEB Publication Structure does not require that all Unicode characters be displayed properly, reading systems have chosen not to do so, making publishing in non-Roman alphabets a difficult business.

Finally, the OEB Publication Structure does not require much image display quality from compliant reading systems, meaning that grayscale (or even highly detailed line art) images can be essentially worthless on some devices.

In addition, the CSS support required by the OEB Publication Structure falls short even of that available on the World Wide Web. For example, it does not require that devices understand the hierarchical location of a tag in order to display it properly (that is, a device need not understand the difference between a paragraph at the top level of a document and a paragraph inside a list item). This is a damaging limitation, removing much of the advantage of the hierarchical structuring XML offers.

PDF files are also limited, and in equally important ways. Since they are so dependent on the concept of a paper page, they are difficult to resize without loss of legibility, and cannot currently adapt to screens of different sizes (although Adobe is working on reflow capability). Moreover, PDF files can be somewhat brittle; if a necessary font is missing, for example, the carefully-designed display can quickly become visual garbage.

A lot of the html coding which is accepted and currently rendered perfectly viewable by Web browsers, is not permitted by XML and OEB.

In particular:

Some HTML tags are not supported. Appendix A of the Open eBook Publication
Structure gives a table with the status of all HTML tags vis-a-vis the OEB Publication
Structure.

In XML, tags are case-sensitive; in HTML, they are not. and are the same tag in
HTML, but two different tags in XML. The OEB Publication Structure, in line with other
XML applications, requires that tags be all-lowercase or the document will not display properly.

End-tags are not optional in XML. If you start a paragraph with a tag, you must
finish it with a tag.

Empty elements--that is, elements that do not contain any text and don't have end-tags,
such as <img> and in HTML--must finish with a space and a slash before the final
>.

The slash is required by XML; the space is required by OEB, so that OEB-compliant
coding can be displayed correctly by older, non-XML-aware web browsers. (Many
browsers that do not know about XML's /> notation can still correctly handle tags
containing the end-slash if there is a space before it.)

Attribute values must be surrounded by quotation marks, something HTML does not
require. The tag <table border=5> is acceptable HTML, but not acceptable XML or OEB;
both require <table border="5">.

Overlapping elements are not allowed in XML and OEB. Strictly speaking, they are not
allowed in HTML either. The commands for bold and italic for example are supposed to "nest" in the order they are given. Therefore;

This is bold and this is bold italic.</b

is correct, while the sequence of the commands ( end italics and end bold) were accidentally reversed on the following version of the same sentence.

This is bold and this is bold italic.

Because the web was popularized by the general population, most of whom had quickly taught themselves how to program simple html pages, (and therefore made a few mistakes along the way), web browsers were designed to recognize the fact that they were dealing with humans and generally don't choke on such simple errors.

OEB does.

OEB-compliant eBooks must be packaged with an OEB package file, an XML file that
describes the files that constitute the eBook, what order text files should be read in, and
(optionally) suggestions for quick tours through the book or direct linkages to important
reference sections such as glossaries and indices.

The OEB package file has no direct relationship to anything in use currently on the World Wide Web.

A bit of Web history: When HTML was first developed, it had very little concern for appearances, since it was intended for easy exchange of information rather than for attractive text display. Once the World Wide Web caught on, though, HTML added many tags having to do with text and image display.

In HTML, purely appearance-oriented features of HTML (such as <align=center>) attributes and tags like <CENTER>) were "deprecated," meaning that while they worked in Web browsers, their functionality was now being replicated by other commands. The OEB Publication Structure deprecates or simply refuses to support everything that is deprecated in the HTML 4.0 specification (in addition to features of HTML that are irrelevant to eBooks, such as forms and programming hooks). Moreover, the Publication Structure states that deprecated features may not be available at all in future versions. If you use a deprecated feature, you use it at the risk that future reading systems may not be able to handle it.

So much for OEB's backwards compatability.

All of this has important implications for the longevity of eBook files. Display devices and programs evolve constantly; even in the short life of typical eBook reading systems, their capabilities have changed in many ways.

If your eBook data is to avoid obsolescence, it must be as independent as possible.

Illumination ebooks don't require any operating system.
Documents on the web can be read on your LunchBOOK (and vice-versa.)
No special software or cables needed.
Gosh. What a good idea!

http://www.the-office.com/lunchbook/overview.htm

OEB publishing excerpts from a document by D. Salo, Electronic Publishing Specialist