Fixed Layout in ePUB 3.0 Draft: Metadata Property Definitions

• Tweet
• Email
• Sumo

• Tweet
• Email

When the ePUB 3.0 specificationwas approved in October 2011, it was somewhat surprising and certainly disappointing to many ePUB creators that there was nothing in the spec for the creation of fixed-layout ePUBs. Apple’s fixed-layout ePUB has been very popular and has allowed publishers to bring content to market as ePUBs that they could not effectively represent as reflowable ePUBs (children’s picture books, graphic novels, cookbooks, etc.). Kobo followed with a fixed-layout ePUB similar to Apple, while Barnes & Noble created their own Digital Replica Plus (DRP) format, which relies on two deviations from the ePUB specification:

1. the format and reading system allow images to be top-level items in the spine, and
2. the addition of a replica map, mapping page images to XHTML content (and vice versa).

You can see a comparison of current fixed-layout formats here.

One of the reported difficulties that the IDPF had when considering specifications for fixed-layout ePUBs was how to handle the metadata, that is how to tell reading systems that the content was fixed-layout and not reflowable. The IDPF has a working group that has continued to work on the fixed-layout issue after the approval of the ePUB specification, one of several (including CSS Page Templates, Dictionaries and Glossaries, and Indexes) that are working on modules that may be added to the ePUB specification in the near future.

ePUB Fixed-Layout Documents

The current Working Group Draft of the ePUB Fixed-Layout Documents is not official, but it does give some insight into the direction the IDPF is going with the fixed-layout module. The working group defines how they see the fixed-layout ePUB issue in the Purpose and Scope section of the draft:

EPUB documents, unlike print books or PDF files, are designed to change. The content flows, or reflows, to fit the screen and to fit the needs of the reader. The EPUB 3.0 Specification says that “content presentation should adapt to the user rather than the user having to adapt to a particular representation of content.”

But this principle doesn’t work for all types of documents. Sometimes content and design are so intertwined they cannot be separated. Any change in appearance risks changing the meaning, or losing all meaning. Fixed-layout documents give content creators greater control over presentation, when a reflowable EPUB is not suitable for the content.

This document, EPUB 3 Fixed-Layout Documents, defines a set of metadata properties to allow declarative expression of intended rendering behaviors of fixed-layout documents in the context of EPUB 3. It also defines mechanisms to express the intended rendering dimensions of fixed-layout XHTML and SVG [ContentDocs30] content, as well as bitmap images.

It has been noted that the ePUB 3.0 specification is a balance between strict and flexible specifications. This is again evident in the note that follows the text above, which states

EPUB 3 affords multiple mechanisms for representing fixed-layout content in EPUB 3 documents. When fixed-layout content is necessary, the author’s choice of mechanism will depend on many factors including desired degree of precision, file size, accessibility, etc. This document does not attempt to dictate the author’s choice of mechanism.

Property Definitions

The first area covered in the ePUB Fixed Layout Documents draft is the definition of properties that can be used in the metadata section of the package or .opf document as a meta element or in the spine section of the .opf as an itemref element. By defining these properties in the metadata as a meta element, an ePUB creator is essentially setting a global definition that will be applied to the whole document. When the properties are applied in the spine section, essentially following <itemref id="itemname", it will only be applied to that particular item in the ePUB. Any property included in an itemref will override the global property defined in the metadata section for that particular itemref. In this way you can potentially make some content in an ePUB fixed-layout and some reflowable.

There are four properties in the draft that allow reading systems to understand that they are to render the ePUB with fixed layout. They are: rendition:layout, rendition:orientation, rendition:spread, and page-spread-*. We will take a look at each of these properties and what they convey to an ePUB reading system.

The rendition:layout property

The rendition:layout property essentially tells a reading system whether the ePUB or spine element is reflowable or pre-paginated (fixed-layout). When using this property, there are literally these two choices: reflowable or pre-paginated. The default value is reflowable, so if the property is not defined in the metadata section or the spine, the ePUB content will render as reflowable text.

Using this property in the metadata would look like this:

<meta property="rendition:layout">reflowable</meta>

<meta property="rendition:layout">pre-paginated</meta>

If this property is used in the spine within an itemref, the property is defined immediately following the item id. In the spine, using this property would look like this:

<itemref id="page01" properties="rendition:layout-reflowable"/>

<itemref id="page02" properties="rendition:layout-pre-paginated"/>

The rendition:orientation property

The rendition:orientation property specifies in which orientation the ePUB creator wants the publication or spine element to be rendered. There are three possible values for rendition:orientation: landscape, portrait, or auto. The default value for this property is auto or “the given spine item is not orientation constrained,” meaning the element should render according to device orientation or default.

