Why buy a Kindle DX that is limited to reading and buying books from Amazon, when you can get an iPad for 10 dollars more that reads content for Kindle, Barnes & Noble eBooks, Apple’s own iBooks, Lexcycle Stanza, and brilliant full-color magazines from Zinio? Not to mention read blogs and websites for free that Amazon otherwise charges for to convert to its proprietary format?

After all, Perlow points out, the screen size is the same on both devices, but the iPad’s is full color. Moreover, it has 4 times the storage capacity and comes with “a much faster refresh rate [and] a much faster processor and has access to over 150,000 applications over ubiquitous high-speed Wi-Fi, including the free Kindle for Tablets app that will provide all of the functionality of the inferior, dedicated black & white e-reader, and then some, because it will be able to read Kindle books in color, as shown in [this] screen shot of the application.”

A really smart, incisive look at things by Perlow.

What’s XML for? Perhaps if publishers understood that question we would be farther along the road to e-books — and to whatever the thing is that subsumes e-books into a richer medium without forgoing book-ness.

I was speaking with Jess Lawson of Oxford University Press earlier this week about using XML in book production. The desirability of an XML workflow comes across more clearly, I observe, when it’s called “XML first,” as OUP does. Adding XML markup for web or e-book delivery after a standard birth — inception, editing, production — enables electronic delivery but seems to be worth only about as much trouble as it takes. After-the-fact XML brings little additional benefit.

I remember a slide that Tommie Usdin of Mulberry Technologies showed at an XML conference ten years ago. It stated simply, “Markup is expensive.” And about the same time Jon Bosak of Sun did some back-of-the-envelope calculations that balanced the extra costs of adding markup at about 1.8 uses of the content.

What’s that mean? By Bosak’s rule of thumb, if I were to publish ten books with ten chapters each, the additional cost incurred by structured markup like XML or SGML would be met by the simple re-use of 80 of the 100 chapters — on the web, in advertising, in custom publications, in re-purposed derivative works. If I remember correctly, Jon’s data came from Sun’s own experiences, in which material describing computer subsystems would be used in documentation for many different final products, with some descriptions even making their way into marketing handouts.

Trade publishing doesn’t have so many opportunities for repackaging, but re-use is as simple as utilizing the same source for different editions. So the added cost of XML markup is met if, say, I publish four of my ten texts in hardcover, mass-market and large-print editions. Fifteen years after the internet’s appearance and well into the second coming of e-books, this seems rather crude justification. But fifteen years ago, those three editions likely would have been produced — keyboarded, formatted, proofed — in three entirely separate editorial workflows. In 1994 I was working with Ballantine Books, and even then setting the paperback from the hardcover text files was the exception rather than the rule.

Single-source “P- and E-” publishing appears to drive the publishing industry’s slow turn to XML workflows. Markup is expensive, and the uncertain economics of our electronic future means the sight line for pay-back on that extra expenditure must be short, direct and obvious.

Perhaps this is one reason “electronic” books are scarcely electronic at all, but only scantily draped in the most superficial of markups, our ever-present HTML. With its ready use in even the most rudimentary web-pages, HTML markup must seem like a no-brainer to those publishers venturing into e-books. Who wants to invest millions on markup with no way of assuring its return?

To return to my opening question — Why XML? — we won’t understand the answer until we first realize that the responses publishers most often rely upon are really answers to Why HTML? or Why single-source? Years ago, Bob Stein argued that we couldn’t exploit the electronic side of publishing unless authors understood what that meant (and then he set about building new authoring tools).

Today, I would argue that we can’t exploit E- (yes, “E hyphen” is my abbreviation of e-publishing and fiddle for anyone else’s use of “electronic” as a situational attribute) until editors understand XML as well as English grammar, and regard metadata as valuable as a plug on Oprah. Only then will the structural elements exist in e-books that will make them more valuable than p-books.

This is only the first broadside of many which I will be launch here from Teleread’s ramparts. I also splutter as @eReadster on Twitter.

