epubjs

Version:

Render ePub documents in the browser, across many devices

92 lines (85 loc) • 6.79 kB

HTML

<?xml version="1.0" encoding="UTF-8" ?><!DOCTYPE html><html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>Talk to Me: Media Overlays</title> <link rel="stylesheet" type="text/css" href="css/epub.css" /> <meta name="dat-origPath" value="/html/body/section" /><link rel="prev" href="./ch03s02_1.html" /><link rel="next" href="./ch03s02_3.html" /></head><body> As you might suspect at this point, the reading system can’t synchronize or play content back any way but what has been defined; as a reader you cannot, for example, dynamically change from word-to-word to paragraph-by-paragraph read-back as you desire. The magic is only as magical as you make it, at least at this time. With only a single level of playback granularity available, the decision on how fine a playback experience to provide has typically been influenced by the disability you’re targeting, going back to the origins of the functionality in talking books. Books for blind and low-vision readers are often only synchronized to the heading level, for example, and omit the text entirely. Readers with dyslexia or cognitive issues, however, may benefit more from word-level synchronization using full-text full-audio playback. Coarser synchronization—for example at the phrase or paragraph level—can be useful in cases where the defining characteristics of a particular human narration (flow, intonation, emphasis) add an extra dimension to the prose, such as with spoken poetry or religious verses. The production costs associated with synchronizing human-narrated ebooks to the word level, however, has typically meant that only short-prose works (such as children’s books) get this treatment. Let’s turn to the practical construction of an overlay to discover why the complexity increases by level, though. Understanding the issues will give better insight into which model you ultimately decide to use. <h3 class="title" id="_building_an_overlay" data-origPath="/html/body/section/section[1]/h3">Building an Overlay</h3> Every overlay document begins with root <code class="literal">smil</code> element and a <code class="literal">body</code>, as exemplified in the following markup: <pre class="screen" data-origPath="/html/body/section/section[1]/pre[1]"><smil xmlns="http://www.w3.org/ns/SMIL" xmlns:epub="http://www.idpf.org/2007/ops" version="3.0"> <body> </body> </smil></pre> There’s nothing exciting going on here but a couple of namespace declarations and a <code class="literal">version</code> attribute on the root. These are static in EPUB 3, so of little interest beyond their existence. There is no required metadata in the overlays themselves, which is why we don’t need to add a <code class="literal">head</code> element. Of course, in order to now illustrate how to build up this shell and include it in an EPUB, we’re going to need some content. I’m going to use the Moby Dick ebook that Dave Cramer, a member of the EPUB working group, built as a proof of concept of the specification for the rest of this section. This book is available from the <a class="ulink" href="http://code.google.com/p/epub-samples/downloads/list" target="_top">EPUB 3 Sample Content project page</a>. If we look at the content file for chapter one, we can see that the HTML markup has been structured to showcase different levels of text/audio synchronization. After the chapter heading, for example, the first paragraph has been broken down to achieve fine synchronization granularity (word and sentence level), whereas the following paragraph hasn’t been divided into smaller parts. Compressing the markup in the file to just what we’ll be looking at, we have: <pre class="screen" data-origPath="/html/body/section/section[1]/pre[2]"><section id="c01"> <h1 id="c01h01">Chapter 1. Loomings.</h1> Call me Ishmael. Some years ago… … There now is your insular city of the Manhattoes… … </section></pre> You’ll notice that each element containing text content has an <code class="literal">id</code> attribute, as that’s what we’ll be referencing when we get to synchronizing with the audio track. The markup additionally includes <code class="literal">span</code> tags to differentiate words and sentences in the first <code class="literal">p</code> tag. The second paragraph only has an <code class="literal">id</code> attribute on it, however, as we’re going to omit synchronization on the individual text components it contains to show paragraph-level synchronization. We can now take this information to start building the body of our overlay. Switching back to our empty overlay document, the first element we’re going to include in the body is a <code class="literal">seq</code>: <pre class="screen" data-origPath="/html/body/section/section[1]/pre[3]"><body> <seq id="id1" epub:textref="chapter_001.xhtml#c01" epub:type="bodymatter chapter"> </seq> </body></pre> This element serves the same grouping function the corresponding <code class="literal">section</code> element does in the markup, and you’ll notice the <code class="literal">textref</code> attribute references the <code class="literal">section</code>’s id. The logical grouping of content inside the <code class="literal">seq</code> element likewise enables escaping and skipping of structures during playback, as we’ll return to when we look at some structural considerations later. </body> </html>