ENTRIES TAGGED "css"
Upgrading to EPUB 3 is not a trivial undertaking
We at O’Reilly are very pleased to announce that we have officially upgraded to EPUB 3, and ebook bundles purchased from oreilly.com will now include EPUB 3 files, in addition to Mobi and PDF files. All O’Reilly ebooks released in 2013 are now available in EPUB 3 format, and in the coming weeks, we will be updating and rereleasing our backlist ebooks in EPUB 3 as well.
But while we’re excited to share this news, this article is not merely a press release. The decision of when and how to upgrade to EPUB 3 has been challenging for many in the publishing community, and it has been a long journey for O’Reilly as well. I’d like to talk more about why we chose to take this step now, what additional value we believe EPUB 3 provides to our customers, and the challenges and tradeoffs we’ve tackled in making our EPUBs backward compatible with EPUB 2 platforms.
The future of the book is inherently linked to the browser
One common misnomer I have come across is that EPUB3 is ‘a technology’ – something in and of itself. I believe this category mistake is largely a result of the the IDPF’s (the organisation that maintains EPUB3) success in promoting EPUB as a ‘standalone’ technology to the publishing world.
Newgen's Silk Evolve is a powerful automation platform
How many times have you opened an ebook and noticed awkward hyphenations or other conversion errors? I still see this in the majority of the ebooks I buy and it’s clear these are the result of someone not paying attention during the conversion process. They may be minor annoyances but they reflect poorly on the publishers who produce them.
I recently had a chance to talk about this problem with Patrick Martinent, the CTO at Newgen KnowledgeWorks. They have a terrific platform called Silk Evolve that helps automate and reduce the errors when going from PDF to EPUB. The following Q&A is a preview to what you can expect to hear in Patrick’s session at next month’s TOC NY conference.
SPi Global's latest whitepaper is a must-read for everyone in publishing
Have you heard all the hype about HTML5 but you’re still not sold on it? You need to read the latest whitepaper from SPi Global. It’s called HTML5: The Code to Maximizing Revenue and it does a terrific job explaining why this technology is so important. The document is only 7 pages long but it will give you a solid foundation. Here are a few of my favorite excerpts from the whitepaper:
Abandoning the “walled garden” environment of downloaded applications also has distinct SEO advantages, because only one set of search criteria is needed to make content discoverable across platforms.
Despite a huge leap forward there's still plenty of room for improvement
2012 was a good year for Kindle developers. With the unveiling of the first-generation Fire tablet in late 2011 and the release of the KF8 Mobi format in early 2012, designing beautiful ebooks for the Kindle platform became a reality. KF8 introduced a fixed-layout specification for Kindle Fire, which opened the door to graphically rich titles—children’s books, graphic novels—in Mobi format. KF8 also greatly increased CSS2 compliance for standard reflowable ebooks, implemented a handful of CSS3 features (text shadow, rounded borders), and added support for embedded fonts. The subsequent rollout of KF8 to Kindle eInk readers running firmware 3.4 (including the new Kindle Paperwhite) and KF8’s support for @media queries to enable fallback styling for non-KF8 devices helped to increase rendering parity within the diverse Kindle ecosystem.
WYSI editors enable a whole new level of interaction
Since HTML is the new paper and the new path to paper online editing environments are becoming much more important for publishing. Dominant until now has been the WYSIWYG editor we all know and…err…love? However the current WYSIWYG paradigm has been inadequate for a long time and we need to update and replace it. Producing text with a WYSIWYG editor feels like trying to write a letter while it’s still in the envelope. Let’s face it…these kinds of online text editors are not an extension of yourself, they are a cumbersome hindrance to getting a job done.
Why are we leaving such an important issue to under-resourced volunteers and small organisations?
Typesetting math in HTML was for a long time one of those ‘I can’t believe that hasn’t been solved by now!’ issues. It seemed a bit wrong – wasn’t the Internet more or less invented by math geeks? Did they give up using the web back in 1996 because it didn’t support math? (That would explain the aesthetic of many ‘home pages’ for math professors.)
The explosion in web typesetting has been largely unnoticed by everyone except the typography geeks. One of the first posts that raised my awareness of this phenomenon was From Print to Web: Creating Print-Quality Typography in the Browser by Joshua Gross.
The new typesetting engine blueprint is right here in front of us
With the onward march towards the Browser Typesetting Engine, not an invention but a combination of technologies with some improvements (much like Gutenberg’s press) it’s interesting to think what that would mean for print production. Although there are various perspectives on how the printing press changed society and they mostly reflect on the mass production of books, and while the first great demonstration involved a book (The Gutenberg Bible), the invention itself was really about automating the printing process. It effected all paper products that were formerly inscribed by hand and it brought in new print product innovations (no not just Hallmark birthday cards but also new ways of assembling and organising information).
The press affected not just the book but print. With browsers able to produce print ready PDF and the technology arriving to output PDF from the browser that directly corresponds with what you see in the browser window we are entering the new phase of print (and book) production. Networked in-browser design. We are not talking here of emulated template-like design but the 1:1 design process you experience with software like Scribus and InDesign.
The evolution of CSS
CSS Regions allow text to flow from one page element to another. That means you can flow text from one box to another box, which is what is leveraged in the BookJS technology I wrote about here. This feature was included in Webkit by the Romanian development team working for Adobe. It appears that Adobe has seen the writing on the wall for Desktop Publishing although they might not be singing that song too loudly considering most of their business comes out of that market. Their primary (public facing) reason for including CSS Regions and other features in Webkit is to support their new product Adobe Edge. Adobe Edge uses, according to the website, Webkit as a ‘design surface’.
A moment of respect please for the Adobe team for contributing these features to Webkit. Also don’t forget in that moment to also reflect quietly on Konquerer (specifically KHTML), the ‘little open source project’ borne out of the Linux Desktop KDE which grew into Webkit. It’s an astonishing success story for Open Source and possibly in the medium term a more significant contribution to our world than Open Source kernels (I’m sure that statement will get a few bites).
”HTML-based design surface’ is about as close to a carefully constructed non-market-cannibalising euphemism as I would care to imagine. Adobe Edge is in-browser design in action produced by one of the world’s leading print technology providers but the role of the browser in this technology is not the biggest noise being made at its release. Edge is ‘all about’ *adaptive design* but in reality it’s about the new role of the browser as a ‘target agnostic’ (paper, device, webpage, whatever – it’s all the same) typesetting engine.
A consortium, not an individual company
However we should not rely on Adobe for these advances. It is about time a real consortium focused on Open Source and Standards started paying for these developments as they are critical to the print and publishing industries and for anyone else wanting to design for devices and/or paper. That’s pretty much everyone.
Gutenberg died relatively poor because someone else took his idea and cornered the market. Imagine if he put all the design documents out there for the printing press and said ‘go to it.’ Knowing what you know now would you get involved and help build the printing press? If the answer is no I deeply respect your honesty. But that’s where we are now with CSS standards like regions, exclusions, and the page-generated content module. The blueprints are there for the new typesetting engine, right there out in the open. The print and publishing industries should take that opportunity and make their next future.
A user experience plea for more consistency across platforms
Ebook publishing is full of problem areas, most of which cannot be addressed through standardisation but can only come about via a sea-change in the behaviour and nature of the various participants in the ebook industry.
There are, however, several issues that could be addressed, at least partially, via standardisation, that would make everybody’s life easier if implemented.
One of the major issues facing publishers today is the spiralling complexity of dealing with vendor rendering overrides.
Each vendor applies different CSS overrides with differing behaviours, sometimes even only enabling features through server-side manipulation, which means that proper testing of an ebook is not only difficult, but impossible.
If vendors cannot be talked out of requiring these overrides then they need to be standardised and normalised. Any reading system that implements a CSS override is in violation of how the CSS standard defines the cascade and so is in violation of the EPUB 3 standard.
CSS overrides come in four broad types:
- Vendor styles only — The publisher’s styles are completely ignored in favour of the vendor’s.
- Aggressive vendor styles, but publisher styles enabled — Very little is seen of the publisher styles in this scenario. They mainly surface in edge cases that weren’t accounted for in the vendor’s stylesheet.
- Minimal overrides — The vendor only really enforces control over margins, backgrounds, and possibly font styles.
- Publisher styles — The mode that the reading app goes into when the reader deliberately selects ‘publisher styles’. Under ordinary circumstances this would simply disable the overrides but in most reading apps this mode has a unique behaviour.