The Pros and Cons of Single-EPUB Workflows

Expert publishing blog opinions are solely those of the blogger and not necessarily endorsed by DBW.

EPUB digital ebook production workflowMany publishers and ebook creation companies strive to create a single EPUB file they can deliver to all of the different retailers, rather than producing different files for each one.

While there are pros and cons to this approach to ebook production, my own view is that the pros outweigh the cons. But first, here’s a look at the more common points on both sides of the discussion.

The Pros:

  1. Creating one EPUB file often reduces production time, keeping costs down. Production costs are the main factor in this decision since most publishers are limited by the bottom line on ebook production.
  2. Some publishers only assign one ISBN to all of their ebook files, and that is a little bit easier to track when you create only one EPUB as well. I won’t get into the potential issues with assigning one ISBN to ebook files in this post, but it is worth noting that this is a common practice.

The Cons:

  1. While it is true that creating one file saves some production time, most publishers still aren’t doing enough quality assurance on their ebook files, regardless of how many they create. So a single EPUB workflow is not increasing the quality of EPUB files, even if it’s helping to generate them faster.
  2. Kindle Format 8 is much closer to the EPUB 2 and EPUB 3 standards than Mobipocket 7 was, but KF8 is still not the same thing as EPUB. Amazon has doubled down on its own proprietary format (for good reasons that I can explain in another post), and I don’t see that changing anytime in the near future. This means that a single-source EPUB has to accommodate the differences that come with a Kindle conversion without negatively affecting the display of the file on EPUB devices. This can be hard to accomplish, and some publishers just give up, again letting quality slip as a result.
  3. At the same time, EPUB support across devices is not as consistent as everyone would like it to be, either. Yes, the other major ebook retailers do sell EPUB files, but their support for specific features and styling will always depend on what they think their users want to see and how much time and money they can spend on reading system improvements. The test results at EPUBtest.org show just how inconsistent the different reading systems are in this area. Even when the retailers all support something, it is not always supported in the same way.
  4. Fixed-layout ebooks cannot be created in a single format. Amazon and Barnes & Noble have their own proprietary formats for fixed-layout content, and EPUB 3 support is not always consistent in Apple, Kobo and Google. Even if you do create one EPUB for reflowable content, you can’t get away with that in fixed-layout development.

While there are a lot of potential problems with the single-file workflow, it still gets my vote for the majority of content.

My normal recommendation is to start with well-formed EPUB files with semantic, accessible HTML code and solid CSS that doesn’t rely on a lot of complex tricks or formatting irregularities. With that foundation in place, most ebook developers will find that creating a single reflowable EPUB that works on all or most devices is much easier to accomplish.

Regardless of how you create your files, though, you need to test them thoroughly before you send them out to distribution. Quality assurance is arguably the most important part of any ebook creation workflow, and we will talk a lot about that in this column in the future. In the meantime: test, test, test!

