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