What ePub3 specification features should be included in AZARDI and why Updated: 2012-11-16
Deciding which ePub3 specification features should be included in AZARDI and in what development priority is probably the hardest part of creating a practical ePub3 reader application. While AZARDI was the first ePub3 reader ever, and the first to support SMIL audio and even has a custom fixed-layout ability six months before the IDPF Specification was released.
There are a number of people on various lists and blogs who rant there is no reader that fully supports ePub3. There probably never will be and more importantly, probably never should be such an ePub3 reader for a number of reasons.
Application development has to be carried out in a pragmatic manner against real-world requirements. For example saying we are not supporting CFI as it is unlikely to be an issue for two years, if ever, is not hot-air, it is action. You have to drop the nutter stuff and cut to the digital content essentials.
There are spec. features that rely on the content being tagged in a specific and complex way to exploit that feature. Most of these significantly raises production costs unless the features can be included at production time with substantial automation. IGP:Digital Publisher is currently the only tool that has that automation or capability (Eg: comprehensive epub:type mapping).
The various IDPF Proprietary Glee clubs have not seriously address the production costs and patterns needed to make some of the ePub3 specification features workable and usable. It is only after wandering around the various ePub3 specification sideshows for a year that you realise the murkiness, importance, functionality, priority and reason for the features is never discussed; just that they are there. Many are irrelevant to the world in which we do digital content business.
So cutting through the noise and/or confusion, here is the our ePub 3 Specification priority list. It is ordered from high to low pretty much in feature importance sequence.
Rather obviously, handling the major components in the core package in the way they are meant to be handled is important. The specification is clear and excellent with manifest and spine and is a major leap forward with navigation structures.
Supporting multiple vocabularies (and testing them) is regarded by us as un-necessary at present. For example we work with the complexities and confusion of ONIX every day with IGP:Distribution Manager. It's suitability for an ePub is zero. But it is great being sent with the ePub to a distribution channel. Of course Apple, Barnes and Noble and a number of other channels have their custom XML or spreadsheet systems to make digital content distribution as difficult as it could be. There should be no invitation for this to enter the ePub structural components.
So DC is cool, ONIX, METS, LOC and others have little place in the real ePub internal world and shouldn't be there. Soon some dick-head channel is going to say your epub must have my ridiculously complicated metadata using my mysterious XML namespace if you want to submit your ePub to my amazing store.
Publishers will groan and service producers will rub their hands together with glee as their prices go up. The correct place for that ridiculously complicated metadata is in external transfer metadata, not as a rigor test in the ePub. It was never a requirement for a print book, why is the IDPF (who theoretically represents publishers) putting in production cost traps?
AZARDI has become more relaxed handling core packaging. The first version of AZARDI released in 2008 was ultra-strict. The 2011-2012 versions are relaxed and will pardon a lot of errors and try and display the ePubs. It's not that we are encouraging sloppiness, but sloppiness exists, and we want to let readers engage with the content without being punished. Right?
Navigation is now more than a TOC and a ratty optional Guide (made mandatory by Amazon and Apple).
Hopefully landmarks is used for more than Start Reading and copyright (except Apple doesn't care if you use it at all).
AZARDI doesn't insist on Landmarks, but if you put the effort in to include Landmarks it will make it available to the end user as a navigation option.
The focus on trade eBooks has meant the importance of other "list-of" structures widely used in academic and education content has not been implemented by any other reader. AZARDI makes included List-of navigation items available at the same level as the core TOC.
A hot new Nav. item is page navigation. We use this in text-book production always. Margin page numbers are inserted into the file so print edition and digital edition users can all get to the same page instantly. Page navigation also brings context to using prior Index numbers where e-books started their life as a print book. It has the potential to allow a "don't worry" approach to print page numbers in indexes if publishers grow up out of OEBS, Mobi and ePUb2.
Required for accessibility, education and entertainment. AZARDI has to be good at long passage reading; not just kiddie book pages in fixed layout. This is an important development area where constant feedback from accessibility users ensures interaction improvements.
It is especially useful in language teaching books. If someone is absorbing the costs of SMIL production processing at any level, readers should match that attention to detail.
FLO is required to create learning books of value right across the spectrum. It can also make rather nice entertainment and edutainment products, as well as comics.
The IDPF Fixed Layout specification has been very well written, but there is an implied elasticity and flexiblity that is not obvious if your brain is conditioned by print, iBooks and Kindle behaviour. Fixed layout behaviour on different screen sizes and resizable viewports/windows needs a lot of thinking. That is why our growing FLO Testbook pages exists here.
When AZARDI was first released in November 2011 we were nervous about scripting due to security concerns. We only allowed our own AZARDI Interactive Engine script to run.
It is our call that great fonts in e-readers is going to become very important. Therefore our production system can both sub-set and obfuscate fonts on packaging to acknowledge and support the design brilliance of so many font designers while making their work universally available. Font foundries are at last starting to write license deals for ePub font embedding. Yay!
We selected Mozilla XUL Runner as the core engine for AZARDI just for this reason. Our focus is education. Education has maths. Maths needs MathML for ease of production, reusability and accessibility.
From our perspective the importance of MathML is for line-art and illustrations in education. But there are a lot more uses as well. The native support of SVG in HTML5 makes this a no-brainer. SVG also supports accessibility very well so illustrations done in SVG with appropriate titles and descriptions on the elements are always going to be considerably more accessible than graphic images.
Our selected desktop core framework (Mozilla XUL Runner) does not support the video formats specified at the time of writing although this may change. Video is not seen as particularly important but can be nice.
However audio is core to educational products and is incredibly important for many subjects, especially language learning/teaching content. It is almost impossible to think of an ePub3 reading system that does not have extensive and powerful audio support.
The reason this is medium priority is we don't have access to reading software of sufficient quality to introduce into AZARDI. So because we cannot do much about it we can't make it high priority. But we do still think it is very, very important.
This feature was designed for the comic publishers (mainly). Personally I think it is just as easy to put these into an XHTML page so the added reading system and ePub loading complexity is not required. However we want to do a good job with Fixed Layout so will address this on the next iteration; if and when sufficient image/SVG based books are in the market, in languages other than Manga. (Hint - comic book makers, put your images in an HTML section. It isn't hard kids).
Basically Readers can do what they like with epub:type properties. The example in the specification using reference roll-overs working with the aside element is a relatively good one and has been functionally implemented in iBooks with Apple terms and conditions. We will be implemented this in AZARDI and are pushing it a bit further for academic and education content so notes, footnotes, glossary terms and even index references can be shown as interactive pop-ups.
Is anyone going to produce their ePubs with triggers? Is anyone going to produce a ePub reader with trigger support? It seems somewhat not required with HTML5. This is a wait and see job. Scripting is probably an easier, faster and better alternative.
We will wait and see how many ePubs are created using epub:switch before diving into the "make all readers do something with my complicated content" puddle.
We will wait and see if a significant number of books are produced that actually use these tags. It is probably un-necessary. It didn't happen with ePub2, it seems as pointless with ePub3.
It is difficult to understand that this will be significant. Until there is a customer with 100,000 books who just "has to have it" this one stays on the bad idea, badly conceived, badly written shelf. The Apple/Google membership on the authoring comittee is a little nerve wracking.