That will soon change. The Windows UMPC will be able to run the Kindle e-reader. Also, Amazon will move the software to new Android and Maemo devices with significantly higher resolution than the iPair’s 480×320. The Motorola Droid 3.7" screen has a resolution of 854×480, and the slightly smaller Nokia N900 has 800×480. Both yield 267 pixels-per-inch compared to the Apple devices’ 163 ppi.

With nearly three times as many pixels per square inch, the typography on the new devices is wonderfully crisp and readable at far smaller point sizes than you would imagine. I write from personal experience of both the N900 display and Coke-bottle-thick eyeglasses.

Whatever the effect on sales that some experts see from waning novelty and growing choices, I predict it will be outweighed by huge new numbers of e-book buyers entering the market and expecting to split their reading among more than one device.

(Adapted with permission from a Reading 2.0 post. Screenshot shows the Kindle app.)

With its flat surface, iPhone-like dimensions, camera, video, and phone capabilities, the N900 aims to fit into the same fits-in-your-pocket-and-does-way-more-than-your-phone category as Apple’s iPhone while still retaining its web-while-you’re-walking-around emphasis.

The N900′s 3.5″ full-color display has a 267 pixel-per-inch resolution (compared to the iPhone’s same-size 163ppi screen) measuring 800 x 480 pixels. This makes for dazzlingly sharp text. The device also includes Flash 9.4 and reads PDF files natively. This, along with the newly added 3.5G wireless capability, would appear to position the N900 as an ideal platform for a synching Kindle e-reader.

Amazon advises publishers to implement color, motion, and interactivity into e-books, despites its Kindle devices’ lacking support of these features. Clearly the bookseller needs more than just Apple’s iPhone and iPod to deliver these electronic essentials lest more entertaining products snatch its current format and pipeline dominance.

Of course, the Kindle 1, 2 and DX utilize a Linux-derived operating system, so porting the e-reader, book-delivery and synching software does not appear to be an impediment either.

The N900 is due in October 2009, with an expected price of €500. With larger-screen and cheaper e-readers arriving in the same period, it may not be the first choice as an e-reader. (Nor, for that matter, first choice as a phone, camera or video player.) But its unmatched versatility as a carryaround device makes it an undeniably attractive contender.

FBReader, the nonpareil open-source e-reader — it reads e-books in 12 different formats and runs on Windows and Linux handhelds and desktops, as well as Macs (unofficially) — has a long and close relationship with the Nokia Internet Tablet. Although it is not formally included among Nokia’s applications, FBReader is part of what makes the NIT’s great e-readers.

Bookstores have long declined to sell print books without an ISBN, a reality of entering the book-distribution chain that new commercial ventures have simply had to accept. For physical objects — items that pass across a checkout counter’s barcode scanner — there’s no getting around it.

But inventory management is irrelevant to e-books, which aren’t barcode scanned, and so an ISBN isn’t required to provide a permanent and globally unique identifier. Many e-book publishers have found it simpler to piggyback on the internet’s domain-name system that guarantees unique web addresses and just utilize a URI as their GUID. After all, registering a domain ensures that no one else is using the prefix you begin with and URIs can be valid without referencing an actual web page.

Unfortunately, URIs are not inherently permanent and domain ownership lapses all too readily so this approach has problems. Perhaps if permanent URIs, such as those provided by PURL.org had been widely utilized, we would not today be hearing a clamor for applying different ISBNs to every format an e-book is issued in. But they weren’t, and the squawking of new and small publishers at the expense entailed more than matches that clamor.

For some years, Jon Noring has suggested establishing a registry for e-books. which would of necessity assign suitable GUIDs. Getting mandatory registration, though, is impossible and voluntary compliance from every publisher everywhere unlikely.

