New in EPUB Fixed Layouts

To keep with a theme of looking at things that are coming soon, I thought today I’d give a quick update on the fixed layout properties.

One of the big changes in the 3.0.1 revision was to integrate the previous fixed layouts information document into the Publications and Content Documents specifications, and make support for fixed layouts required in reading systems. It was deemed to have earned its wings, if you will, and belong as a core feature of EPUB.

Now before you get too excited, required support only means required support for the rendition:layout pre-paginated value, but that’s the one you set to have the reading system generate a fixed-layout page. Reading systems aren’t required to support the peripheral properties, like orientation and synthetic spreads preferences, at least not beyond whatever they do by default (i.e., you’re compliant by doing nothing special, which is probably to be expected). Of course, you sort of hope that developers will strive to deliver more than the bare minimum.

The Apples and Googles of the world have supported fixed layouts (using this metadata) since not long after the original document was published, so this is a case where you won’t have to wait to start using the feature. I’m not aware of anyone who supports everything in fixed layouts yet, but that’s sort of a natural part of the evolution process.

If you’ve been following fixed layouts since that original document, the nice thing is that no backwards incompatible changes were introduced in integrating it into the core. Other than parceling the parts up between the two existing specifications, not a lot changed at all. The same properties and values are all still available.

But there are some new bits to be aware of…

Viewport Dimensions

The primary change made was to introduce a new property to allow the dimensions of the page to be specified in the package document: rendition:viewport. By default, when you set an XHTML content document as pre-paginated, the dimensions of the page are obtained from the viewport property in the head of the document:

<meta name="viewport" content="width=720, height=1280" />

While this is still required to be set, the rendition:viewport property reduces the work of the reading system by providing the information up front (i.e., without having to parse the XHTML document to get the dimensions before rendering it). So your package document metadata might now also include this  equivalent declaration:

<meta property="viewport">width=720, height=1280</meta>

Now a reading system doesn’t have to inspect each document time and again just to discover they all have the same dimensions.

You can override this property for individual documents, or set it if only a few documents are fixed layout, by attaching a refines attribute that points to the ID of the spine item the new dimensions apply to. For example, the cover page might be specified as slightly bigger by adding this override:

<meta property="viewport" refines="#cover">width=1152, height=2048</meta>

At this point, if you’re a content creator, you’re probably rolling your eyes that you now have to specify dimensions all over the place. It is a very reading system-friendly feature to add, I’ll grant that. If up-front metadata was preferred, dropping the content-level declarations at the same time might seem to make sense, but then existing content would no longer work. This is how you end up stuck with these sorts of mixed requirements.

If one declaration should have been optional, however, my preference would have been to have it the other way around. If developers all jump on the package declarations and build in support, maybe the content-level declarations will become optional again in a future revision. It seems like the developers should be the ones suffering for a suboptimal decision, not the content creators.

For now, it’s not clear if the new mechanism will become a de facto requirement or not. You can keep specifying dimensions only in the content, but vendors may start requiring the package declarations at some point. I can’t see that far in my crystal ball.

Content Flow

Specifying how content documents should be run together started off as a fixed layout request, but ultimately became a general layout property. I’m going to cover it here, regardless, since it has use for fixed layouts.

The expectation with items in the spine is that a page break is assumed before each. For reflowable content, this is why each new spine item’s content begins at the top of a new page. With fixed layouts, the page-to-page progression can be controlled with greater precision, since the content never grows or shrinks depending on user settings like it can in a reflowable document.

While that’s all fun and great, (dynamic) pagination is not the only way to present documents, and in many cases is not at all how the author desires them to be read. Think of scrolls, for example. While some reading systems provide the option to scroll content documents instead of having them dynamically paginated, only the user has the ability right now to determine which mode to use.

To redress this deficiency, a new rendition:flow property was added. Content creators can use this property to define the following three preferred modes for rendering their documents:

  • paginated – Traditional dynamic pagination is preferred.
  • scrolled-doc – Rendering as a single scrolling document is preferred, with a page break after.
  • scrolled-continuous – Rendering as a single scrolling document is preferred, but without a page break after (i.e., all consecutive documents marked should be rendered one after the other as a continuous scroll).

In typical EPUB layout property fashion, you can specify these values for the publication as a whole or for individual documents within it. If I wanted my whole publication to be one long running scroll, I’d just set the scrolled-continuous value in the package metadata like this:

<meta property="rendition:flow">scrolled-continuous</meta>

You can set the same for pre-paginated content, like a comic book, so that each page would scroll into view one after another.

But as this property only defines a preference, support will probably always be an open question. It’ll only be valid to use this property once the 3.0.1 revision is finalized, too.

Layout Changes

I’m not going to spend a lot of time and energy on the little layout clarifications that were also made. Here’s a quick recap of some key issues:

  • When you’re try to put together a synthetic spread, having a big ugly gap between the two pages in the spread isn’t the most desirable rendering feature. The specification now recommends that there be no gap between the pages.
  • When you create a fixed layout, you typically want it to occupy the greatest amount of space possible. While this desire is sometimes complicated by differing aspect ratios between the device and content, the specification now states that reading systems should not insert borders, margins, header and footers and give the content the greatest amount of space possible.
  • Some people were confused by the use of media queries in the style sheet examples, taking them as also setting the viewport. It was clarified that media queries have no effect on the viewport dimensions, only on which style sheet is applied based on the device screen.
  • It was also noted that the spec does not state what the expectation is when two pages in a synthetic spread are different sizes. No change was deemed necessary to the specification, but be aware that the reading system will scale the larger to fit with the smaller in putting together the spread.

Go Forth and Multiply

So that’s it for fixed layout metadata fix for today. Take what you have learned and use it wisely… since not everything is valid yet.

And if you’re scratching your head and wondering what you just read, you probably need to brush up on fixed layout metadata. Reading the specs is a quick free way to learn things, but there’s also the free BISG field guide.

The best practices book has a review of the properties if you have it already, but as they were still quite new at the time, I’m not going to plug it as the greatest resource. We did try to outline some accessibility pitfalls in the book, though, which was a new addition from the Accessible EPUB 3 freebie. The field guide is aligned with these practices, too, as far as I’m aware.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.