31 October 2013
The AAP ePub3 Implementation white paper is out. Get it here. It is pretty much what it needs to be. A succinct list of the features desperately needed in an ePub3 reading system. It has eschewed all the arcane edge features we have critically blogged about and focuses on the important content issues and accessibility.
The AAP ePub3 Implementation white paper is out. Get it here. It is pretty much what it needs to be. A succinct list of the features desperately needed in an ePub3 reading system.
It has eschewed all the arcane edge features we have critically blogged about and focuses on the important content issues and accessibility.
The priority list is exactly the same as the ePub3 Reading System feature priority list we authored when we developed AZARDI in 2011 (the world's first ePub3 reading system). The difference between the lists is we stated why we are not supporting certain ePub3 specification features. The chaff has to be sorted from the wheat.
Here is the AAP prioritized feature list. Not much to argue with here but there are some pleasing and exciting priorities.
The AAP Paper goes on to explain each of these in more depth. I am pleased to say both IGP:Digital Publisher (our digital content production system) and AZARDI meet all 10 criteria in spades.
The only thing that I am a little surprised is missing is scripting.
The impression is that there were a lot of education focused attendees at the conference. EPub3 may be largely irrelevant for trade fiction and even non-fiction, but it has massive potential to change education content delivery. That is certainly our focus.
Most of the items on the list are straight-forward and easy to understand but I have a few questions and comments.
We put a lot of effort into both IGP:Digital Publisher and AZARDI to ensure the full CSS-Font module was implemented. In fact we have a dedicated APEX@IGP Fonts Unit dealing with various CSS3 font issues such as: Open Source Fonts List (embed without guilt); Font Properties; Font Subsetting; OTF Font Features and Glyphs, with two pages exposing the internals of the Megalopolis font and the Linux Libertine font.
The report is font feature annnoted comprehensively except for no mention of the font-stretch property. If you are embedding and obfuscating fonts it is good to take notice of, and be able to use, all font-face properties.
There is no mention of font-features, the mapping of alternative glyphs to characters. This is relatively easy to do today and is fully implemented in IGP:Font Manager 2, IGP:Digital Publisher and AZARDI.
EPub3 files produced with IGP:Digital Publisher have the richest semantic epub:type mapping of any production system. It just comes automatically with every ePub3 generated.
You can see our semantic tagging to ePub3 type map here. This can only happen if you make things the right way in the first instance. What matters is how digital content books are produced for this to work.
The problem with the IDPF semantic structure list is it is highly incomplete, based largely on a DocBook type structure, is gramatically weird in places, and has absolutely no properties for education or important other genre content at all. If this is as important as stated significant work needs to be done on the semantic list. They should take a look at IGP:FoundationXHTML to understand how to approach this in a more professional and complete way.
This requirement is a little ambiguous and not stated clearly. In our experience most ePub2 reading systems support CSS float which is limited to left and right. Support of the overflow:auto; CSS property is of course required with this to make sure floated content blocks position correctly.
I would like to read a little more on the problems that have raised this as a feature issue, especially since it is rated amazingly above fixed-layout!
Another excellent and thorough list. Here it is straight from the AAP document:
These issues are of course more about production methods than reading systems.
Some of these are Catch-22 production issues. EPub2 reading system limitations and poor production methodologies reach into ePub3. They shouldn't. But they do.
We have ensured that content produced with IGP:Digital Publisher meets most of the above requirements. However with even simple value additions such a really good alt-text publishers have to be convinced to make it important.
Where we can automate features we do. That is why from a print PDF produced in IGP:Digital Publisher, pagebreak elements can be automatically inserted into the ePub3 text for a particular edition, semantic vocabulary is processed in detail into the ePub3, the structure is semantically detailed and accurate without styling.
More challenging accessibility features include ARIA in interactive content. We are working on that at present and because IGP:FoundationXHTML uses pre-defined tagging patterns this is more straight-forward than using ad-hoc elements. This will be substantially automated in an IPG:Digital Publisher produced ePub3 by the New Year.
There is nothing overly demanding in the accessibility requirement list and it is good to see it presented succinctly and in a workflow ready list format. The IGP:Digital Publisher production tools and methods deliver a substantial part of this always and transparently We will certainly be using this document and list to educate our publisher partners on the value and importance of the items that need editorial input.
The last two feature lists in the white paper are Metadata and Use Cases.
Metadata is a little hard to follow? Too many questions marks? In the bullet lists? I understand their problem. We have been wrestling with the correct creation and use of metadata for a couple of decades.
However our position is that we don't think metadata beyond that required for reading system usage belongs in the ePub package. Certainly not ONIX which is an inter-business exchange format. Good straight-forward DC:Metadata is the requirement. If more extensive metadata is required for a particular client or site requirement it should be packaged in a metadata tagging pattern of some sort. Not in the OPF file.
This reads like an ePub2 feature list critique. Most particularly an Adobe Digital Editions lack of features list. It is a good and valid list but may not apply to the ePub3 readers that exist now, and that may appear.
Reading systems are now being built on highly standards compliant engines such as Mozilla and Webkit that are years in advance of the ePub3 specification. This is certainly a list of features that if they are not supported in a reading system should be subject to positive public comment and criticism.
All in all a great list. Well done AAP for getting an industry spot-light focused on priorities for ePub3 reading systems that match real world content presentation demands right now.
I am encourages by the statement:
... it was clear to all participants in this initiative that improvements in both reading system feature implementation and practices for creating EPUBs on the part of publishers are not just important, they are urgent.
It is of course smugly satisfying that this feature priority list pretty much matches our original AZARDI feature development priority list written two years ago. The inordinate amount of flak we have had from the IDPF on our stand, posts and comments has been vindicated.
But we are not gloaters (he said gloating!). It's on with the job of making some of the perceptibly difficult technologies like MathML and SVG easier for K-12 education publishers to work with. Having got the ePub3 Reading System map right, it's now time to make sure production solutions can exploit them to the full.
It is nice to end October 2013 on a positive, moving forward note. It's Halloween in the U.S.. Let's hope the hob-goblins don't bite too much.
Now let's hope that some reading device and software creators other than Infogrid Pacific take notice of this report. Regretfully we have to say we are not optimistic.
Posted by Richard Pipe
Start a real digital content strategy with
The complete digital publishing content management and production solution.
Available as for Small and Medium publisher:
IGP:Digital Publisher is also available as a full site license purchase.
Use one master XHTML file to instantly create multiple print, e-book and Internet formats.