Monday, Teleread ran a piece by Elizabeth Burton decrying the unequal effect of requiring a small press in the U.S. to churn through these expensive ISBNs (whereas next door in Canada, publishers pay no charge at all for ISBNs). Discussion about ISBNs broke out anew in other places, including on the Reading 2.0 list.There Jon brought up a new twist to his suggestion that has a distinct stroke of brilliance.

The current ISBN-13 code is a conforming EAN-13 code, Jon pointed out. By utilizing EAN-13 similarly, e-book identifiers from a new registry would be compatible with ISBN-13.

And being compatible, an e-book-only identifier could be placed in the field intended for ISBNs in a sales or inventory program without causing anything to break in a bookseller’s database. (Even though such overloading isn’t necessarily advisable.)

Additionally being an EAN-13 number, this identifier provides the guarantee of uniqueness and vendor registration a retail business needs (the famous “if it doesn’t have an ISBN, they won’t be able to sell it in bookstores” dictum actually means EAN-13 today).

What’s more, a U.S.-ebook EAN-13 identifier would never duplicate an ISBN code. So publishers could stick with an all-ISBN system or mix the two as they find most convenient.

Let’s see: retailer friendly, affordable, complementary to and not overlapping the existing ISBN registry, globally unique and permanent, non-proprietary — this sounds like a good answer to the need for e-book identifiers to differentiate format within the larger “electronic” designation.

And with it, then booksellers, libraries, content repositories, and us content consumers could reasonably demand that all content producers and packagers provide the central piece of metadata that all of us want to be included in any book distributed electronically. Use the ISBN system or use this alternative, we can say, or don’t be downloading your untrackable files into my e-reader.

As per Jon, a completely new registry agency could be set up to distribute EAN-13-conformant e-book identifiers. However, as part of its intended role to further e-book standards and interoperability and keep our industry from factionalizing, I wonder why we do not expect IDPF to take this on.

Other than its post-dotCom-era lassitude, is there any reason we shouldn’t turn to IDPF? As a believer in metadata’s pre-eminent role in internet discovery, I’m convinced that permitting e-books to be issued without permanent and globally unique identifiers portends disaster.

IDPF should act promptly to forestall this. Who better to cope with this situation? It’s what a trade organization is for.

Software publishers started out with the same “X users requires X licensed-copies,” but that evolved into a policy cognizant of the customer’s need to make maximal use of its resources and so X concurrent-users became the norm.

I suppose the technical requirements of a similar ebook-lending policy would be too daunting to effect.

But still, that buy-one/lend-one practice is galling. It just forces libraries to spend money on books that aren’t being lent efficiently, stifling the adoption of ebooks where they’re needed the most.

So I have a suggestion for libraries — ask your patrons to buy ebooks in the library’s name.

If I buy an ebook of Pride and Prejudice and Zombies, then it’s glued to me. Love it or hate it, I can’t give it to the library for others to read.

So why doesn’t the library set up a program for donors: “Buy it in our name and we’ll lend it to you first.”

Hey, I’m going to spend the money on the ebook already; I still get to read it when I buy it; and this way I’m able to donate it to the library (which I am otherwise prevented from doing). The library gets sorely needed ebooks for lending, and more readers are exposed to the book earlier. (Surely that can’t be bad for authors or publishers.)

A sensible business model won’t penalize either party in such situations, but let’s face it, we’re still very far from discovering what works for writers, illustrators, publishers, bookstores, libraries and readers (the human kind). So this is nothing more than a (in my opinion, much-needed) stop-gap for libraries. But I think we should settle for some breathing space until the new paradigm begins to take shape.

I’ve been counting books in Kindle Store on a daily basis and now the time to share results:

* When I first started counting on the 2nd of March 2009 there were 242,488 books in the Kindle Store.
* As of the 12th of May 2009 there are 281,986. 39,498 books in 71 days.
* So on an average day 556 new books are added to the vast collection already available to Kindle owners.
* If the pace remains constant there will be 411,606 books in the Kindle Store by the end of the year.

Go over and read the rest of the story. Thanks to Roger Sperberg for the link.

