epubjs

Version:

Render ePub documents in the browser, across many devices

54 lines (52 loc) • 4.33 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/section[1]" /><link rel="prev" href="./ch03s02_2.html" /><link rel="next" href="./ch03s02_4.html" /></head><body> In this case, the <code class="literal">epub:type</code> attribute conveys that this <code class="literal">seq</code> represents a chapter in the body matter. Although the attribute isn’t required, there’s little benefit in adding <code class="literal">seq</code> elements if you omit any semantics, as a reading system will not be able to provide skippability and escapability behaviors unless it can identify the purpose of the structure. It may seem redundant to have the same semantic information in both the markup and overlay, but remember that each is tailored to different rendering and playback methods. Without this information in the overlay, the reading system would have to inspect the markup file to determine what the synchronization elements represent, and then resynchronize the overlay using the markup as a guide. Not a simple process. A single channel of information is much more efficient, although it does translate into a bit of redundancy (you also typically wouldn’t be crafting these documents by hand, and a recording application could potentially pick up the semantics from the markup and apply them to the overlay for you). We can now start defining synchronization points by adding <code class="literal">par</code> elements to the <code class="literal">seq</code>, which is the only other step in the process. Each <code class="literal">par</code> contains a child <code class="literal">text</code> and a child <code class="literal">audio</code> element, which define the fragment of your content and the associated portion of an audio file to render in parallel, respectively. Here’s the entry for our primary chapter heading, for example: <pre class="screen" data-origPath="/html/body/section/section[1]/pre[4]"><par id="heading1"> <text src="chapter_001.xhtml#c01h01"/> <audio src="audio/mobydick_001_002_melville.mp4" clipBegin="0:00:24.500" clipEnd="0:00:29.268"/> </par></pre> The <code class="literal">text</code> element contains an <code class="literal">src</code> attribute that identifies the filename of the content document to synchronize with, and a fragment identifier (the value after the # character) that indicates the unique identifier of a particular element within that content document. In this case, we’re indicating that chapter_001.xhtml needs to be loaded and the element with the id <code class="literal">c01h01</code> displayed (the <code class="literal">h1</code> in our sample content, as expected). The audio element likewise identifies the source file containing the audio narration in its <code class="literal">src</code> attribute, and defines the starting and ending offsets within it using the <code class="literal">clipBegin</code> and <code class="literal">clipEnd</code> attributes. As indicated by these attributes, the narration of the heading text begins at the mid 24 second mark (to skip past the preliminary announcements) and ends just after the 29 second mark. The milliseconds on the end of the start and end values give an idea of the level of precision needed to create overlays, and why people typically don’t mark them up by hand. If you are only as precise as a second, the reading system can move readers to the new prose at the wrong time or start narration in the middle of a word or at the wrong word. </body> </html>