the popularity of .pdf is no surprise to people
who have followed the electronic-book world.
every e-book site reports that that's the case.

i don't think very much of the .epub format.
(as you might have already gleaned by now.)

but in a contest between .pdf and mobipocket,
i would choose .epub over either one of those,
because it's a much easier format to repurpose.

once you unzip an .epub, you've got .xml+.css,
and thus access to the formatted and styled text.

so it's no wonder .epub is gaining in downloads.

(although there is a rich comic irony that the rise
in .epub downloads is undoubtedly due to stanza,
a program that strips all the formatting and styling
from the file and displays it in a bare-bones state.
one wonders how long the novelty of that will last.)

but if you offered your e-books instead as .html
-- especially without chopping them into pieces,
which seems to be "necessary" with .epub files --
i bet you'd find that to be the most popular format.

e-book people have had to learn to do conversions,
so they appreciate the format that makes 'em easy;
these days, the rosetta stone continues to be .html.

-bowerbird

The challenge with offering HTML is that you need to figure out what to do with the file structure and images (plenty of opinions of how to chunk -- one big file? break into chapters? sections?). I'm not suggesting EPUB is perfect by any means, but it packages up the HTML in a reasonable way. Putting EPUB into Bookworm is a nice way to get at the HTML content (via browser and mobile) w/o needing to manually manage the unzipping.

andrew said:
> The challenge with offering HTML is that
> you need to figure out what to do with the file structure
> and images (plenty of opinions of how to chunk --
> one big file? break into chapters? sections?).

i believe we need a master-format that allows the _users_
to decide how to "chunk" the file, for their own purposes...

_and_ lets 'em customize output to their own preferences --
concerning fonts, sizes, colors, leading, margins, and so on
-- plus the _nature_ of that output (e.g., kindle, pdf, etc.)...

that's the type of capability my format will be offering them.
so if your format cannot do the same, why should i adopt it?

> I'm not suggesting EPUB is perfect by any means,
> but it packages up the HTML in a reasonable way.

um, am i missing something here? .epub _zips_ the files;
that's not some mystic process you couldn't do otherwise.

the "manifest" file is equally unnecessary, since you _can_
put the links among the various files right into the .html...

(indeed, the absence of all these inter-file links is a huge
shortcoming when a person does repurpose an .epub file.)

-bowerbird

There's nothing about ePub as a specification that dictates how the content should be chunked. You can stick all of Proust in a single XHTML 1.1 file and still produce a valid ePub.

There are implementations which limit individual viewable chunks to

However, it is a reality that limited memory/bandwidth devices are not going to be able to ingest a 1M+ file at once. As a reader, I would prefer that a human make the decision about where to break up that content, rather than a device which may simply split arbitrarily.

Bookworm imposes no limitations at all on file size, but if you try to read a 10M text file in a web browser you are going to be pretty sad about it.

liza, you seem to be saying it's not the fault of the _format_,
but rather the _implementations_. but then you report that
it's a "reality" that "limited memory/bandwidth" is to blame.

sounds confusing... fingers pointing every which way...

what is _not_ confusing is that adobe recommends that
anyone creating .epub for its viewer-program chop it up.

i think we should design our format such that even devices
which are limited in memory or bandwidth are still able to
handle even books as large as -- for example -- 4 megs
(which is the size of the king james bible over at p.g.)...

all _without_ any "human" having to make _any_ decisions.

-bowerbird