image No one is a bigger booster of the ePub standard than I am. E-books need to be audio-CD-simple.

Right now, however, ePub isn’t the solution for every book, especially those with tens of megabytes of images that need to be displayed precisely.

Some publishers doing ePub are correctly making exceptions of works with production challenges. On both the standards side and the app side, tech people still have plenty of work ahead.

Great for textish books, not the best for graphics variety

Often, of course, it’s often no problem if e-layouts deviate from p-layouts. This is the Web era of reflowable text, where reader pleasure should come out of designer mandates. But sometimes this-here layout issue can get out of hand. For example, images might spill over on other pages in ways that slow down your reading of a book. Small wonder that Wowio, with so many graphic novels and other image-rich works to display, has not yet switched over to ePub. What’s more, at least with some ePub apps, image-filled books may take longer to load than with the PDF approach, and the software may not be as responsive as with PDF apps. I’m not sure how much of this is an app problem and how much is the standard itself.

Textish books: A different story

image Books that are overwhelmingly text? No problem in the overwhelming majority of cases! In fact, ePub is sleeker than PDF, and I’d encourage publishers to follow the example of Hatchette and make ePub a standard. Textish ePub books will be less of a challenge to display on small, low-powered devices with little screens.

Our Three Shadows torture test

Meanwhile, however, a rightly vexed Mike Cane complained to me of the hassles he suffered when he downloaded TOR’s free ePub edition of Three Shadowsby former Disney animator Cyril Pedrosa—for viewing in Sony’s eBook Library software. I tried it. Keep going, and you’ll see the PDF version of this graphic novel in Adobe Reader 8, the ePub in Adobe Digital Editions and the ePub in Sony’s eBook Library program. Yes, the PDF version is almost surely closer to the layout in the actual book.


Adobe Reader 8 above – PDF (I didn’t trim to the image). I’ve added the shadow at the borders.


Adobe Digital Editions above – ePUB. Notice? The first image seen in the PDF version is missing here. It’s on an earlier page, a spillover.


Sony eBook Library  above – ePUB. Same problems as with Digital Editions. The eBook Library is a desktop program. Don’t even think of trying this on your Sony Reader, at least if you value your time. Of course, I suspect that the PDF version wouldn’t load in a flash, either.


  1. For these types of graphic books, the jpeg-book is just fine. is there some way PDF beats the jpeg-book? Only if there is a good deal of text that can be compressed and rendered as vectors.

    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.

  2. epub is pretty much pain old html(okey xhtml) in a zip container with some added metadata, run a unzip on a unDRM’ed epub and your browser will read it just fine.

    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…

  3. As a packaging format, OPF with OCF should work perfectly for graphic novels, manga etc…

    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.

  4. I tried this in Bookworm and it’s too large to go up via web file upload (it would take quite some time to upload anyway, as most people have fairly slow upload connections at home).

    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.)

  5. Liza and Hadrien make excellent points.

    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/>

  6. I’ve been reading the specs once again:

    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.

  7. Good points, Hadrien.

    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!

  8. The problem here is that epub standard allow you to do things that make even the most common popular clients display the book in a troubling way. like i wrote before using more chapters and grouping each page as one image could have solved most of the practical problems.

    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.

  9. What is the best method for converting a graphic novel into the epub format?…

    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…

The TeleRead community values your civil and thoughtful comments. We use a cache, so expect a delay. Problems? E-mail