Slashdot Mirror
Universal Ebook Format Debated
Amy Hsieh writes "A well-known ebook industry expert, Jon Noring, recently wrote an interesting article for eBookWeb, formally calling upon the ebook industry to adopt a single universal ebook distribution format. Right now there's a plethora of essentially incompatible ebook formats, and this format 'babel' is hampering the growth of the ebook industry. In the article, Mr. Noring proposes a promising open-standards candidate which appears to meet a list of basic requirements: The Open eBook Forum's OEBPS Specification. Andy Oram, a Linux programming editor for O'Reilly, wrote an interesting reply to the article that should also be read." On the other hand, Noring's proposal has also met with some skepticism elsewhere.
I don't think any format will get Ebooks to catch on until we have reader hardware that makes reading those books at least as pleasant as reading a paper book.
Here's hoping that all those e-paper efforts will produce something usable soon.
Why should i choose a format that have all possibilities to have DRM included in the future thus allowing only one read. And will require Electricity to read.
This is especially true for for factbooks who are often used as reference and not to be read just one time.
So far Ebooks cant beat the paper version in portability, convenience and ease of use.
Paperbook still seems more favorable to me.
I had a taste of incompatible e-Book formats when I got my first colour Palm.
Sadly, there were better (open) formats using better compression and rendering, losing out to closed formats with big marketing push.
The format that ultimately prevails will not necessarily be the best. It'll be the format pushed by those with the greatest marketing skills/budget, and the one which gives them the greatest control over how their works are used.
It wouldn't surprise me if authors are already signing e-book distribution deals which forbid them from releasing in rival formats.
One of these days, the masses will choose software and data formats according to quality and freedom.
But something within me suspects that the Pope will convert to Islam, and the Jews will profess the divinity of Christ first.
-- In the beginning was the WORD, and the WORD was UNSIGNED, and the main(){} was without form and void...
The Project Gutenberg Etexts should so easily used that no one should ever have to care about how to use, read, quote and search them ...
.it is the only text mode that is easy on both the eyes and the computer.
.to IBM, to Mac, to TRS-80. . .
.not just those your access has allowed you to get from Project Gutenberg. The point is that a decade from now we probably won't have the same operating systems, or the same programs and therefore all the various kinds of etexts that are not Plain Vanilla ASCII will be obsolete. We need to have etexts in files a Plain Vanilla search/reader program can deal with; this is not to say there should never be any markup. . .just those forms of markup should be easily convertible into regular, Plain Vanilla ASCII files so their utility does not expire when programs to use them are no longer with is. Remember all the trouble with CONVERT programs to get files changed from old word processor programs into Plain Vanilla ASCII?
.so is very much of the value of most of the various markup systems we have in the world. But until some real standards arrive-- we would be limiting our options a great deal if we do not keep copies of all etexts in Plain Vanilla ASCII as well.
.an operating system, a program, a markup system. . .will not.
.as the .Z compression format does in a similar manner today.
This has created a need to present these Project Gutenberg Etexts in "Plain Vanilla ASCII" as we have come to call it over the years.
The reason for this is simple. .
However, this encourages others to improve our etexts in a variety of ways and to distribute them in a variety of the available media, as follows:
Once an etext is created in Plain Vanilla ASCII, it is the foundation for as many editions as anyone could hope to do in the future. Anyone desiring an etext edition matching, or not matching, a particular paper edition can readily do the changes they like without having to prepare that whole book again. They can use the Project Gutenberg Etext as a foundation, and then build in any direction they like.
Thus any complaints about how we do italics, bold, and the underscoring, or whether we should use this or that markup formula are sent back with encouragement to do it any ways any person wants it, and with the basic work already done, with our compliments.
The same goes for media. We have had a long-standing work ethic of providing our etexts in any medium people wanted: Amiga, Apple, Atari. .
However, now that our etexts are carried in so many BBS's, networks and other locations, it is easier to download the file in a manner that puts them in your format than we can make and mail a disk, so we don't really do that too much.
The major point of all this is that years from now Project Gutenberg Etexts are still going to be viable, but program after program, and operating system after operating system are going to go the way of the dinosaur, as will all those pieces of hardware running them. Of course, this is valid for all Plain Vanilla ASCII etexts. .
Do you want to go through all that again with every book a whole world ever puts into etext?
The value of Plain Vanilla ASCII is obvious. .
We don't have anything against markup. Not vice versa.
Alice in Wonderland, the Bible, Shakespeare, the Koran and many others will be with us as long as civilization. .
This includes the many requests we have for compression in particular formats. There are only two formats we know of that are suitable for transfer to a wide general audience: Plain Vanilla ASCII (.txt files) and ZIPped files of them, (.zip files). Requests for other compression formats must be ignored as they are appropriate only for small portions of our target audience. However, (programmers take note: we will need help) we are planning to put some compression links on our files so they can be transmitted in any of an assortment compression formats on the fly. i.e. we should be able to generate any kind of file asked for, but we can keep only one copy of each etext on our servers. .
Shows what I know.
A couple of side notes: And how can you not know what babel is? Babel: Tower of babel: a story from the bible where King Nebekenezur (there is no correct spelling for that in english, just commonly accepted ones) wanted to build a tower to god, so god being jealous, put a spell on everyone, and they all ended up speaking a different language. It's how the christians believe that there came to be multiple languages.
Now the website babelfish gets its name from 'The Hitchikers Guide to the Galaxy' by Douglas Adams, where the characters 'stick a babelfish in their ear' to act as a universal translator.
Speak for yourself.
You have to be careful. Half of you are saying "I won't use this until e-books are as pleasant as paper books" and half of you are saying "why not use the standards that are already there? Just make the device do everything."
Don't you see these are at odds?
To make e-books as pleasant as real books, you're going to want to make them thinner and thinner in profile. You're going to want to make them run on a single lithium cell battery or AAA. You're going to want to drop all of the interface but the forward, back, and bookmarking buttons. You're going to want the computing device to be as close to nothing as possible, so you can put weight into making the device indestructible like a real book. You want to go to the store, buy the title, and have it just work, or go to Amazon and *know* your desired title is published in that format. That's the ideal, in the near term. It isn't a device that will easily accomodate PDFs and HTML and a number of other standards.
I have developed a higly sophisticated format for storing books in a computer file.
.TXT extention.
Each character of the book is to be enciphered to a byte. I reserve the first 32 codes (0-31) for various system function characters. The next 32 codes (32-63) encipher the space character, various punctuation marks, and numerals. The next 32 codes encipher the capital alphabet and a few more punctuation characters. With the simple use of 00111111 binary mask 'A' maps to 1, 'B' maps to 2, and 'Z' maps to 26. Quite clever if I say so myself! Naturally the next 32 codes encipher the lowercase letters in the same manner. Using the very same 00111111 bitmask you find 'a' mas to 1, 'b' maps to 2, and 'z' maps to 26! Ingenious, isn't it?
To ensure compatibility with legacy computer systems values above 127 shall not be used.
I call this encoding Advanced Storage Cypherment Input Ideal - or A.S.C.I.I. Any file utilizing this encipherment is a Tagged eXchange Template. These files may be identified by the use of a
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.