23 March 2014
epubtest.org is up and working. The ePubTest site looks quite nice and I do like the way it has addressed the complexity of giving an analysis for a lot of reading systems and properties. Regretfully there is no business or market prioritization or weightage of the various features...
epubtest.org is up and working. We covered this in September last year here. and checked out AZARDI here. The ePubTest site looks quite nice and I do like the way it has addressed the complexity of giving an analysis for a lot of reading systems and properties. Regretfully there is no business or market prioritization or weightage of the various features.
Mandatory and optional features are listed separately, but in the final scoring everything is bundled together. That means dinky optional features get the same weightage as essential (for example) navigation features. However it also means meaningless mandatory features such as CFI get the same weightage as essential content features.
The outcome is that the "scoring system" does not represent anything even slightly useful for users, publishers... or anyone... in terms of understanding the value and usability of any particular reading system.
...the "scoring system" does not represent anything even slightly useful for users, publishers or anyone...
Not all IDPF specification features are equal in importance or value. That is an industry stated fact. This was made very clear with the AAP ePub3 Implementation Project which saw publishing industry inputs on prioritized feature importance. The AAP go it right, but regretfully none of this industry feedback or experience has any effect on the IDPF.
This was an opportunity for the IDPF to syncronize with the publishing industry stated priorities and requirements rather than giving everything the same mark weightage in nine relatively arbitrary feature sections. The evaluation sections were based on the extremely dated 2011 specification written structure rather than 2013 stated publisher needs.
Here is an illustrative graph of various e-reader technologies and how they compare with (X)HTML(5).
Statements have been made that ePub3 is HTML5. That is a deliberate obfuscation of the facts. The core packaging and add-on technologies have nothing to do with HTML5.
Of course ePub3 makes a passing nod to XHTML5 (the content pages are a custom set of XHTML); but ePub3 has so many irrelevant XML, XLINK and arbitrary property add-ons any direct comparison between HTML5 and ePub3 is specious.
Meanwhile E-Book Zero builds exactly on HTML5 with controlled structures and vocabulary and achieves so much more.
For example giving the same mark weightage to vertical Japanese and other yesterday's reading system backward support features gives ranking up even if a reading system doesn't have any significant ePub3 navigation support (the most important AAP feature requirement).
The "score" is an incomprehensible IDPF tab against the pointless features of ePub3 that has no particular meaning for publishers trying to implement real digital content strategies.
The IDPF assessment has nine feature "categories" and all categories are all given an equal weighing. That simply doesn't make sense. But even worse, within the categories the choice of important items is technical rather than publishing need driven.
The most amusing of these is "international language support". There are in fact just two issues and three languages; vertical Japanese writing, and right to left presentation for Arabic and Hebrew. The IDPF redefines International!
In the scoring system vertical Japanese is given 80% of Global Language Support marks. We understand this is pushed by the "Manga" brigade and is important in Japan and at the time of authoring Sony was strongly supporting ePub3. However this should NOT have the same marks weightage as Navigation. Looking at languages that are actually spoken by reasonable numbers of people this should be something like 1%. This type of feature mis-weighting just lowers the value of everything. There is absolutely no reason vertical Japanese should be a required feature if a reading system is not being promoted for use in Japan.
There is a pointlessness commenting on the IDPF aePub3 specification and "initiatives". But if you care about delivering content, especially education content it is important to stay engaged.
With ePub3 the IDPF pushed more wrong buttons than right buttons. They were of course victims of radical market changes... the death of the autonomous reading device and emergence of tablets and large smart phones. With AZARDI we have been highly selective and rationalized the features supported. The focus, like the AAP, is on the sensible parts of the specification that are HTML5 and forward looking. Anyone who says they are supporting the full ePub3 specification is not serious about digital publishing content. They are distraught technophobes
The ePub3 spec pretty much encapsulates the state of e-reading systems before the advent of tablets and smartphones. The timing for irrelevance was perfect.
The value of ePub3 for publishers is a reasonably competent and consistently defined packaging and navigation structure. The rest of the specification is lost in a pointless 2007 reading device hole.
I see articles about Apps vs. e-books from time to time such as this article "Five Myths About Book Apps" by Karen Robertson. Meanwhile AZARDI in ePub3 and E0 modes can show any content in an App-like manner as it has scripting, SVG, MathML, fixed, scrolling and reflowing layout. That is because we decided to select "the" useful and sensible features from the arcane ePub3 specification, ignore the un-needed features, step around the un-wanted features and get down to business way back in 2011.
AZARDI ticks off the AAP priority list and of course adds real Internationalization support. We are now working on 206 languages as mentioned in the previous post. This is an exciting new dimension to accessibility that digital content delivers. Of course that means fonts are very important.
So I guess now we just have to wait for Reading systems based on the IDPF Readium API project underway and see if that makes any difference for anyone.
Posted by Richard Pipe