Skip to content

ePub Content Document

kjaebker edited this page Sep 13, 2012 · 1 revision

An ePub publication must supply at least one Content Document. These documents are referred to by both the Package Document and the Navigation Document.

OSCI Toolkit will provide the Content Document for a section at http://[hostname]/[section id]/epub.xhtml. The following sections highlight how OSCI Toolkit features will be represented within the ePub specification:

Paragraphs:

Paragraphs should be identified with an id such as paragraph-N, allowing them to be referenced with a URL of the form http://url-to-the-section/#paragraph-N.

Figures:

A figure reference will be identified with an id of the form figref-book#-section#-N. The corresponding figure parameters will be defined in a document referred to by the manifest. The contents within the object tag will be rendered if the media type is not supported by the reader and the reader is unable to execute the script for the media type referenced in the bindings.

    <figure id='fig_3_13'>
      <object id='fig-3-13' type='application/osci-tk-conservation-figure' data='figure-2.xml'>
        <img src="url-to-fallback-image"/>
      </object>
      <figcaption>Fig. 13.4</figcaption>
    </figure>

The relevant parts of the package document would look like this:

    <manifest>
        ...
        <item id='figimg-2' href="url-to-fallback-image" 
            media-type="image/jpeg"
        <item id="figure-2" href="figure-2.xml" 
            media-type="osci-tk-conservation-figure"/>
        ...
    </manifest>

The corresponding XML may look like:

    <?xml version="1.0" encoding="utf-8"?>
    <!DOCTYPE html>
    <html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops">
	<head></head>
    <body>
      <figure id="fig_17_1" data-position="n" data-columns="50%" data-options="{}">
        <div class='figure_content'><video src='http://localhost:10088/oscitoolkit/sites/default/files/videos/8b7b6dc4a8ed0b53_ipod.mp4'><p>Fallback thumbnail</p></video></div>
        <figcaption>Fig. 1 Testing</figcaption>
     </figure>
    </body>
    </html>

In our case, our reader will support the osci-tk-conservation-figure type. It will see this type on the object element for the figure reference and load the data from the data attribute. If we decide to provide support for our custom media type in other ePub readers, we will need to add a script and a bindings section to the package document like so:

    <manifest>
        ...
        <item id='figimg-2' href="url-to-fallback-image" 
            media-type="image/jpeg"
        <item id="figure-2" href="figure-2.xml" 
            media-type="osci-tk-conservation-figure"/>
        <item id="osci-tk-conservation-figure-viewer" href="impl.xhtml" 
            media-type="application/xhtml+xml" 
            properties="scripted"/>
        ...
    </manifest>
    <bindings>
      <mediaType handler="osci-tk-conservation-figure-viewer" media-type="application/osci-tk-conservation-figure"/>
    </bindings>

The reader will check the bindings in the package document, see that the osci-tk-conservation-figure-viewer item in the manifest handles this media type, and use it to process the data (we'll need to look into this more if we want to provide this feature). If the script cannot be executed or a handler can't be found (as would be the case if we don't implement the binding), the fallback content in the object element will be displayed. The best practice would be to use a file referenced in the manifest for the figure data so that a binding could be implemented in the future.

Footnotes:

Footnotes can use the noteref type from the default epub:type vocabulary.

    <html  xmlns:epub="http://www.idpf.org/2007/ops"><p><a epub:type="noteref" href="#n1">1</a></p><aside epub:type="footnote" id="n1"></aside></html> 

User notes:

We should be able to use the same method as footnotes, but with a custom value of osci-tk-user-note for the epub:type attribute. These could then be handled in a different manner, and will be ignored by readers that don't recognize our custom type.