More on TechnologyTell: Gadget News | Apple News
Pepper Pad promising as an e-book reader despite flaws
June 22, 2006 | 10:50 pm
|
By David Rothman
The Pepper Pad is finally here, ready as review fodder for the TeleBlog.
Oh, the timing! Amazon has knocked the still-high price down to $670 after a $150 rebate, and eCost.com will go as low as $649. What’s more, thanks to a recent update, the Pepperized version of Mobipocket is much better than before–when you couldn’t even change the size or style of the letters on your screen when reading Mobipocket e-books. Pepper says further improvements are on the way. Len Kawell, founder of Pepper, is a hardcore e-booker, having founded Glassbook, which Adobe acquired and used to develop PDF. Hey, I won’t hold Len’s past against him (humor alert).
Any e-book-related questions about the freshened-up Pepper? Or usage tips and other comments from existing Pepper owners? Pepper employees and contractors are welcome to speak up, too, just so they reveal their affiliations. Here’s what I myself am thinking about the Pepper Pad 2, which the 3 will soon supersede:
Screen and (split) keyboard
The TFT SVG screen of 8.2 inches is quite readable even if it isn’t absolutely optimal for e-books and won’t please those insistent on the reflective approach of E Ink. I can vary the brightness but apparently not the contrast. While screen reflects light a little more than it should, it’s surprisingly bright; perhaps tomorrow I’ll take the Pepper outside and see how it fares in the sunlight. Sharpness isn’t at XGA levels, but still sufficient for heavy-duty reading.
I love the little scroll wheel to the right of the screen. Nice going, Len! Works great with both Mobipocket and the Web browser, helping to distinguish your box from the competition. So far, though, I hate the split keyboard. More on that later.
Like some others, I wish the Pepper were lighter and a bit smaller, a goal that the elimination of the split keyboard would help achieve. It’s 2.3 pounds. I’d be more comfortable with the weight–just a tad heavier than the Cybook‘s–if the machine were configured in the portrait mode, which the Pepper used to be. The present landscape mode is better for movies than for e-books.
Storage, CPU and those other grubby details
Nope, you don’t need a monster machine to use Mobipocket, the e-reader with which the linux-OS Pepper comes. For what it’s worth, the basic specifications are a 624Mhz CPU (Intel XScale PXA270), 256Mb of RAM and 20G of storage.
You’re all set for thousands of books. Pepper sent me the same machine as the one on sale at Amazon, so these specs apply.
Mobipocket issues
Ideally a newer Mobipocket will soon let e-book fans use the Pepper in the portrait mode, the way the usual flavors do. The Pepper’s cursor arrows are in a good place for page changes while you’re in the landscape mode, and I suspect they’ll also work out in the portrait mode.
Integration with the Mobipocket store online is seamless. The only question I have is, Will this harm independent booksellers? Also, TeleBlog readers already know how I feel about people getting locked into proprietary formats. Oh, to see the Pepper in action with the forthcoming dotReader in its double-column mode! (Reminder: I’m a ringleader of the OpenReader Consortium and dotReader is our first implementation).
Meanwhile do any Pepper users want to share thoughts on the use of HTML and ASCII on the Pepper?
Multimedia
While e-books are my main interest, I will say that the Pepper excels at its main task, multimedia. Videos show up beautifully on the machine.
Net radio sounds tiny on the built-in stereo speakers. But I wasn’t expecting much to begin with. Audio is crisp with good headphones.
The browser
The browser–a Firefox derivative–is apparently faster than earlier versions about which other reviewers griped.
Oh, and if you don’t notice at first, here’s how you change the font size in the browser.
Battery life
Yes, the battery does die after three or four hours. Don’t buy this machine to enjoy on extended hikes. I suspect improvements will be on the way.
More on the keyboard
I wish that Pepper would replace the split keyboards–to the right and left of the screen–with a good virtual keyboard to reduce size and weight. True, the split keyboard is organized QWERTY-fashion. But I still find myself typing very slowly on it. A Pepper tech support person assures me that to know the keyboard better is to love it more (or perhaps in my hate to hate it less). Maybe existing Pepper owners can fill us in. Jon Melamut, a bizdev guy at Pepper, tells me he’s doing perhaps 25 word per minute on the keyboard–much faster than with a virtual keyboard. So maybe, given the chance, I could yet adjust.
For those of us who prefer our keyboards whole, the Pepper lets you add on a Bluetooth-style KB, which you can use for searching e-books and, I’d hope, eventually for interactive e-book reading. You can use a mouse, too.
With the Pepper propped up on its wire stand, this could be a cool quasi-laptop once the variety of software expands. OpenOffice or an equivalent, anyone? If the Pepper’s OS won’t allow it now, maybe the company should consider doing so in the future.
The price issue
May Pepper hangs in there for time when a $149 Pepper is possible! List is $850. Because some new laptops can sell discounted in the 400s, Pepper will have to justify the machine on grounds of ease of use and reliability. The new software upgrades, which covered far, far more than Mobipocket, have helped tremendously in that respect. I know this first hand, since Pepper accidentally sent me an machine without the updates.
Pepper’s Great Challenge: Reconciling the ease-of-use pitch with the dismal realities of tech:
Alas, technical challenges help create the built-in paradox for a product like the Pepper. The company is conscientiously trying to court nongeeks through ease of use, or at least management of problems that may spring up. But what to do about woes that originate from a router, say, rather than not the machine? Or from other outside factors? The router example isn’t coincidental. Prior to the upgrade, I couldn’t get the Pepper to do encrypted WiFi, a “must.”
Oh, and then there’s old Tower of eBabel problem. How to explain to a newbie that Mobipockiet can’t read Adobe files? Luckily I hear that PDF is on the way. But there’ll be other issues like this. Simply put, while Pepper would love to position the Pad as a consumer item just like a high-def TV, the realities of tech may get in the way. Few industries are as Murphy’s Law-prone.
In fairness to Pepper, when technical issues arose over the issue of whether my borrowed unit needed an upgrade, the help was excellent. Kathy at the other end knew I was a reviewer, so I can’t promise you’ll get the same great treatment, but so far I have positive vibes about the company. In the end, I’m convinced, it’s the humans, the tech support staff, who might make the difference–in the positioning of the Pepper as an enticing bundle of entertainment for nongeeks.
Pepper ideally will be flexible in helping people faced with router problems and others that haven’t anything to do with the machine. Otherwise consumers will feel betrayed. My hunch is that Pepper will do the right tihng.
Memo to Amazon: The eBabel issue (continued)
Hey, guys, I know you’re reading the TeleBlog. Interesting, isn’t it–how the Pepper runs Mobipocket (Amazon-owned) and is on sale at store A? Too bad about this eBabel complication. With e-book standards and more openness in software, you might well be moving more Peppers. More competiton in e-book software would be good for consumers. Only one company makes software that can read DRMed Mobipocket, however, and that’s, yes, Mobipocket, Jeff B’s baby. Without a proprietary format involved and with DRM issues addressed by standards-setters, Pepper might not have to wait as long for a final version of the reader.
No–nothing against the good folks at Mobipocket, whose reader is miles ahead of those from Adobe and the rest. It’s just that they need to be more standards oriented and work toward true standards without DRM gotchas. Otherwise all this rhetoric from the e-book establishment about container formats and the rest will be in vain. E-books will still dwell in the Tower of eBabel, and, as noted, that will hurt Pepper’s pursuit of the nongeeks.
About that photo
I finally got a chance to change the Pepper photo to one that shows the review unit, or something close to it. I will also be making other tweaks.
|
Previous
SUBSCRIBE TO RSS
Comments:
Nice one David! With the iLiad costing almost $800+ … the pepperpad is becoming a very attractive option …
I guess the split keyboard is something that one must try and use for a few days or week to feel and know.
I had a Siemens SL4 SIMpad for a few months … I initially thought that with the onscreen keyboard, I would not miss a keyboard. But no … after a few weeks of tapping away … I gave up.
Online browsing is ok with just an onscreen keyboard … but internet today is beyond static browsing. As I type, I cannot imagine tapping away these lines … so, if my internet usage pattern is any gauge at all, a keyboard is always better than onscreen.
[...] TeleRead gives Pepper Pad 2 a half thumbs-up With all the buzz about forthcoming E Ink devices, it’s easy to ignore the alternatives. David of TeleRead reviewed the UMPC-style Pepper Pad 2 and he tested it for its capabilities as an e-book reader. To recap briefly, the Pepper Pad is powered with an Intel XScale 624 Mhz CPU, has a 8.4 inch 800×600 touch screen and is equipped with a 20GB harddisk. On the plus side, David notes, the screen of the Pepper Pad is usable for reading e-books with enough brightness and sufficient sharpness. What he didn’t like: keyboard, weight, short battery life, deep integration with Mobipocket (could be considered either good and bad, depending how much you like the Mobipocket format). Although the market for ultra-mobile PCs is still in its infancy, I expect it to heat up fast with the emergence of the first UMPC devices. And personally, at a price of $670 (after a $150 rebate), I very much doubt that the Pepper Pad will win any hearts among e-book fans. Related: Revamped Pepper Pad may be coming soon, Pepper Pad 2 – suitable for reading e-books? [...]
Hey dude!. The most attractive feature is the price. Apart, in the earlier one the little letters and numbers were absolutely incomprehensible. It was like a bad joke………….and its pretty cool in shape n size too.
1) It’s too heavy (must be under a pound).
2) It should have a flash drive instead of HDD.
These two items are non-negotiable for my money.
Sean from Pepper here. Just a quick note on changing text size — Ctrl-Scrollwheel will change font sizes on-the-fly in the Browser. Just remember to tap somewhere else on the screen once you’re done resizing to release the Ctrl stickykey.
Ah! So that‘s the answer to the mystery. Big thanks, Sean. I’ve just replaced the original copy with your tip.
Everyone: Sean not only works for Pepper but also is the author of the Pepper Hacks blog. I hope that at some point he’ll have more time to update his useful blog. Great way to encourage developers to write for the machine!
David
Last I heard (here), OSoft had its own proprietary DRM to lock up books in dotReader format when publishers demanded it. Won’t this put purchasers in exactly the same position they would be in if they bought the book in Mobipocket’s proprietary format, except that now they’d have books in dotReader’s proprietary format? What’s going to change? Are publishers going to forego DRM protection for their books?
You suggest here that some kind of common DRM scheme is going to be established by some kind of standards body. Can you say more about those efforts?
Heck, Bill, OSoft’s DRM is there only because publishers required it. The company is originally tried in vain to do a reader without DRM. A lock-up effort not!.
Besides, the forthcoming dotReader has lots of good things going for it, including the willingess and in fact eagerness of OSoft to avoid a Microsoft-style DRM chokehold. OSoft wants others to administer the DRM and would even allow other companies to use the technology without gouging them. We’re talking about pragmatic people committed to standards, including those orignated from other companies (for example, dotReader can deal with a number of XML-based formats and could even do DRMed PDF if Adobe allowed).
From an OpenReader perspective, however, all this is premature in some important ways. As you note, it will be up to the standards setters to decide on the best DRM system. If you want to be part of the process, then you will help determine the solution. Maybe it will be OSoft’s, maybe it will be interoperable systems from different companies–oh, the possibliities go on and on.
But as an end user, based on what I know so far, OSoft’s approach seems rather attractive. It isn’t machine oriented and also would allow full interactivity, according to what the company says–this is something for the appropriate people, including you, to vet. I’d like to see this happen by the rules of a neutral body such as OASIS. If anyone has a better solution, let that one prevail over OSoft’s. I just hope that there’ll be a better balance between the needs of consumers and the self-perceived needs of the content providers, who are really hurting themselves when they insist on Draconian measures–especially since it’s increasingly easy to scan paper books.
But back to the issue of the standards body. That’s no small factor, IDPF just isn’t to be trusted to be Standards Central, not when people from ETI chair both the container and format groups. This in itself shows the lack of technical talent available to the IDPF. OpenReader favors a more open, more inclusive approach, encompassing more people from outside the e-book-related companies; and to avoid accusations of favoritism, we would prefer that OpenReader founder Jon Noring not run the standards effort. My own preference would be someone from outside the industry, such as Allen Renear, who earlier presided over the once-productive IDPF/OeBPS efforts before business people let the standards group fade away. Standards efforts at the IDPF were revived only when OpenReader started up.
Thanks,
David
Bill Janssen posted an insightful and powerful comment earlier that outlined the immense difficulties in creating a common system for “digital rights management” (also called “digital restrictions management”). Janssen’s comment is in this thread here. I agree with the primary thrust of Bill Janssen’s comment. Also, I think that stringent and effective DRM for ebooks is largely unworkable because it will always be possible to simply scan a book to yield a version that is DRM free. However, I would like to comment on the technological and economical feasibility of building a comprehensive cryptographic infrastructure. I think that it is possible to build such an infrastructure and it is a highly desirable goal. (My comment is continued immediately below.)
First, there already exists an example of a widely deployed cryptographic system that is used by web surfers every day. Many web users are unaware that a complex piece of cryptographic software is built into Firefox, Internet Explorer and other browsers. Scores of websites use https which relies on Secure Sockets Layer (SSL). Yes, this may sound like more acronym gobbledygook, but the motivation for using https and SSL is to help provide secure communications on the Internet. To accomplish this task websites and browsers use public-key and private-key cryptographic algorithms. Websites must obtain public-key certificates and usually the certificates are digitally signed by companies such as VeriSign. Admittedly, website administrators that use https are more sophisticated than the average web user. But it is interesting that web users can transparently access these websites without major difficulties.
There are very compelling reasons to create a cryptographic infrastructure that would give each person in the world a flexible cryptographic identity using multiple public and private keys. The infrastructure necessary to accomplish this would be vast but it need not be expensive from a per capita viewpoint. In fact it would be delightfully inexpensive compared to the advantages obtainable. Here are just a few of the boons possible:
1) Electronic mail could be encrypted to substantially increase communication security. The newspapers have recently been filled with stories about eavesdropping. This is unsurprising when so much communication today is performed in the “clear” with minimal attempts to provide security.
2) Electronic mail could be digitally signed. This would raise the level of trust in communication. It would also allow a radical reduction in the amount of spam and in the number of bogus solicitations from con artists.
3) Financial transactions could be made more secure. An individual could use one of his digital keys to sign a valid financial transaction.
4) Access to governmental services could be improved. For example, taking out an item from a digital library would be facilitated. Obtaining a license online would be easier.
5) Polling data collection could be improved. For example stock proxy voting, and voting during popular television shows could be done more easily and more accurately. Spoofing and multiple voting could be reduced.
How does this relate to DRM? It would be possible to piggyback on this infrastructure by adding an additional set of keys for DRM. I do not advocate this because as I indicated about I do not think that DRM for ebooks is a good idea.
Thanks for your thoughts, Garson. I’m hardly a crypto epxert, but as an end user, I certainly think that standards setters should consider your idea along with the others. As you know, I myself wish that we didn’t have to be discussing DRM for e-books. I’m open to DRM only because I fear that without it, there’ll be an increasing disconnect between the worlds of literature and the Net. I want those wonderful 20th century literary classics–the ones still under copyright–to be online. Thanks. David
btw, David, is the batt life with wifi or not? Maybe some details would be good, wifi, screen brightness etc.
Hi, Snappy. Batt life is with WiFi. You’ve got what seems to be a full set of options–various flavors of WEP (64- and 128-bit) and WAP encryption. As for screen brightness, it’s superior, but I really need to give it the ultimate test and go outside. I will in the next hour or so and revise this post. I’ll be Fed-Exing the unit back tomorrow or the day after, so now’s the time to ask question. Meanwhile I’d welcome more details on your pad–here’s a Wikipedia item.
Back to the Pepper. Who knows, I may yet be won over on the built-in-keyboard issue for the Pepper–but I wonder if the board couldn’t be in a dfferent location and not split. Perhaps it could even be on the back on the unit, with an entry screen. Or if that gets in the way of true interactivity, maybe the keyboard could be an attachment at the front that could also be detached for more comfortable typing.
Update on screen brightness, 11:05 a.m. EST: It’s cloudy here in the Washington, D.C. I could see the screen comfortably when I read in the shade of a tree; otherwise, the Pepper Pad’s brightness won’t suffice. Oh, well. Perhaps it’ll still work out at the beach if you take a big umbrella.
More on battery life with WiFi: A more precise estimate would most likely be under 2 hours. But then again, the battery I’m using may not have been charged using an optimal pattern.
Thanks,
David
David writes:
A lock-up effort indeed! I’m talking about using proprietary DRM to create a “locked” book format, one that only “your” reader (or one from one of your licensees) can open. I fail to see why locking up books as a result of bowing to business pressure from business partners should for some reason be seen as more virtuous than locking up books for other reasons. Won’t a consumer who buys one of these DRM’ed dotReader books be similarly locked out of their purchased content? What’s the effective difference between this and any other proprietary DRM scheme? Where’s the solution to your tower of eBabel here?
Color me skeptical. Of course, if they decide to publish the details of their DRM system, so that open-source implementations of it can be constructed, or if they decide to scrap it and adopt an open published DRM scheme from some standards group, I’d be a believer. Right now, though, from the little I know of it, it looks like just another proprietary DRM scheme that will further fragment the eBabel market.
Bill, my own preference would be open-source everything. The question is, “Will the content owners go along?” And will open-source be more secure vs. the alternative? Those are issues for the standards-setters–including you, if you’re interested–to settle. As an end user, I like the functionality of the OSoft approach. But I’m open to open source as well. Anyway, I can see a number of possibilities ranging from OSoft’s system to a good interoperable approach, involving different products.
The former could happen under the strict supervision of outside techies and the publishing industry, with costs kept to a minimum and opportunities for other companies to profit. Just keep in mind us end uers. I’m sick of machine-oriented DRM. Come up with a good open source technique using OSoft’s approach and just as user-friendly and reliable, and count me in–after there’s a consensus on its merits.
One way or another, OpenReader needs to avoid the present mess. I don’t trust the IDPF to be objective–not with ETI chairing both the container and format groups. That’s why we need for things to happen under OASIS-style rules with a greater range of standards setters involved than the IDPF wants.
Whether the end result is OSoft’s system or another, the end product will be far, far superior to anything that IDPF could cook up. I think the publishers eventually will go along, tearing down the Tower of eBabel once and for all. It’s plain dangerous for them to rely on either the IDPF or, say, Adobe–which as you know has had its share of security-related problems. Whatever system is chosen needs to be tire-kicked by appropriate experts, who, if need be, can sign NDAs. Again, however, I’d love for the system to be open if security can be maintained. Let the standards setters answer that question once and for all.
Some answers to specific points:
Bill: “I’m talking about using proprietary DRM to create a ‘locked’ book format, one that only ‘your’ reader (or one from one of your licensees) can open.”
Me: There will be no single reader for OpenReader. FBReader plans to be able to read us, and that’s terrific. I hope more implementers will join in. Want a BillReader to read OpenReader? Jon can help. Beyond that, keep in mind that OSoft’s dotReader does not require the use of DRM system. That’s optional.
So what about DRM for publishers insisting on it, as most of the big houses do? If OSoft wanted its DRM system to be standard and if the standards setters agreed, the standard setters could dictate the business terms to protect the licensees and also make the terms much easier on publishers than the alternatives with which Adobe would love to saddle us. Otherwise, no go. I also wonder about the possibility of foundations or the publishing industry buying up the technology, so that an industry organization rather than OSoft owns it. Again, this is assuming that the OSoft standard holds up against alternatives. We don’t know who’ll win.
Bill: “I fail to see why locking up books as a result of bowing to business pressure from business partners should for some reason be seen as more virtuous than locking up books for other reasons.”
In details above and earlier, I’ve explained the considerable differences. A Microsoft-style lockup not! OSoft does not want to administer the DRM. And who’s bowing to business pressures? OSoft has a very user-friendly system, the reason for my interest. Plus, I’m saying that it’s the standards setters who’ll decide, acting under OASIS rules–with a number of people involved. That’s the problem with the IDPF approach. ETI and Adobe are dominating.
Bill: “Won’t a consumer who buys one of these DRM’ed dotReader books be similarly locked out of their purchased content?”
If it’s a standard–and for the nth time I would advise standards setter to consider alternatives as well and impose stringent conditions on OSoft, including the availability of the technology to most anyone–where is the lock-out? Especially if the system is used with the understanding that consumers are guarateed access to their books. OSoft’s position already is, “You buy it, you own it.”
Bill: “What’s the effective difference between this and any other proprietary DRM scheme? Where’s the solution to your tower of eBabel here?”
Me: A standard in this case needs to mean one tongue blessed by a standards body–whether it wants OSoft’s DRM or another solution. Couldn’t be simpler.
By the way, Bill, in case you haven’t noticed, OSoft’s reader can be made to read most anything XMLish, including a BillReader. So if the IDPF wins out instead of OpenReader, it isn’t as if OSoft will be history. Of course, that would still leave open the DRM issue. I highly doubt that Adobe’s rates would be as attractive to publishers as OSoft’s will, especially under the arrangements I’ve mentioned if the OSoft system wins out.
Once again, Bill, the operative word is “if.” Please don’t distort OpenReader’s position or my own by saying we think that the OSoft approach is the only option. Absolutely false. It’s just one of a bunch to be considered. Ideally this note has repeated “if” enough for you.
Thanks,
David
As you say, “if” is the key word here.
If OSoft adopts an open standard (as you note earlier, not all standards bodies are created equal, and many standards, particularly for DRM, are not open), or if they publish their own DRM scheme with sufficient detail for a third party to produce a compatible reader, I’ll believe it. Otherwise, it has to be assumed to be mere marketing-speak, I’m afraid.
I thought that was clear. OSoft is bowing to them, by adding DRM, in order to get material to publish from the publish from the publishing houses. (That’s a weird sentence, isn’t it? Perhaps OSoft is better considered as a printer or distributor?)
It’s not a standard, though, so your argument is irrelevant. Right now, it’s their own secret proprietary scheme, just like Microsoft’s own secret proprietary scheme. Right now, there is no open standard for DRM. In fact, on technical grounds, I doubt whether such a standard can be constructed in any cost-effective manner.
David, you’re shifting ground here. We were talking about dotReader, with its own proprietary “dotReader format” (OpenReader with OSoft’s proprietary DRM scheme), and how (in the DRM mode that publishers demand of OSoft) it will contribute yet another chord to the eBabel cacaphony.
Bill: “If OSoft adopts an open standard (as you note earlier, not all standards bodies are created equal, and many standards, particularly for DRM, are not open), or if they publish their own DRM scheme with sufficient detail for a third party to produce a compatible reader, I’ll believe it.
Me: As noted, I’d prefer an open standard. But if the standards setters decide that isn’t the way to go, I’ve also outlined ways to protect the interests of publishers and users. The IDPF approach would not do that. Why are you spending so much time critiquing OpenReader without considering the far less attractive alternatives? Again, however, I’d love an open approach if it’s possible.
Bill: “And who’s bowing to business pressures? I thought that was clear. OSoft is bowing to them, by adding DRM, in order to get material to publish from the publish from the publishing houses. ”
Me: Try talking to publishers without mentioning the D word. They’ll just turn to the far-less-consumer-friendly IDPF approach if we don’t offer a DRM solution. Without DRM as an option, a standard in the real world of big pubishing can’t be a standard for those people, alas. Let’s stop pretending that it can.
Bill: “(That’s a weird sentence, isn’t it? Perhaps OSoft is better considered as a printer or distributor?)”
Me: Nope, that’s the point–it want to see others administer DRM.
Bill: “…It’s not a standard, though, so your argument is irrelevant. Right now, it’s their own secret proprietary scheme, just like Microsoft’s own secret proprietary scheme.”
Me: But shouldn’t the standards setters have a right to evaluate OSoft’s approach along with others? Why are you discriminating against OSoft, which would be willing to show far, far more flexibility than competitors. No good deed…
Bill: “Right now, there is no open standard for DRM. In fact, on technical grounds, I doubt whether such a standard can be constructed in any cost-effective manner.”
Me: Hmm. So you’re saying to forget about DRM standards and thus, in effect, continue the Tower of eBabel? As an eBabel victim, I’d hope you’d empathize more with readers. Bottom line: Without OpenReader involved, IDPF will end up with a closed standard or standards without the protections that OpenReader wants for publishers and readers.
Bill: “Bill: ‘I’m talking about using proprietary DRM to create a ‘locked’ book format, one that only ‘your’ reader (or one from one of your licensees) can open’ ‘Me: There will be no single reader for OpenReader.’ David, you’re shifting ground here. We were talking about dotReader, with its own proprietary “dotReader format” (OpenReader with OSoft’s proprietary DRM scheme), and how (in the DRM mode that publishers demand of OSoft) it will contribute yet another chord to the eBabel cacaphony. ”
Me: Heck, Bill, you’re the one who seemed to be blurring the difference between the reader and the format. As I’ve said, we want other readers to be involved, and the DRM is optional. If the standards setters adopt OSoft’s system, then, as I keep saying, we want safeguards in place that the IDPF won’t offer. And if instead the standards setters adopt an open approach instead, that would be great as well. Whatever’s best for publishers and consumers.
Meanwhile I’ll await your similarly skeptical analysis of the IDPF approach.
Thanks,
David
David, I don’t think I’m the one pretending here. I completely agree that DRM is going to be required by publishers, even though the OpenReader folks may, I think somewhat disingenuously, call it “optional”. But what that means is that dotReader (and OpenReader) is a solution to nothing much (though of course OSoft has good business reasons to create dotReader). Even if the books are published as “OpenReader Inside”, they will be coated with opaque DRM which will make them functionally equivalent to current Microsoft Reader books (which are, after all, OEBPS “inside”). By adding another DRM scheme, one might reasonably think that OSoft actually makes the eBabel problem worse, rather than better. By adding another ebook format, one might reasonably think that OpenReader actually makes the problem worse, rather than better.
By contrast, the IDPF efforts seem to be the work of a more-or-less real standards body. (Yes, it’s not the IETF or the ISO, and I realize you’re somewhat unhappy with the results of recent elections.) However, thanks to efforts by Jon and others, they seem to be on the verge of a container specification. If they follow through and produce a half-way reasonable ebook content specification, there might be a chance for the confusion of formats to be at least somewhat reduced. Designs produced by standards committees, of course, typically incorporate a great deal of compromise, and usually are somewhat technically uninspiring, sometimes fatally so. An alternative is to do what Adobe did with PDF — produce your own proprietary but open design, make it popular, then get a standards body to endorse it (PDF/A) down the road, because everyone is using it.
But I think we’ve gotten far enough down a comment thread on a review of the Pepper Pad..
Bill, this is a hoot. IDPF has ETI chairing both the container and format committees, and you’re letting people think they’re trustworthy as a standards group? Meanwhile I’m kinda amused that you’re cutting the IDPF so much slack on the eBook Community list. You’ve never really answered the questions I’m raising about the diversity–or lack of diversity–of the IDPF standards setters. Publishers should be involved. But so should diverse technical people, ideally from outside the e-book biz, so the publishers don’t just trust ETI and Adobe, etc. As for OpenReader and dotReaders, I think my earlier answers are pretty responsive. I’ve described in detail how the OpenReader approach will differ from the IDPF approach. Thanks. David