In the metadata section, rendition:orientation would look like this:

<meta property="rendition:orientation">auto</meta>

<meta property="rendition:orientation">portrait</meta>

<meta property="rendition:orientation">landscape</meta>

If this property is used in the spine within an itemref, the property is defined immediately following the item id. In the spine, using this property would look like this:

<itemref id="page01" properties="rendition:orientation-auto"/>

<itemref id="page02" properties="rendition:orientation-portrait"/>

<itemref id="page03" properties="rendition:orientation-landscape"/>

The rendition:spread property

The rendition:spread property “specifies the intended Reading System synthetic spread behavior for this Publication or spine item” where synthetic spread is defined as the rendering of two adjacent pages simultaneously on the device screen. If you are working in the print environment, this would be the equivalent of having an image cut into two images that connects in the gutter across a two-page spread.

There are five possible values for rendition:spread: none, landscape, portrait, both, or auto. The value none means spreads should never be rendered; landscape means spreads should only be rendered when the device is in landscape orientation; portrait means spreads should only be rendered when the device is in portrait orientation; both means spreads should be rendered both when the device is in landscape orientation and when the device is in portrait orientation. The default value for this property is auto or “No explicit synthetic spread behavior is defined. Reading Systems may use synthetic spreads in specific or all device orientations as part of a display area utilization optimization process.” In other words, the Reading Systems will decide how to render the page.

In the metadata section, rendition:spread would look like this:

<meta property="rendition:spread">auto</meta>

<meta property="rendition:spread">none</meta>

<meta property="rendition:spread">landscape</meta>

<meta property="rendition:spread">portrait</meta>

<meta property="rendition:spread">both</meta>

If this property is used in the spine within an itemref, the property is defined immediately following the item id. In the spine, using this property would look like this:

<itemref id="page01" properties="rendition:spread-auto"/>

<itemref id="page02" properties="rendition:spread-none"/>

<itemref id="page03" properties="rendition:spread-landscape"/>

<itemref id="page04" properties="rendition:spread-portrait"/>

<itemref id="page05" properties="rendition:spread-both"/>

The page-spread-* properties

When dealing with spreads in this draft, there is a left-side viewport and a right-side viewport. The page-spread-* property allows you to specify which viewport a spine itemref element will appear on. As the draft states:

When a Reading System is rendering synthetic spreads, the default behavior is to populate the spread, which conceptually consists of two adjacent viewports, by rendering the next Content Document in the next available unpopulated viewport, where the location of “next” is determined by the given page progression direction, or by local declarations within content documents. By providing one of the page-spread-* properties on the spine itemref element, the author can override this automatic population behavior by forcing the given Content Document to be placed in a particular viewport.

So if you have two spine itemref elements that make up a single image that should be appear across a spread, you can define the one that should be on the left as page-spread-left and the one that should appear on the right as page-spread-right.

In addition to page-spread-left and page-spread-right, the draft also defines an additional property, page-spread-center, as:

which indicates that the synthetic spread mode should be overridden such that instead of two adjacent viewports, a single viewport must be used, and positioned at the center of the screen. Note that the presence of rendition:page-spread-center does not in itself affect the content dimensions.

If you are dealing with a children’s book, for instance, this would allow you to make single pages appear on a device screen alone while the two itemrefs that make a spread would appear together. These three page-spread-* properties apply to both reflowable and pre-paginated content.

When this property is used in the spine within an itemref, the property is defined immediately following the item id. In the spine, using this property would look like this:

<itemref id="page01" properties="page-spread-left"/>

<itemref id="page02" properties="page-spread-right"/>

<itemref id="page03" properties="page-spread-center"/>

Multiple properties can be combined in both the metadata and in a spine itemref element. So a children’s book might have the following in its metadata if you wanted fixed-layout with all pages displayed horizontally in landscape mode as spreads:

<meta property="rendition:layout">pre-paginated</meta>

<meta property="rendition:orientation">landscape</meta>

<meta property="rendition:spread">landscape</meta>

Similarly, you can apply multiple properties to a spine itemref element. Take note how properties are listed within the properties= quote marks and separated by a space.

<itemref id="titlepage" properties="page-spread-right rendition:layout-pre-paginated"/>

There are multiple examples of how to use the properties at the end of the EPUB 3 Fixed-Layout Documents draft.

In a future post, I will look at how these rendition properties are used to properly render fixed-layout ePUBs.

What do you think of this working draft? Has the IDPF make good decisions? How do you think it compares to Apple’s Fixed-Layout ePUBs and Barnes & Noble’s Digital Replica Plus ePUBs?