They have started a new service, currently Twitter based, which will build a catalog of ebooks. Check out their epubcatalog info and here’s an excerpt from their write up:

How do I get started?

It’s very easy if you’re a member of Twitter. We plan to support many services in the long run, but for now, you’ll need a Twitter account. With your Twitter account, follow @epubcatalog. Once you’re a follower, you can tell epubcatalog about books you find on the Web. The only format supported for books is EPUB. Support for catalogs is planned through the OPDS recommendation.

How do I add books?

To let epubcatalog know about links to books, the books must be on the Web and publicly accessible. To get links, often you can right click on them in a Web page and select “Copy link” or “Copy URL.” Then simply Direct Message (DM) the URL, prefixed by a plus sign (+). It will be added to the epubcatalog.org catalog as soon as your message is processed. Normally, it happens in a matter of seconds, but it can take several minutes to an hour depending on Twitter network congestion.

A command to add a book looks like this:
+ http://catalog.feedbooks.com/books/1001.epub

The space between the plus and the URL is required. You don’t need to type in the title or author, these will be pulled from the EPUB file.

How can I see books I’ve added or books other people added?

The epubcatalog Twitter stream will announce new additions as they’re processed. Since you’ve followed epubcatalog at this point, you’ll see everything new as it comes in, including your own adds (although to protect privacy, epubcatalog won’t tell anyone who posted the items). It may take a few minutes for your additions to appear. Another way to see new additions is to simply subscribe to the epubcatalog.org Atom feed. This is a catalog feed that you can subscribe to with Google Reader, most Web browsers, and a lot of other tools out there.

At .036 inches, the new e-reader is thinner than a pencil. Among other improvements over the discontinued 14-month-old Kindle 1, the device-side buttons for turning pages now press inward instead of outward, minimizing inadvertent page turns.

While many had speculated that the $359 price would hinder sales, that doesn’t appear to have occurred. Indeed, the biggest contretemps involving the Kindle 2 has centered around its Nuance-provided text-to-speech voices (Tom and Samantha) and whether authors ought to be compensated when machines read the text aloud.

The TOC Blog has a description of the content. (Formats: epub, mobi, pdf.)

The JP Morgan Library houses, among many other treasures, the only surviving original copy of Paradise Lost, as well as three Gutenberg Bibles. On Monday, I reflected upon the enormous pecuniary value of these specific copies (or instances of a manifestation, as the FRBR taxonomy has it) when Amazon announced its forthcoming Kindle2 e-reader in the Library’s auditorium. No matter how strenuously Amazon labors to associate the Morgan’s grandeur with the Kindle, there will be no similar physical artifacts for future generations to venerate with the electronic books that will be read on this latest and stately issue of the e-book state of the art.

Well, that was a fleeting meditation, I admit. I was soon caught up in the very remarkable features of the Kindle2 that I suspect were not much remarked upon in the media flurry that ensued.

The Kindle2 is the first non-cellphone native of the walkaround web — lightweight, portable and capable of accessing the web at all times from anywhere with no extra charges of any sort.

Astonishingly, the Kindle does not rely on some in-the-future-for-most-of-us widespread WiFi like Sprint’s variously named XOHM or WiMax. Instead we’re talking about Sprint’s 3G (e.g., EVDO) wireless network. For that same unlimited data access, on that very same 3G network, my wife and I are obligated to pay some $60 to $70 each month through 2010.

Of course, this shouldn’t lead you to do all your websurfing on a Kindle2, since it lacks not only color but also the ability to play Flash files and video.

I’ve always abhorred reading books online because it’s predicated first on doing your reading on a computer and second on your being connected to the internet through the entire time reading. Now, however, people with a Kindle2 can read online books without either of these encumbrances.

If a book is not a product but a process (as Jeff Jarvis noted today at TOC) and if the conversation around the book’s ideas are as rich as the book itself, then we really have arrived at Bob Stein’s sense of a book (also noted at TOC), which he proposes is “a place where readers (and sometimes authors) congregate.” Seen from this perspective, the online book has a currency that locally downloaded copies will always lack.

