Combining reflowable and fixed layout pagination?

5 posts / 0 new
Last post

Does anyone know whether it is possible in the ePub3 standard format to combine
or mix reflowable and fixed layout pagination in the same publication: for
example fixed layout pagination is shown when the user holds an e-reading
device/reading app in landscape orientation, reflowable pagination is shown
when the device is held in portrait orientation. The content in fixed layout
can be the same content as in the reflowable view or could be entirely
different content. Furthermore, would this feature be supported in the
latest version of the iBooks app (and other reading apps)? Do you know of
any ePub3 publications already showcasing this feature? I am not referring
to publications in the proprietary iBooks format by Apple and created using
iBooks Author which I know supports the combination of reflowable and fixed
layout pagination, but which can only be made with iBooks Author and can
only be published in the iBookstore.

Very much looking forward to hear your views on this.

We are currently taking part in an innovation project focussing on the
possibilities that the ePub3 standard offers to create enhanced eBooks and
would like to implement this feature in an ePub 3 publication as a test

What you're asking is only sort-of supported through the new Fixed Layout specification. You can mix fixed layout documents and reflowable documents in the same publication, but there's no metadata to have the content automatically reflow or fix based on the way that the device is held (i.e., a fixed document is fixed regardless of whether the device orientation).

As it's not yet a formal part of EPUB 3, you can't rely on support for this metadata, but from what I've heard recently both iBooks and Google Play now support the metadata scheme. It's not quite what you need, but maybe is a start.

Alternating content based on the orientation of the device is more problematic than just whether it is fixed or reflowable. I could only picture that working without breaking the existing spine mechanics by adding metadata to the manifest items and then linking the alternate views together perhaps through a mechanism similar to fallback chains. That or having two different renditions of the same publication and switching between them based on the orientation (e.g., a fixed rendition in horizontal and a different reflowable rendition in vertical). There's a working group that's looking at rendition switching, but I don't believe that's on their plate, only switching between image and text based renditions of the same content. It's an interesting idea, but not one supported at this time.

And putting on the accessibility hat, I'd just pick a bit at the implications of changing content. Suddenly changing the content if someone re-orients the device may not be the friendliest thing to do, as how the device is held can be irrelevant to the reading experience. If a blind reader were listening to text-to-speech playback, for example, what happens when all/some of the content changes just because they shifted the device in their hands? (e.g., where does the reading system pick up?) Even sighted readers might find changing content a bit odd, depending on what exactly you're envisioning the change to be. Readers typically want to control those kinds of behaviours, rather than the reading system changing things automatically for them.

Anyway, hope this helps and good luck with the project.

Hm, I got hung up there on publication mechanics...

I wasn't even thinking about using media queries in your CSS to change from fixed to reflowable depending on the orientation. I'm not sure that reading systems rerender the styles on an orientation change, so it may only work the first time the document is loaded. You'd have to test support/behaviours.

And I suppose you could try to detect the orientation via script and change the current document that way -- whether through the orientation property, if available, or height/width. I'm assuming you could monitor for changes in orientation the same way you do in a browser on a tablet (as unreliable as those sometimes are) and change the document location to the more appropriate version. Something to try out, anyway.

There are potential problems with this kind of approach, too. If the content is more than one page in length, for exampe, you have to consider that you'll need to load the same view the person is currently viewing, and not sure how easily that would be possible if the content has changed. 

But some other avenues to try if your goal is just to push the boundaries.

Sorry, scratch all that! My brain's shutting down at the end of the week.

CSS alone wouldn't change that the document is fixed or reflowable. That can only be done by the metadata. Changing the stylesheet to reflowable would likely have a bad effect when the boundaries of the page remain fixed (e.g., content running off the screen and not being reachable).

Scripting also wouldn't work, as you'd still have to put both documents in the spine and mark one as fixed and the other as reflowable. You'd then have to do some ugly hacks like skipping documents based on orientation otherwise all your content would be duplicated. That's quite a house of cards that relies completely on scripting to work.

It is possible to select between different page templates, as well as select different content,  for portrait vs.  landscape mode and other dynamic conditions using the new EPUB Adaptive Layout specification ( ), published as an IDPF Informational Document in September.

In theory this could include fixed layout content in some circumstances although that hasn't been fully explored, and in particular the intersection of fixed-layout metadata and this new adaptive layout spec is TBD since these were developed in parallel.

But more fundamentally EPUB Adaptive Layout can enable a range of higher precision layouts to be specified, in a manner that's much more flexible than the iBooks Author one fixed landscape representation + one reflowable portrait representaiton. There may not be a need for a fixed rendition given the ability to represent complex page templates and dynamically adjust them and select/deselect appropriate content.

The fly in the ointment is that there are at present zero implementations of EPUB Adaptive Layout in reading systems. InDesign CS6 can generate markup that's compatible (by selecting the option, rightly labeled experimental since it predated the spec being formally published, "EPUB 3 with Layout"). Adobe publicly demoed this as "Liquid Layout" as long as a year ago but hasn't shipped anything that renders it yet. I do know of a number of other reading system vendors who have expressed a strong interest in supporting the specification, but I don't know about timeframes.

Another complication is that this originally IDPF proposal helped lead to related work in W3C CSS Working Group on regions, exclusions, and what's in effect a subset of EPUB Adaptive Layout built on them called CSS Pagination Templates ( ). But this has not stablized as there are competing CSS proposals for similar functionality as well as some controversy around the various approaches. That is one reason IDPF has only published EPUB Adaptive Layout as a technical note not a formal Recommended Specification. I do believe that we will nevertheless see multiple real-world implementations compatible with EPUB Adaptive Layout in the coming year.

Secondary menu