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. Only after it has gone through all that can it render the page.īased on this behavior Ben has awarded the title of "weirdest epub rendering engine" to Google Play Books.
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. 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. What it actually did was select the first letter of each page. 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.
Intrigued, I added another layer to my selector. 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.īen goes on to explain the steps to confirm this strange behavior, eventually ending with: 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). When I loaded this book into Google Play books I noticed something odd. 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). These were identified using an HTML class ( p.first) and a pseudo-element selector ( ::first-letter). This book had drop-caps on the opening body-text paragraphs of each chapter. This first became apparent to me when I loaded one of the books I was working on into Google Play Books. The problem comes from the way that it handles the HTML framework onto which that CSS is applied. 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.
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. He detailed the quirk on his blog a couple days ago: I learned of this oddity from Ben Hollingum, an ebook developer based in London. 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. A reader has tipped me to the news that Google Play Books doesn’t actually display Epub.
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.Īnd now it seems we can add Google to the mix. Google Play Books Doesn’t Support Epub, and Other Crazy PossibilitiesĮpub advocates like to pretend that it’s an industry standard format, but that’s not completely true.
0 kommentar(er)