I’m as object oriented as any other bookstore browser, with dangerously strong bibliophile yearnings. Four enormous volumes of The Story of Civilization sit atop the eight-foot bookshelf next to my desk and I can still relive the vivid moment in an upstate New York bookstore when I experienced the vicarious pleasure I would have on re-reading the Durants’ glorious prose (because, yes, I had already read these books). And yes, I haven’t opened these books once since that feverish moment when I calculated our vacation finances and then squandered a prince’s ransom on them.

So I enter our new age with some regret, too.

The antiquarians of the future won’t have any “last surviving original copy” of any of our electronic books to house in some future Morgan’s library. And readers of the archived snapshots of the conversation-we-engage-in-that-is-a-book will wonder What was it like to participate in the making and shaping and working out of our quondam masterworks?

I know though that, along with that tinge of regret, I am also experiencing a bliss in this dawn to be alive, to see this new book-making emerge. Remarkable, really.

Photo: Morgan Museum and Library

As TMQ might say, This is surely the 21st century, when the release of a new e-reader is blazoned across Times Square for the masses to exult in.

For something like five or six years, I’ve been able to style XML elements with CSS and have the text displayed just the way I want.

That is, in the XMetaL XML editor* and in browsers.

Not in an e-reader, however. All the e-readers specify the vocabulary you’re permitted to use in your e-book**.

There’s a difference between a reader and a browser, between a reader and an editor.

The reader has library functions, bookmarks, annotations. It collects multiple files into a single package; browsers and editors don’t have the same orientation. They just won’t do.

As it happens, I’ve worked with XML since 1999 and I have lots and lots of XML files I need to look at. I’m not particularly happy with my reading choices and I hate converting a file to XHTML just so I can view it in the distraction-free confines of FBReader or MS Reader.

Last week I ran across OpenBerg Lector again, and I took a fresh look at it. Lector has separated from the original effort to make YAEBVBOX (yet another e-book vocabulary based on XHTML), and it has a fairly clear goal: to enable a (human) reader to open an e-book package in Firefox and read the e-book there.

It took a day or two for me to realize that. In the past, I’ve envisioned browsers being used to treat texts on the web more like an e-book, and Lector’s being a Firefox add-on clouded my perception.

However, Lector won’t just read XHTML files. In fact, its main format is OEBPS — Lector will read OEB package files in a single-file publications (stored in .obz zip files) and handily display the content files therein.***

Once I realized that Lector was built to be an e-reader that lets Mozilla’s Gecko do its rendering, it dawned on me that at last an e-reader had arrived that would accept arbitrary XML.

I grabbed some XML files (structured, as any XML ought to be, by the nature of the content and not by some pre-ordained presentation of a scientific article that spawned HTML), wrote some CSS for the elements used, and created a package file, tossing it all into a .obz archive.

When I opened this file (yes, using File | Open File…) in Firefox, it correctly utilized Lector’s scripts to display my three XML files, moving smoothly between one and the next by pressing PageDown at the bottom and PageUp at the top.

I’ve just begun exploring what Lector can do. The first effort to replace scrolling with pages is underway. I believe the annotation, highlighting, bookmarking and so on will be delegated to other extensions. By building on the Firefox framework, Lector surpasses other e-readers by providing such features as MathML, SVG and use-your-own-XML.

That’s a lot to recommend it, and of course an example of the ‘prairielight’ e-readers I projected earlier. Lector has now set the bar that other e-readers will have to to meet.

__________
* And possibly other XML editors that I haven’t owned.

** Don’t point out the unfulfilled potential of the “extended” vocabulary permitted in OEBPS 1.0; I never heard of any reading system that implemented it.

*** I’ve never encountered a book in the “Cabinet Comic Books” format (.cbz, .cbr), but that too is handled by Lector.

As someone who’s made my living as a freelance writer and written a couple books, I’ve thought about copyright and the rights of a creator. These concerns are pretty low in my current thinking.

