1) Provides the binding mechanism (OCF uses ZIP).

2) Organizes the content useful for publication distribution purposes (OCF specifies the META-INF/container.xml document).

The real “magic” of OCF is the second item, while the first is simply “mechanics”.

Thus one can imagine repackaging the OCF specified files into MHTML. And of course the same for our proposed GCF.

It is hardly correct to say that Google’s Book Search has us reading PDFs (PDFs are available from Google but with GBS we are reading JPEGs with the help of a database, PDFs are there purely for the convenience of printers) and he seems to be suggesting that going with the Web means going with texts as HTML. This is just not what Google and Amazon are doing. Google and Amazon get their power and their reach by putting all texts into a database system…….

I agree that HTML is NOT synonomous with reading at the desktop. Increasingly, just about every device with a screen (or device which can be hooked to a screen) will have an HTML interface. (I remember fighting battles in the 1990s about why network equipment should include web services for management)

Also, smart devices will be able to render HTML in a way consistent with the strengths of the device. After all, that was part of the point of HTML, to separate content from formatting and to let the browser handle formatting in a way that meets the user’s needs.

This is one reason I offer HTML books. However, we don’t live in an always connected world and even for those of us who are always connected, we may share David’s concern for being able to archive our purchases in case the publisher or distributor goes away. And while HTML files can be saved, graphics tend to go funky. Which, I think, is part of the justification for the package idea–all of the parts of the document will be there together. (The other part, as I understand it, is so that eBooks can be used with DRM–something which is already fully discussed on TeleRead).

While I don’t agree with everything Aaron says, I absolutely agree that the more we can start with HTML and figure what we need to add, rather than starting with PDF or anything else, the more universal a reading experience we can offer.

http://www.unmht.org/unmht/en_index.html

That is the crux of the matter, right there. Having my ebooks, my music, my personal data, my word processing documents, etc. only available via an internet connection is a major problem. What if I am using a device that doesn’t have internet connectivity? What if I am in a location that doesn’t have this ubiquitous internet “cloud” you are talking about (which is quite a few places)?

Beyond the connectivity issues, there are concerns over who is controlling my access to “my” data if it is all online. Policies change, companies go out of business, governments change laws (and sometimes circumvent the law). I am not willing to place myself at the mercy of all of these entities and circumstances, over which I have no control, just to read a book that I have paid for. If you are, that is your decision.

Until we all live in some future Star Trek utopia, I prefer to be responsible for my own digital information, thank you.

One thing is clear: browsers do have most of the capabilities needed for a digital publication reading application including the most important and difficult one to implement: taking XML and splashing the content on the screen in a readable manner.

Two deficiencies with browser reading of digital publication content which ePub fills are 1) single file distribution (hard to argue against), and 2) publication metadata/organization provided by the OPF Package (this is pretty important from several angles – the “web site” paradigm does not include the concept of a Package which is biggest innovation that OEBPS provided to e-bookdom.)

Regarding single file distribution of a “web site”, one could certainly now use MHTML (which Bill Janssen has suggested) which I believe IE supports pretty well (Firefox and Opera support is more problematic so I’m led to believe, especially for running scripts which of course is what a lot of people here love about web content and hate about ePub.)

Alternatively, last year three of us proposed a ZIP-based container for “web content”, compatible with the IDPF OCF container, called the “Generalized Container Format” (GCF).

It was our vision that GCF be used for distributing digital publications (like e-books) directly viewable in browsers “as is”. We envisioned that plug-ins would be developed for browsers like IE, Mozilla/Firefox, Opera, etc. These plug-ins would locally unzip the GCF container and render the web content inside.

GCF may even be used to seamlessly distribute different renditions (formats) of the same publication, such as “browser-ready”, OPS (ePub), Mobipocket, PDF, LIT, etc., thus being a “catch all” container for a variety of formats – a “super” ePub, if you will.

So this is offered as a pathway that is quite compatible with ePub. On a related note, I recently posted to the ePub Community some thoughts on an ePub to “web site” converter. The power of ePub is that it is flexible and high-fidelity, capable of ready conversion into other formats, including a functioning “web site” which is immediately browser renderable.

