Why should I create OEBPS Publications? When shouldn’t I?
OEBPS Publications are durable and long-lasting. If every single device and program for Open eBook Publication display were to disappear from the earth, OEBPS Publications would remain usable, since any text editor can handle them, and with minor modifications any Web browser is able to display them. Text editors and Web browsers have many more uses than just working with OEBPS Publications, making them highly unlikely to vanish.
The disappearance of an entire class of hardware and software may seem a ludicrous scenario, but it really isn’t. Display devices and programs evolve constantly; even in the short life of OEBPS reading systems, their capabilities have changed in many ways. In a sense, display devices and programs do disappear, when they become obsolete and are replaced. If your eBook data is to avoid obsolescence also, it must be as independent as possible, not reliant on any one display device or program.
Note that evading obsolescence is a key reason the OEBPS does not define a binary format for OEBPS Publications. Such a binary format would be doomed to eventual obsolescence, marooning staggering amounts of content. An OEBPS Publication, however, need never become obsolete; as new binary formats come along, the same OEBPS Publication can feed into them.
Accessibility for the visually-impaired is a vitally important advantage. Markup-based text-to-speech systems already exist, and promise to be easily adaptable to eBook use.
The authors of the OEBPS have committed themselves to backwards-compatibility, meaning that even when new versions of the Publication Structure are released, files coded according to the old rules will still be substantially or completely conformant. Moreover, intelligently-created OEBPS Publications should be relatively trivial to upgrade in the future, as new capabilities become available on reading systems.
Because XML is an important technology outside as well as inside the publishing world, new authoring, conversion, display, and manipulation tools are constantly becoming available for it. Many of these tools can be used in a publishing context, even if not originally intended for it.
On the other hand…
Working with the OEBPS often 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 OEBPS-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, lack of hyphenation and justification, and limited control of element placement on the screen. As stylesheet languages evolve, however, the gap is likely to narrow. Already, CSS support in the typical Web browser is fairly impressive; those whose vision of HTML is bounded by the look of unvarnished HTML tags should revisit the issue.
Unfortunately, the CSS support currently required by the OEBPS 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. Fortunately, future versions of the OEBPS will address this issue.
The OEBPS is not currently well-adapted to technical publishing and foreign-language publishing. There is no provision for complex mathematical or chemical equations in the OEBPS. Moreover, since the OEBPS does not require that all Unicode characters be displayed properly, reading systems have generally chosen not to do so, making publishing in non-Roman alphabets a difficult business.
Finally, the OEBPS 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.
What kind of software do I need for direct authoring of OEBPS Publications?
OEBPS Documents can be authored in any text editor or word processor that can handle plain ASCII (also known as “text”) files. Examples of text editors include UltraEdit or WinEdt on the PC platform, BBEdit on the Macintosh, and emacs or vi (or any of their numerous derivatives) on Unix or Linux.
Commercial XML-specific authoring tools also exist. Within the next few years, standard word-processing programs should be able to write XML files. (Microsoft’s Word 2000 claims to be able to do so, but in fact the “XML” it produces is malformed.) Sun’s StarOffice (and its open-source derivative Open Office) file format is native XML; StarOffice is available for Linux and Unix platforms.
As yet, there are no OEBPS-specific authoring tools. One possibility would be to use one of the many HTML authoring tools available, although the output of such tools will need some changes and should be validated in order to ensure OEBPS conformance, since they probably are not programmed to produce clean, XML-conformant HTML.
The Brown University Scholarly Technology Group has released XHub, a service for converting specific types of documents to OEBPS.
How do I know that my OEBPS Publication conforms to the rules of the OEBPS?
Since the OEBPS includes a DTD for Basic OEBPS Documents, it is possible to use a piece of software called a "parser" to check that such documents conform to that DTD. Any XML parser (several of which, most of them free, are currently available) can do this.
The Brown University Scholarly Technology Group and NuvoMedia (now part of Gemstar) have also made an OEBPS compliance checker, available at http://www.stg.brown.edu/service/oebvalid/, which checks for other requirements of the specification in addition to parsing the XML. This compliance checker functions for both Basic and Extended OEBPS Documents.