As a technologist, I’ve thought about including motion, sound, color and interactivity to take advantage of the content being delivered by a computer. Following the development of Sophie, I’ve come to accept the need for creators to make rich-media texts, no longer thinking of this as an after-creation/publisher activity.

As a reader, I’ve thought about getting ahold of what I want to read and removing the barriers to what Bill Hill calls ludic reading. What kind of device do I want to hold in my hand and what do I want to see on it? In this time, I’ve mostly been using FBReader on the Nokia 770, N800 and N810 internet tablets, and I am consequently dependent upon a flexible and color-capable device, unlike the majority of what the market seems to be offering up right now.

As someone who has worked in book publishing for the last fifteen years, I’ve thought about how to forego copyright as a mechanism for economic protection and still provide incentives for publishers and writers (and jobs for editors). A viable business model — gosh, it sounds more and more like the search for the holy grail.

I’m no true prognosticator, but I think we can see the outline of the next generation of e-readers now.

Bowing to Sophie’s makers, I believe the new e-books will contain far richer media than at present. And by this I don’t mean “including video and audio” but just what Sophie‘s makers do: including anything an author might devise when provided with full programming capability.

Like FBReader and Openberg Lector, the next-gen e-reader will accept a whole slew of formats. And as the OpenReader and OEBF formats champion, the most useful formats will deliver a single file that itself contains one or more maps to multiple files inside it. And we’ll be able to escape the “html with a slight makeover” straitjacket we’ve lived with since day one of e-reading.

And as FBReader and Lector insist, the next-gen e-reader will be multi-platform.

All of which lead me to expect that the triumvirate of AJAXed development platforms — Mozilla’s Prism, Adobe’s AIR and Microsoft’s Silverlight (I call them “Prairielight”) — will provide us with many new e-readers.

For one thing, with any of these platforms, a small team will be able to create a formidable, flexible, cross-platform e-reader. Heck, I’m no programmer and I have conjured up a respectable application based on XUL and Javascript. They build on the internet technologies already widespread — I mean the browsers’ rendering engines and Flash, HTML, Javascript, XML and CSS — and will benefit directly by new innovations the web brings.

I guess I’m counting on people expecting their e-reader to have the same capabilities as their web browser. In that case, why not just build on top of the browser/rendering engine?

Besides, prairielight apps should make it easy to allow authors to program their own interactive aspects.

For that matter, we might see halfway-authoring tools that basically allow authors to build one-off e-readers, designed solely for their e-books and requiring a prairielight installation to read and not some specific next-gen e-reader.

So some textbooks could build in interactive questioning that would send the results to a local network server in the school. And language textbooks would build in timed review, evaluating your responses and flashing recent vocabulary you’ve had problems with more often than older, easier terms.

That’s already something you can do with AJAX and prairielight now and wouldn’t require programmers to learn new skills to make their e-books really electronic.

Access has announced a public beta of virtual machine software that allows Nokia Internet Tablets to run Palm OS applications. Thoughtfix (aka Daniel Gentleman) at Tabletblog was the first* to report on this and has a video showing the software running as well as some photos.

The Garnet VM runs on the about-to-be-released N810, the N800 and the no-longer-being sold 770.

If, as expected, the software runs in landscape mode on the Internet Tablet, readers of this blog may find more e-books now available to them (and more readable on the NIT’s 225-pixels-per-inch screen). With 770′s going for as little as $100 on eBay, an inexpensive high-quality e-reader on a widely used platform is a reality. For those unsatisfied with the stock on non-DRMed books readable in FBReader, this is good news.

As Internet Tablet Talk headlines it, “Run 30,000 Palm OS apps on your Nokia Internet Tablet.”

Brighthand reports that “Garnet VM is expected to be available by the end of the year free of charge as a download from Access.” (Other reports at intomobile and engadget.)
__________
* Oops. Dan writes that he got the news from intomobile.