I don’t see this proposal as competitive with ePub, but rather supportive. After all, what is important is that our digital publication future embrace formatting the publication content in XML documents within a general organizational framework. What those who don’t understand the technical intricacies of ePub fail to realize is that the gap for web browsers to directly render ePub is quite small, and so once web browsers can take a GCF and render the web content inside, the jump to directly rendering ePub becomes even narrower.

I’m sorry, but human nature suggests that the future will look less like Star Trek (’Computer, what is the location of David Rothman at this time?’) and more like the bloody century just past. Is it possible to utilize modern technology and live off the grid at the same time?

…the IDPF is peddling a format that search engines can’t index, browsers can’t natively open, and experienced web developers can’t figure out.

The format seems to have been designed without thinking about the impact of the Web, and Web 2.0 in particular (by which I mean Javascript apps running in Web browsers). In fact, it looks like it was designed by a bunch of folks who didn’t realize that the “future of ebooks” envisioned in 1996 didn’t actually turn out that way, people who believed that downloadable read-offline files for custom reading hardware were the holy grail of ebook formats, despite all evidence to the contrary.

Aaron, you have your web-sentric view of things, which is fine. The web is useful for many things, but I don’t think book reading is one of them. I also don’t think that having all your software as a “web app” is a smart idea either. (You didn’t mention this, but it fits the same argument).

You say “there’s skepticism and even contempt for the idea of reading a book in a browser.” This may be true, but your articles leave me with the impression that you are equally skeptical and contemptuous of non-web reading (epub in particular). You also say “In this space, there’s an aggressive need to defend one’s turf.” Well, it seems to me that you are doing the same.

You may have some good ideas about some of these issues, but of the two recent articles that you have posted here, all I see is critisism about epub and drum-beating about a web-only solution, which coincidentally, you have adopted. If this assesment sounds unfair to you, perhaps it is due to the tone of your articles. Maybe you need to rethink how you are presenting your arguments.

I think constant web access does not necessarily imply that one is using a desktop computer.
It can be a laptop or some other gadget.
The trend is for all devices to be connected all the time.
e.g. the amazon Kindle has an experimental browser – under the hood I believe

David,
what’s this possession mania ?
I think the best redundancy for “keeping it forever” is provided by the cloud.
I think we need to distinguish between
- a person being able to access his/her collection anywhere anytime
- archival of literature
I think you care about the former.
So what’s wrong with the content being online?
Nothing. What do you care if it’s coming over the wire or coming from a magnetic disk. As long as it’s coming…

Keeping it forever and using it on a variety of machines and OSes.

As for PDF, yep, it sucks. I want reflow at the consumer level.

Thanks,
David

We really need to make the distinction of reading for pleasure and reading because you have too. They are very separate and need to be approached differently.

Reading how-to, technical articles for research is one thing; but, if you are talking reading for pleasure, at least for the foreseeable future, the desktop is not the first choice.

That’s the biggest missing ingredient to the arguments over ebooks at the moment that people are not grasping in my opinion – not seeing the difference between “informational” reading (blogs, on-line newspapers, e-mail, Google searches, RSS feeds) and “choosing” to read for pleasure.

There is a whole wide world of diffence in those two usage scenarios.

Great article. I totally agree.

David, what does “owning a file” mean?
Let me tell you about my CD collection. I don’t listen to them very often because it takes too mcuh time to walk across the living room and grab one. They don’t even have the value they used to. They get scratched. Instead I just go online and download the entire discography of my favorite bands. (In Canada it’s legal.)
How long until you’ll feel the same about your books?

The time and efforts would be more worthwhile if we moved every book ever written online, into the “cloud”.

I think all we need to focus on is
- better typography on the web
- better creation tools

One last thought:
For off-line reading PDF format is superb. Reflow is overrated. It can happen at the time when the content is converted to PDF format. (”choose the font-size you want!”)
… and that’s pretty much it