blog

Infogrid Pacific-The Science of Information

The AAP ePub3 Implementation Project

31 October 2013

Event, ePub3, AZARDI, IGP:Digital Publisher, Fonts, SVG, MathML, Audio, Video, SMIL Audio, Fixed Layout, Opinion

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.

Syncronicity - the Hot Feature List

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.

  1. Navigation, both via thorough TOCs and proper document structure
  2. Audio, needed for media overlays, aligning with audiobooks, and accessibility
  3. SVG, an XML-based for scalable images with searchable text
  4. Fonts, including embedded fonts for design and special characters
  5. Media Overlays, which enable synchronization of text with recorded audio
  6. Semantic Inflection, for providing important information about an element’s purpose and aids with contextual search and assistive technologies
  7. MathML, the XML format for math, providing resizable rendering and accessibility
  8. Video, including proper use and handling of fallbacks in systems without video
  9. Floats, the CSS function for handling elements outside the narrative text flow
  10. Fixed Layout, which enables control and display of fixed pagination in EPUB

AAP ePub3 Implementation Project White Paper

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.

Some Discussion on Ambiguities

Most of the items on the list are straight-forward and easy to understand but I have a few questions and comments.

Fonts

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.

Semantic Inflection

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. 

Floats

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!

Accessibility Issues

Another excellent and thorough list. Here it is straight from the AAP document:

  1. Separate content and presentation: Use more than just visual cues to convey information. The content’s meaning should be the same without styles or formatting.
  2. Provide complete navigation in the form of a complete table of contents.
  3. Create meaningful structure by always using the most specific tag possible.
  4. Define the content of each tag with the EPUB 3 Structural Semantics Vocabulary.
  5. Use images only for pictures, not for tables or text.
  6. Use image descriptions and alt text: Every image should have a description, caption or alt text unless it is solely decorative.
  7. Include page numbers for titles with print equivalents, and provide the ISBN of the printed edition.
  8. Define the language(s) in both the root element and for words or passages that are not in the default language.
  9. Use MathML for math content.
  10. Provide alternative access such as captions, transcripts, and sign language to media content: Enable native video and audio controls by default and offer fallback alternatives.
  11. Make interactive content accessible. If using custom controls, follow the W3C Accessible Rich Internet Application (ARIA) specification to make them accessible.
  12. Provide accessibility metadata in your files so end users know what features are there and search engines can discover your accessible materials.
  13. Make sure your processes support the above best practices.

AAP ePub3 Implementation Project White Paper

Some Discussion on Accessibility

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.

Metadata and Use Cases

The last two feature lists in the white paper are Metadata and Use Cases.

Metadata

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.

Use Cases

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.

Summary

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