10 thoughts on “The Pros and Cons of Single-EPUB Workflows

  1. Anthony Levings

    One of the main things holding me back from a single EPUB approach has been pop-up notes, which are near essential in academic books. iBooks uses asides and while I’ve heard others tell me that combining asides with a vanilla approach to notes works I’ve held back on doing this for fear that it might break the Kindle’s pop-up notes or have consequences in certain ereaders.

    Reply
    1. Joshua Tallent

      Anthony,

      Thanks for your thoughts! I don’t think there is any problem with using asides for Kindle notes. As a matter of fact, as far as I know, using an aside with epub:type attributes and two-way linking should work on all of the reading systems that support pop-ups, as well as on all of the ones that don’t. Good luck!

      Joshua

      Reply
  2. Bill Kasdorf

    Good post, Joshua, and I agree with everything you said. I just want to point out one common and useful variant. Even when files need to be tweaked to adapt to the requirements and limitations of certain reading systems (a bigger issue the more complex your ebooks are), it is still far and away the best practice to _start with an EPUB 3_ and then just tweak that for the needed variations. And that EPUB 3 should have fallbacks for things that may work in one reading system and not in another, to minimize the amount of tweaking and management of multiple versions needed.

    Reply
  3. Joshua Tallent

    Thanks, Bill! That is a point that I definitely should have made more clear, and is certainly one that everyone should consider. A well-formed EPUB 3 file is a perfect foundation for any variant EPUB or Kindle files you have to create. Start with the best, then water down as needed.

    Reply
  4. Ori Idan

    I think that single eBook for all retailers is the way to go. Creating a separate eBook for each retailer causes a lot of work and may lead to errors.
    We have a set of automatic tools that change details such as metadata and even add specific pages for each publisher.

    Reply
  5. Chas Newport

    This may seem a bit off topic but please bear with me. I noticed EPUB files are significantly smaller than mobi files (both compiled from Scrivener). The EPUB file is only a little bigger than the bare project template with the image file sizes added on at 588KB , presumably there’s a bit of XML to structure it all. A mobi from kindlegen is nearly three times the size at 1.6MB… apparently to do with storing several formats inside it with embedded fonts.

    I’m trying to find out whether my download charges are based on the EPUB size or the bloated mobi they create during conversion… I’ve asked Amazon but based on previous experience I may not get straight answer.

    Do you guys know the answer?

    Reply
  6. Chas Newport

    This may seem a bit off topic but please bear with me. I noticed EPUB files are significantly smaller than mobi files (both compiled from Scrivener). The EPUB file is only a little bigger than the bare project template with the image file sizes added on at 588KB , presumably there’s a bit of XML to structure it all. A mobi from kindlegen is nearly three times the size at 1.6MB… apparently to do with storing several formats inside it with embedded fonts.

    I’m trying to find out whether my download charges are based on the EPUB size or the bloated mobi they create during conversion… I’ve asked Amazon but based on previous experience I may not get straight answer.

    Do you guys know the answer?

    Reply
    1. Rob Siders

      My testing shows, and client feedback confirms, that Amazon calculates the download fee based on whatever the deliverable file size Kindlegen reports after running. In most cases, it’s roughly the same size as an epub version. You can verify the delivery fee on the Step 2: Rights & Pricing page at KDP. Divide the total in the Delivery Fee column by $0.15 to determine the file size Amazon considers the mobi file to be.

      Reply
  7. Joshua Tallent

    Chas,

    Yes, the .mobi file is usually larger than the EPUB because of how it is compiled by KindleGen. I have heard varying reports on how Amazon calculates the cost of their download fee, but my best recommendation to get around that is to just give Amazon the EPUB file, not a .mobi.

    I am not sure if Scrivener does anything specific in building its Kindle file, and I’m not even sure if it uses the official KindleGen compiler since Amazon does not usually license that for inclusion in other tools. However, if you run the EPUB through KindleGen yourself (or use Kindle Previewer to do it) then you can test whether the auto-converted EPUB file will work. If so, upload the EPUB to KDP and you’re good to go. If not, tweak the EPUB code and try again.

    Good luck!
    Joshua

    Reply
  8. Michael W. Perry

    I’m behind Adobe, InDesign, and the Creative Cloud on this one. I’m insisting on a one-document workflow, with InDesign creating the print edition along with the fixed and reflowable epub editions. That’s one content with the only tweaks easy ones such as replacing b&w graphics with color for epub. ID’s fixed format works with iBooks. If B&N and Kobo want similar versions, they can make sure they’re also compliant with what ID exports. Otherwise, they don’t get that format.

    Amazon, insisting on playing the proprietary game, gets the left-overs. I handle reflowable by sending them an epub file. For my next book, I’ll see if their scheme for using PDF for fixed layout works. If not, they’re out of luck. I’m not going to take the advice one Kindle rep gave me and spend hundreds of dollars having a third-party firm format a fixed layout book for Amazon, particularly not when Amazon could quite easily assist Adobe in developing Kindle mobi and KF8 export for inDesign. After all, Amazon’s Seattle headquarters are only about a 10-minute drive from where Adobe develops InDesign.

    In short, I’m insisting on fairness and good sense. Thousands of publishers and independent authors shouldn’t have to diddle with formatting quirks for each particular retailer and ebook, when all these problems can be solved by perhaps a half-dozen large retailers supporting those standards with their readers. The few should make life easy for the many.
    ——
    And that doesn’t mean I’m a fan of epub either. Whoever set the specs for it seems clueless about how reflowable ebooks should be configured for devices that vary enormously in their screen display.

    If the epub gurus want to know how reflowable ought to be done, they should look at what Framemaker has offered since the late 1980s. It’d designed to handle complex technical documents with numerous illustrations. And because those documents reflow every time material is added or removed, the app does reflowable right. Whatever is throw at it, and companies such as Boeing use it for documents running thousands of pages, it creates an attractive result.

    For instance, graphics and tables don’t simply appear where they come in the text as with epub. That can lead to hideously ugly page breaks. No, those objects can come with a specification that says, for instance, place this picture on the top right of the next page. Those doing the layout can ensure that, however the text flows, the illustrations are attractively placed. And they can do that without a lot of messy hand-coding.

    Epub 3.0 is so-so. Hopefully, epub 4.0 will be better designed.

    –Michael W. Perry

    Reply

COMMENT

Your email address will not be published. Required fields are marked *

*