From 46439007cf417cbd9ac8049bb4122c890097a0fa Mon Sep 17 00:00:00 2001 From: "Charles.Forsyth" Date: Fri, 22 Dec 2006 20:52:35 +0000 Subject: 20060303-partial --- lib/ebooks/devils/foreword.html | 99 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 lib/ebooks/devils/foreword.html (limited to 'lib/ebooks/devils/foreword.html') diff --git a/lib/ebooks/devils/foreword.html b/lib/ebooks/devils/foreword.html new file mode 100644 index 00000000..3d1304be --- /dev/null +++ b/lib/ebooks/devils/foreword.html @@ -0,0 +1,99 @@ + + + + + + +The Devil’s Dictionary: Editor’s Foreword + + + +

Editor’s Foreword

+ +

This Open eBook edition of The Devil’s Dictionary was begun as a way for +me to learn the Open eBook (OEB) structure and how to write clean XHTML that duplicates the original formatting of the +typeset edition.

+ +

Having hit the limitations of the OEB format and current OEB readers in this attempt, I am +posting this early version of my conversion effort as a test document that illustrates the shortcomings of the +format and is meant to encourage the developers to address these issues in forthcoming versions of their software +and the OEB specification itself.

+ +

The most difficult problem I have faced in formatting The Devil’s Dictionary +has been poetry. The print copy I own has the poems formatted so that the attribution line is right justified +with the end of the longest line of the poem, no stanza is broken across pages, and the whole thing is centered +within the margins of the body text. This is a very natural way to format the poetry, yet it is impossible to +duplicate this structure with the current eBook readers—most notably, with Microsoft Reader.

+ +

First, the only +way to create the desired justification and centering with HTML is to place the whole poem inside one table. This +works for small poems, but not for larger ones because MS Reader cuts off all text in a table cell when the end +of the page is reached, preventing long poems from being displayed in their entirity. Additionally, if each stanza +is placed inside a pair of paragraph tags (as would seem natural) many of the indents must be accomplished by +adjusting the left margin of that individual line with a <span> tag. This should work, since +both this tag and the left margin property are applied to all elements (block and inline) according to the HTML and +CSS specifications. MS Reader, however, ignores this instruction. An example of this formatting +is found in the “A” section of the Dictionary.

+ +

An alternate way to format the poems is to enclose each poem in a <blockquote> tag, +each line in its own paragraph tag (with different CSS classes to handle the needed indents and close up +the line spacing) and, each stanza in a <span> tag (with the CSS page-break-after property set +to avoid breaking across pages). However, the blockquote’s margins causes many poems towrap, does not +center the poem, places the attribution line (and any right-justified lines of the poem) almost at the right margin +of the book (sometimes far away from the poem itself), and MS Reader ignores the instructions to not +wrap the stanzas. This method is demonstrated in the “B” section of the Dictionary.

+ +

As I was writing this, I thought of what should have been an obvious construct for these poems: putting +each stanza in a separate table cell. This solves many, but not all, of the problems described above. For poems +with short- or medium-length stanzas viewed with the PC version of MS Reader on a large-screen laptop +it should work fine. But for a PocketPC, or even for poems with long single stanzas on a PC, the bottom of each long +stanza will still be lost. You can see the results of this experiment in the “C” section of the +Dictionary.

+ +

These issues can best be demonstrated by one representative poem in each of the first three sections, when +reading the book in the desktop version of MS Reader. Abracadabra should +be separated into stanzas with 1em of space between each, but since Reader ignores the <span> +tag, it is just one long block. The poem cited under the definition of beg exemplifies +the problems with the wide right margin described above. Although not perfect, the poem cited under +carmelite is presented almost exactly as it should be. The poem is properly +centered, the indents and right justification appear as intended, and the poem is broken across pages only +between stanzas. But when viewed on a smaller screen (almost certainly with a Pocket PC) the first stanza +alone will likely be cut off.

+ +

A major additional problem, not specific to this book, is the inability of any current OEB reader to handle +Unicode text, as mandated in the OEB specification. An example of how such a Unicode document appears is +demonstrated in sections “D” (UTF-8) and “E” (UTF-16) of the Dictionary. Notice that +the Unicode signature/byte-order mark which appears at the beginning of each of these files causes problems with +both the readers and with the authoring tools. The MobiPocket Publisher can not complete the conversion +process at all, and while ReaderWorks handles both relatively OK, MS Reader can not display UTF-8 files +correctly (the Unicode signature causes it to ignore all CSS formatting and UTF-8 characters are displayed +as their literal byte sequence, something specifically forbidden by the OEB specification) and the whole +section “E” disappears because of the byte-order mark.

+ +

Most sections beyond E have not yet been fully formatted, so please do not expect them to look pretty.

+ +

Project Gutenberg

+ +

Another goal is much broader. I have long known of Project Gutenberg, but have +always found its insistence on plain ASCII to be a handicap that limited its appeal and usability. Don’t +get me wrong—the effort has provided a tremendous resource, and at the time the project was begun +(and until very recently) plain ASCII was clearly the best choice. But you can’t properly format a book +with just ASCII characters. Not only must basic things such as *bold* and _italics_ be indicated in a funky +manner, it is simply impossible to preserve the accented characters, ligatures, and many other important +features. And trying to display such a work legibly on a PDA or eBbook reader with a small screen is +impossible, given the hard line breaks that are present (keeping the text from flowing properly).

+ +

With is footing solidly in HTML and XML and its completely open nature, the Open eBook +format is the ideal structure in which to continue the goals of Project Gutenberg on into the 21^st +century. So this edition of The Devil’s Dictionary is not meant just as a personal learning +project, but as an example of the benefits to offering current and future editions as Open eBooks. I don’t +dispute the benefits of the current plain ASCII versions, but with the right automation tools, future editions +could begin as Open eBooks and then be converted to plain ASCII, making both versions available without +duplicated effort. This would be far preferable to starting with plain ASCII versions and converting them to +Open eBook. This is the method I obviously used for this edition, and I assure you that it is quite tedious +and not well-suited as a standard practice.

+ +

Peter K. Sheerin

+ + \ No newline at end of file -- cgit v1.2.3