Google Play Books Doesn’t Support Epub, and Other Crazy Possibilities

Epub Chimeric[1]advocates like to pretend that it's an industry standard format, but that's not completely true.

Kobo (to name one example) adds their own nonstandard components to the files they sell, Apple prefers their own bastardized form of Epub3 ( iBooks) and uses a proprietary DRM, and then there's the fact that no vendor actually supports the complete Epub3 spec.

And now it seems we can add Google to the mix. A reader has tipped me to the news that Google Play Books doesn't actually display Epub. Sure, Google will let users upload Epub files, and they maintain a pretense of selling Epub, but their reading apps apparently Do Not Display Epub files when you are reading an ebook.

I learned of this oddity from Ben Hollingum, an ebook developer based in London. He detailed the quirk on his blog a couple days ago:

Most e-readers ruin your books by not recognising certain CSS declarations, overriding them with their own defaults, or by implementing your CSS in a freakishly non-standard way – not so Google Play Books. The part of Google Play Books that handles CSS stylesheets – presumably forked from the Chrome browser – seems to be excellent, it can understand complex pseudo-class selectors and parse combinations of pseudo-class and pseudo-element selectors with ease. The problem comes from the way that it handles the HTML framework onto which that CSS is applied.

This first became apparent to me when I loaded one of the books I was working on into Google Play Books. This book had drop-caps on the opening body-text paragraphs of each chapter. These were identified using an HTML class (p.first) and a pseudo-element selector (::first-letter). I did it this way because it allowed swanky modern systems like iBooks and Readium to display drop-caps, but phrased it in such a way that Adobe Digital Editions and similar readers (which always render drop-caps wrong) would ignore it (pseudo elements mean nothing to them).

When I loaded this book into Google Play books I noticed something odd. In addition to the drop cap on the first paragraph (which rendered very nicely), it added a drop cap to the first letter of the following page (the page break having fallen halfway through the first para). This seemed to imply that Google Play Books was altering my HTML in real-time (it reacted to changes in font-size and line-height that moved the page break), adding in a hard paragraph break on either side of the page break.

Ben goes on to explain the steps to confirm this strange behavior, eventually ending with:

Intrigued, I added another layer to my selector. I changed it to body>div.text>p:first-of-type::first-letter this absurdly convoluted selector should, in theory, have selected only the first letter of the first paragraph of the first div in the whole HTML document. What it actually did was select the first letter of each page.

This seems to imply that in order to render a book, Google Play Books takes the content from your epub and pastes it into an individual HTML document for each page. To make it even stranger, in order to work out where to put the page breaks it must have to apply the CSS to the HTML first, then work out where the page breaks will fall, then chop up the HTML into individual documents and re-apply the CSS. Only after it has gone through all that can it render the page.

Based on this behavior Ben has awarded the title of "weirdest epub rendering engine" to Google Play Books.

If his report is correct then it will most definitely deserve the title, but unfortunately for me I have not yet managed to confirm Ben's claims.

I don't think I know anyone (other than Ben) who has looked closely enough at GPB to have noticed this strange behavior, and I didn't get a response to my tweet yesterday. It had an #eprdctn tag attached, so I thought it would get some attention, but aside from a single retweet I have not gotten even a nibble.

And so I am throwing this story on to the blog just to see what happens. If anyone can confirm or deny this story, please let me know.

--

In spite of the lack of evidence, I have to say that this report rings true.

This report is consistent with Google requiring that you upload an ePub before downloading it and reading it in the Google Play Books app, and it offers the best explanation for Tom Semple's remark that GPB only downloads a fragment of an ebook at a time. It would also explain why GPB didn't support 3rd-party ebooks until the middle of last year.

All of those quirks can be explained by the simple supposition that the Google Play Books app for Android doesn't actually support Epub. Instead it appears to be using some type of concealed intermediary file format of unknown design to serve up fragments of an ebook.

P.S. If anyone knows of a best practices FAQ for GPB, please don't hesitate to share a link. I want to see what it says.

