To not. Really. When I see epub I think “easily reflowing text” I suppose you could wrap a PDF in an epub wrapper, or use epub’s woefully inadequate image handling, but I’d rather you didn’t. The nice thing about PDF is that it is as widely or mor…

It’s not a that new problem you just cant have flexibility without sacrificing predictability it’s well understood in web development and competent web designers can work around it, but it’s not understood widely that you need to do the same with epub if you want the optimal reader experience.

I vaguely recall (thus I may get some details wrong) that the OEBPS Working Group, which developed the specs underlying EPUB, spent portions of a few working group meetings discussing this topic.

Restating the question: should we allow core media types other than XHTML/DTBook content documents (this would primarily be PNG/JPEG/SVG images) to appear in the spine?

There was substantial opposition to opening up the spine to non-content documents, the reasons of which elude me at the moment. At the time, though, the arguments by the content-document-only group were pretty strong, but not strong enough to make it a “slam dunk.”

Since we could not come to unanimous agreement, we erred on the side of exclusion based on the principle: “we can always add support for it later, but if we add it now, and later determine we made a mistake, we can’t remove it.”

(The biggest fear in building complex specs like OPS and OPF is adding some feature we later regret adding since, like a bad haircut or a hated relative, we have to live with it for a while. Thus, when in doubt, it is better to not add the new feature — it can always be added in the future as we learn how the specs are used in the real world, and the feature requests that come in from the users.)

Hadrien, it looks like we may soon start up what we call the “maintenance working group” (I’ve been informally asked if I would consider being the group chair), which essentially is to collect bug reports plus proposed new requirements and features for a future upgrade. When we start that up, I encourage you to submit your bug reports and recommendations, including a request to support non-content-documents in the spine.

Btw, I looked in the OPF spec for the fallback error you mention in your comment and cannot find it. Can you send me, in private e-mail, more information of where that bad example is? Clearly we want to fix all the bugs in the specs!

Each itemref in spine must not reference media types other than OPS Content Documents (or documents whose fallback chain includes an OPS Content Document). An OPS Content Document must be of one of the following media types: application/xhtml+xml, application/x-dtbook+xml, the deprecated text/x-oeb1-document, and Out-Of-Line XML Island (with required fallback.) When a document with a media type not from this list (or a document whose fallback chain doesn’t include a document with a media type from this list) is referenced in spine, Reading Systems must not include it as part of the spine.

As items appearing in the spine must either be OPS Content Documents or items with a fallback chain that includes an OPS Content, it is possible to have a fallback chain for a spine item that “falls over” another OPS Core Media type. For example, a spine itemref could reference a PDF document, that falls back to a PNG image, that in turn falls back to a OPS XHTML Content Document. It is valid for this item to appear in the spine because the fallback chain includes (in this case terminates with) an OPS Content Document.

Obviously, for a graphical novel it’s pretty stupid to create XHTML files. You should be able to directly link to the image files in the spine as long as the images are included in the list of supported media.

While the specs says that you MUST reference to an OPS Content Document, the example used right afterwards use a fallback directly to a PNG (which is an OPS Core Media type).

I do believe that when an itemref references an OPS Core Media type, it shouldn’t be mandatory to add a proper fallback to an OPS Content Document.

ePub is perfectly suited for graphical novels/comics/manga, but the mandatory support of an OPS Content Document makes no sense at all in this case.

In summary, we must not blame the format for the sins of the reading system, and we must not blame the reading system for the sins of the format.

And we certainly must not blame the format and the reading system for the sins of improper authoring!

I find it interesting (and perplexing) that some pan the OPS 2.0 specification because it supports a publication being represented by stitching together multiple content documents. However, for a number of reasons I won’t get into here, this is the strength of OPS (and, as an aside, the Web.)

Anyway, if someone just gotta have all their textual content in a single XHTML document, they are certainly allowed to do that.

Regarding not using epubcheck to check one’s ePub for conformance before release — the Monty Python comfy chair torture (“nobody expects the Spanish Inquisition”) comes to mind. <smile/>

The whole comic is rendered as a single HTML page, which forces page-based reading systems like DE to break the pages arbitrarily, wherever the image boundaries are.

Bookworm actually renders this nicely in my local development version, but it would be a nightmare to read over the web, as the single HTML page loads more than 700 fairly large GIFs.

This could be done correctly in ePub by making each HTML page contain only those images which were in the original source document. So I don’t blame either the reading systems or the standard, but Tor’s implementation.

(It doesn’t pass epubcheck either, for what it’s worth.)

Usually people just zip their images together: well, OCF is a zip file, and in an ePub file you can use JPEG files. Unlike a simple zip file, you can also add metadata and a table of contents to your graphic novel.

ePub is a perfect format for this, the problem is on the reading system side.

The epub packaged directory in question does indeed consist of a folder full of gif’s and the reason it puts a pagebreak where it does is because the top strip is a different imagefile and not actually grouped with the second image.

It’s not well done the file have one chapter file who just have a few 100′eds of “img src” tags means that an unprepared reader(like firefox) might attempt to load all of it to ram at once, it should have been broken up into maybe 20 chapters, or maybe a html file pr page but…

Comics, manga, graphic novels are all best as jpegs in a directory/folder. I believe most of the new, larger ebook devices have built-in picture viewers/browsers.

As for books that are all text, I really question the benefit that epub offers over plain old html 4. As far as I can see, for novels etc, Amazon’s solution is the best: html (a subset of it, actually, but bare-html, that is, the few elements that were original to html, work as well) with two additional elements, one for page-break, and one for start-here (I’m not sure why we need that one, Amazon describes it as the default page that their app will open if the book has not been read).

If we standardize open-content etexts on plain old html, then device makers as well as software apps like fbreader, can subscribe to this. FBreader handles html like a champ, for example, outside of not being able to distinguish blockquotes from plain paragraphs.