P.P.S. In a way, this quirky non-Epub behavior might be caused by Google Play Books' early history. While Google focuses support on Epub now, there was a time when they would let authors and publishers upload just about any type of file to be sold in Google's ebookstore. This included RTF, PDF, PDB, XML, DOC, and even Mobipocket (I kid you not).

The behavior reported by Ben could be the result of some Googler's kludged together attempt to support all those disparate file formats in a consistent manner. I don't know why they didn't just convert to Epub, but I suppose at some point this chimeric file made sense. Or maybe they didn't have enough time to get it right, I don't know.

image credit Heidi Taillefer

25 thoughts on “Google Play Books Doesn’t Support Epub, and Other Crazy Possibilities

  1. I completely ignore Google Play Books so I have no idea how it works. I thought it was just another generic adept store stocked by the BPHs and, maybe, smashwords.
    Now I’m wondering, what do you get when you download a book off GPB?
    Do you get an epub you can open with, say, Aldiko or ADE?
    Does it depend on how you download it or where you download it?

    Maybe GPB is a walled garden, too?
    Or a half-n-halfer like Kobo?

    1. GPB is probably more like Kobo. It is designed to be cloud based in that you normally don’t ever download the whole book, although you can “pin” it so you can read offline in which case it does download the whole book, but NOT in any place or format you can get to with other apps like Aldiko or ADE. But, you can download an epub from them that you can load in whatever you like, but I’m not sure if I could do this directly on my Android phone/tablet or not as I’ve only ever done it on a computer then added to my Calibre library. They do a similiar thing with their google play music.

  2. I just wanted to chime in about something different. Google Play’s royalties for authors and publishers was pretty crappy, so I never bothered.

    Support for pseudo-selectors has been spotty on all platforms (though I’ve recently heard it unofficially renders on KF8 devices). I’ve learned the hard way that testing in browsers is not always the best way to see how they render in ebooks.

    As an aside, let me say that it always amazes me how much time is spent trying to get drop caps to work on any platform. I’ve never been able to do it well in more than one platform….

  3. While I started rabble rousing here on Apple’s case, the bottom line is e-readers are just not the way to go long-term. E-readers, regardless of the format, are just a new form of a walled garden leaving users at the mercy of the hardware developers or the limitations of the software coders. Why take something from a fully capable HTML5 document perfectly usable when locally stored and then try to fiddle to get it to work in an e-reader?

    This is just the latest example of media companies making a fortune on a dead format only to make customers purchase the same thing again in a better state.

    I have put together a system that takes a media rich document built in wordpress and with a click of a button it downloads a single html document (or a zipped html) that contains media, CSS and Javascript, mathml, svg.

  4. Calling the Google Play version of EPUB a mutant subspecies is like calling Raphael a mutant subspecies of Teenage Mutant Ninja Turtles because his name ends in a consonant. EPUB is the worst joke of a spec I have ever seen. The simple fact is that the EPUB spec has zero relevance to how a book will render on any device or app.

  5. I realised, while I was sitting on the train this morning, that my second code example isn’t quite right. Rather than body>div.text>p:first-of-type::first-letter it should be body>div:first-of-type>p:first-of-type::first-letter.

    There’s no difference between the result of these two lines of code, which means my point stands, but I just thought I’d put in that little correction.

    I feel I should point out that I wasn’t seriously trying to use these monstrous pseudo-selectors as the basis for the styling of a book, nor was I desperate to get drop-caps to work. The book I was working on was a test, created for probing the behavior of various e-readers.

    re: William Ockham’s point. I agree that the epub spec is something of a joke, but this particular deviation is an order of magnitude more annoying than the usual crap. GPB is smashing your finely-built lego castle, whereas a program like ADE is merely smearing it with poop.

  6. I suspect they did it to make syncing between different devices easier. Apple for example does it for its Pages, Numbers files because it was too difficult to get the changes synced a crossed for cloud services. Hence they use a proprietary binary format instead of XML which the old version used, which allows smaller files to be sent and gives the impression of speed, particularly when using a web browser client. Amazon and Apple still use binary files for sending the page location info in their ebooks but send the entire book file before doing so (in ePub or mobi etc..). Hence the ebook is ePub but the bookmark information isn’t (if that makes sense).

  7. I recently purchased a bunch of ePub comics through a humble bundle offer. The humble bundle site recommends loading the books onto Google Books to read them. I went ahead and did as suggested and found that while the android version of Google Books can display the comics perfectly. The browser version does not support these particular epubs. Very annoying.

  8. As a new author, I’m new to e-publishing. Publishing to Kindle was a doddle. But I’ve been trying for five days to publish on GPB and have failed so far. I created an epub file using Calibre, but when uploaded to GPB it says there are errors, many of them. Not being a technical person, I have no idea what they mean or how to resolve them. So I’m looking for an alternative way of creating a file that GPB will accept. Any suggestions would be gratefully received. I have uploaded a pdf but when published, it looks dreadful trying to read on a mobile device.
    I have read other books on my mobile device from GPB and they are great – not so lucky with my own book.

  9. What I do is to download free books from Google Play (not through the Google Play Books app, then open the downloaded file to extract the epub before deleting the rest because it’s the only way I can open the books in my chosen ebook app.

  10. You mistakenly assume that the aim of GPB is to render EPUB, and then deem it to be “weird” that it does not live up to this false expectation. The aim of the GPB renderer is not to render EPUB – it is to deliver a decent reading experience. Waiting for an EPUB download to finish, having your mobile device’s tiny memory clogged with EPUB files, etc. are all detriment to having a decent reading experience. That’s why Google has chosen a streaming model for GPB rendering. Unfortunately, unlike PDF, EPUB does not natively support streaming, and so Google have had to come up with their own delivery scheme.

    1. No, I didn’t assume that was their aim. I assumed that because they maintained the external appearance of supporting Epub, they would display Epub. They don’t, and I thought that was pretty cool.

      Waiting for an EPUB download to finish, having your mobile device’s tiny memory clogged with EPUB files

      Given how fast download speeds are now and the cost of storage, that is just nonsense.

        1. I’m fine with being wrong; it happens to all of us.

          But your argument in support of Google’s solution smacks of working backwards from your conclusion. The average ebook is well under 1MB in size. With storage measuring in GB there are no real space issues, and with mobile data plans measuring in GB the cost to transmit 1MB is negligible.

          Also, don’t forget that Google requires that you upload an ebook before you can download it – and that includes when you already have the ebook on the device. That undercuts your argument; Google is effectively adding to the storage issue and wasting bandwidth uploading and downloading the file.

  11. I can confirm Ben Hollingum’s story. I’ve uploaded several ebooks with CSS drop-caps to Google Play and they all demonstrate the problem described here in both the web and Android readers. It appears that Google’s ebook renderer doesn’t paginate HTML documents like, say, your browser’s Print dialog does, but by actually breaking any block-level elements at page intervals. Unfortunately it’s not possible to inspect the DOM in the readers, so I don’t know exactly what kind of transformation it does…

    And you’re right in that neither the Android app nor the web reader actually serve you the EPUB as you uploaded it. If you’re curious about the “concealed intermediary file format of unknown design”, you can inspect it yourself (sort of) on your Android phone: just fire up your favorite file manager app and navigate to ~/Android/data/com.google.android.apps.books/files/accounts/your.account@name.here/volumes/. Every oddly-named folder there corresponds to a book, with a segments subfolder containing the actual chapter files. You’ll notice the names of the files in the segments subfolder match the ids that the corresponding elements were given in the original EPUB’s manifest file. The contents of the files themselves are unfortunately encrypted, though in an earlier version of the app, contents of user-uploaded books were served in plain text. You’ll just have to take my word that their contents were mostly the same as what the Google Books web reader serves to date, which you can easily inspect yourself by opening your browser’s network debugging console while using it (look for requests going to https://books.googleusercontent.com with a query string starting segment?start=chapter_id_here....)

  12. I don’t even bother reading ebooks through Google’s app, I just download whatever I want from Google Play, then find the file on my fake SD card and pull the epub from it before opening it in Cool Reader. I guess it’s the wrapper that Google puts on the epubs that’s at fault because I’ve never experienced drop caps being on every page.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>