AZARDI and ePub3 Fixed Layout

Opinion & Overview

This is an article on the considerations and decisions made to make fixed-layout, and more importantly fixed/flow layout work hard for appropriate content in the AZARDI context. We implemented a custom fixed layout system for AZARDI in 2011 just after the main specification was released and are now bringing AZARDI in line with the specification, with some innovations.

We understand that fixed layout, interactivity and fluid navigation were the reasons for any publisher to even consider using ePub3; otherwise ePub2 was just fine. The publisher has to have the type of content, or want to innovate with new content to make ePub3 useful and valuable.

A large part of the IDPF specification is a net cost increase in production for publishers with no visible business benefits. Our mission is to correct that cost imbalance and make it practical and realistic for publishers to innovate and expand their business strategies.

Kindle and iBooks fixed layout is promoted primarily as a "kids book" feature, but both have agendas for education content. Apple has gone as far as to make mixed flow/fixed a proprietary format via their iBooks Publisher application bypassing ePub3. That is an iTunes lock-in gambit more than anything real.

It is really time to move forward.

Helping Publishers Get to Market

Because we work on a daily basis with real publishers, with real budgets and real customers who have to address real semsters and real schedules it is essential that we can provide solutions that wring every gram of value from each production, fulfillment and marketing dollar spent.

We state that it is unlikely that many reading systems will support the full capabilities of the current Fixed Layout spec, or even examine the potential of the set of properties available. Not because it is hard, but because the consultants and those who work with fear-marketing of real content production, distribution and fulfilment make their living "not" giving substantial solutions.

AZARDI is fully IDPF fixed layout complete. It offers presentation features and user experiences that can be produced cost-effectively (especially with IGP:Digital Publisher) and which will never be possible from the current  desktop applications.

From the IDPF forum "...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 the device orientation)..." This is patently wrong and a simplistic reading of the fixed layout properties and the use of content in the world today. Theory should not be the decider of the actions of the properties. Implementation and demonstration by practitioners is the proper method of specification property interpretation.

The challenge of working with moving targets

The IDPF continues to lumber on writing specifications without implementations. That's a world first, and few seem to understand it is a business strategy bushwack.

For example it will be interesting to see if the "ePub3 Adaptive Layout" gains any traction given that it is an Adobe driven exclusive. It is without doubt the specification that should never have been written. It's Pinochio in the land of donkeys.

Perhaps the elves at Adobe are working madly behind the scenes to release ADE 24.0 or something that does what the specification says is going to be useful for about 0.05% of digital content. They must be planning to surprise the market because there recently released ADE 2.0 is a content engagment and presentation disaster.

Real Content Engagement Experiences

The ultimate shock of all of this is the insistence on pagination and print simulacrum as if that is what is needed with digital content. Mobile devices have taught people to engage with content in a scrolling, zooming, swiping manner. The rules of both print books and best web practices hit the dust two years ago when applied to valuable publisher content.

The other ultimate criticism of the IDPF approach is its myopic approach.

In the interest of full disclosure Infogrid Pacific are not in the IDPF. The main reasons are that we are small, we are a practitioner organization and are at the delivery end of the digital content game. We may not like what is written in IDPF specifications, we don't have to like it or agree with it, but we have to do the best we can at implementing what can be implemented. Sensibly! We are one of the real-world filters of specification crap!

AZARDI has the the objective to enable fixed/flow content on all platforms and devices, and ensure the consistent behaviour of that content under the readers control.

Phew! Now back to what can be done, and what we are doing to offer publishers better value for their digital content expenditure.

Analysing What's Available

Here is a quick summary of features and behaviour as we have observed them for the two applications available with FLO features. Note these are NOT criticisms (IDPF support ranters) but observations we have made as we work out what we want AZARDI to do. Practioners do what they need to do to exploit the heart of the specification.

This list was created 2012-11-20 and may be different when you read it.

Apple iBooks

1. Can do prepaginated spreads. Does excellent job on two page spread portrait and landscape. Viewport zoom feature strengthens the experience on the device.
2. Can do spread-none plus one of orientation-portrait or orientation-landscape but only in a single aspect and orientation locked document.
3. Cannot do prepaginated and reflowable mixed.
4. Cannot do mixed spread and mixed spread none.
5. Always forces the first page right (arbitrary token cover). Does not understand epub:type="cover" property. This considerably screws cross platform compatability. You will always be designing down for iBooks fixed layout.
6. All the above because it does not take any notice of spine properties.
7. Does not take any notice of XHTML changing viewport dimensions (size or aspect ratio) even in spread mode.
8. Assumes a spread is an imitation print book (which is probably a reasonable assumption) with paper chrome.

Readium

1. Can do FLO spreads. Does excellent job on two page spread portrait and landscape.
2. Can do prepaginated and reflowable sequentially mixed.
3. Appears displays first page as cover and forces the first page to center if the book use the epub:type="cover" property. Powerful.
4. Does a good job on on two page spread portrait, but limited by the quality of the Chrome Webkit rendering engine (sucks).
5. Cannot do mixed spread-both and spread-none interchangeably. User has to change the single or double viewport option from the interface.
6. Cannot handle multiple fixed pages with rich interactions. Launches them all at the same time on book load.
7. Does not fill viewport with spread-none orientation-landscape pages (uses half the available screen area).
8. Assumes a spread is an imitation print book (which is probably a reasonable assumption) with a rather dirty looking paper chrome.

In both cases apparently books will have to be created with an opening single page before starting spreads.

epub:type Properties

We decided that fixed layout books was a good starting point to start defining uses and actions of the epub:type properties.

Readium does a good job here and puts covers in the middle and title pages to the right just like a good print book. We uplift from that approach.

We have defined the following AZARDI behaviours and would welcome feedback of other suggestions. These are of course pretty much print book simulations, but they make fixed layout books both work with iBooks and Readium approach and allow users to over-ride them where appropriate.

epub:type="cover" Center the page in the viewport in either orientation if there are no provided spine properties.

epub:type="titlepage" Align the page to the right if there are no provided spine properties.

epub:type="copyright" Align the page to the left if there are no provided spine properties.

epub:type="part" Align the page to the right if there are no provided spine properties.

This was a modest beginning, but at least seems to be a start in using epub:type in a useful and predictable manner. It aligns AZARDI behaviour with the Readium behaviour.

Fixed

Implementing the core fixed layout concept (excluding spreads) is pretty straight forward.

You have a viewport and you want to be able to maximize the content into the viewport. The orientation options are portrait, landscape and both. With both the viewport should be filled with the content to the maximum

A desktop monitor can be a bit of beast to rotate, so behaviour has to be explicitly decided for the monitor version (just forgetting about devices for a while) and handled so the user can resize the window and make it portrait and landscape at whim.

Tablet devices are easy. If the device is rotated set and maximize the view for the viewport orientation following the fixed layout rules. There is no other resizing possible.

Please note depending on your browser the code may flow outside the frame in these examples. That has been left in place so it can be seen.

Fixed Layout Landscape

<meta name="viewport" content="width=xxx, height=yyy"/>

<meta property="rendition:layout">pre-paginated</meta>
<meta property="rendition:orientation">landscape</meta>
<meta property="rendition:spread">none</meta>

<item properties="rendition:spread-none 
    rendition:orientation-landscape" />

 Fixed Layout Portrait

<meta name="viewport" content="width=xxx, height=yyy"/>

<meta property="rendition:layout">pre-paginated</meta>
<meta property="rendition:orientation">portrait</meta>
<meta property="rendition:spread">none</meta>

<item properties="rendition:spread-none 
    rendition:orientation-portrait" />

Spread

Next we had to handle the spread issues. The options are

1. spread when viewport is landscape,
2. spread when viewport is portrait,
3. spread with both orientations, and
4. don't spread.

After considerable "mucking around" we decided that in the case of the application window (for AZARDI Desktop) or browser window (for AZARDI Online) view, we have to ignore the size and aspect ratio of the window, obey the  fixed layout orientation and spread properties and maximize the page(s) into the available viewport.

With this approach, if spread is auto, portrait or landscape you will always get a spread. You will not get a spread if it is set to none. Here is the map.

This honours the book designers intentions while giving predictable behaviour to the content. The user must adjust the window to make the content fill the available viewport or be adjusted for a comfortable reading size.

Of course in a tablet there is no requirement for considering window orientation.

Fixed Layout Landscape Spread

<meta name="viewport" 
content="width=xxx, height=yyy"/>

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

<item properties="
  rendition:spread-landscape 
  rendition:orientation-landscape" />

Yes. You can do a spread in portrait orientation. There are a lot of reason why this can be valuable with certain types of content. 

Fixed Layout Portrait Spread

<meta name="viewport" 
  content="width=xxx, height=yyy"/>

<meta property=
"rendition:layout">pre-paginated</meta>
<meta property=
"rendition:orientation">landscape</meta>
<meta property=
"rendition:spread">none</meta>

<item properties="
rendition:spread-none 
rendition:orientation-landscape" 
/>

Mixed Spread

That disposes of the yesterday Apple-like stuff. Now things start to get interesting.

A mixed spread is where page orientation and size are not the same. We decided to handle mixed spread because it may need handling, we saw potential uses and felt there had to be a test-book driven, well defined set of behaviours. That means there may be a small and large page with different orientations side by side in a spread.

We still wanted to fill the available window/viewport. So that meant making a decision about the center of a mixed spread.

Rather than compose the spread from the center, we decided to compose it from the left and size and center to the viewport. This means the two pages are framed side by side and have the same tranformation applied to the spread. With this approach content such as font-sizes will remain proportional during the transform process on the two displayed pages, even if the pages are different sizes.

This was important. The AZARDI reading system never assumes a page size but always uses the explicit page size set in the XHTML metadata of each page, scaled to the viewing window.

Mixed Spread Landscape

Mixed Spread Portrait

The test book has some crazy permutations of this because it is a test book. But it does allow you to see both the flexibility and behaviour of this in extremis.

Mixed fixed and Flow Spreads

This set of features is a significant exploitation of the IDPF vocabulary and the possible rendition property combinations.

The intention of the specification is that if a page is made reflowable it appears as a normal page. This makes sense.

However it is possible to exploit the properties to delivery a fixed page and a flowing page side by side by exploiting the spine properties.

This enables the easy creation of some very interesting, useful and powerful page size and orientation combinations. This custom interpretation of the properties is also unlikely to clash with any other reading systems so is relatively safe to use. It works like this:

1. Define a book as a fixed layout book
2. In the spine define a page to be reflowable. It becomes a standard stand-alone reflowable page.
3. Now add into the spine a spread-both property and page-spread-right (or left).

AZARDI takes notice of the specific combination of properties and puts the reflowable page into a width controlled viewport.

Fixed Flow Combo

There is potential in the fixed layout properties to have fixed and flow properties available in spreads. This can be done semantically correctly with the correct combination of fixed-layout properties.

<item id="page1" linear-"yes" properties-"spread-both; page-spread-left rendition:pre-paginated">
<item id="page2" linear="yes" properties-"spread-both; page-spread-right rendition:reflowable">

This set of properties can only literally be read as:...

I want to be a spread whether portrait or landscape, and on the left I want a pre-paginated presentation and on the right a reflowable presentation.

Now you can create windows with fixed content left or right, and flowing content on the other side.

Flow Flow Combo Spread

Additionally you can create two flowing pages side-by-side like this.

<item id="page1" linear-"yes" properties-"spread-both; page-spread-left rendition:reflowable">
<item id="page2" linear="yes" properties-"spread-both; page-spread-right rendition:reflowable">

Linked Fixed to flow and reverse spreads

After more "tinkering" around we felt the textbook market in particular would like to have a fixed navigation component on the left (for example) that would then change fixed or reflow pages on the right. Quite an app'y approach.

Again, the challenge was how to do this within the rules and spirit of the specification, and create FLO books that would not "clash" with other reading system FLO implementations.

We decided that a series of right pages following a left page could occupy the space on the right without disrupting more rigid interpretations of the spec.

So when you navigate to a left FLO page, and there is a series of right pages following, the reader doesn't leave an empty left frame.

Now fixed right is relatively important for left-to-right books where printy-people like books and parts and things to always open on the left. We are reasonably certain that the other reading systems will use the page-spread-right in a relatively simple manner.

Because AZARDI builds and analyses the spine before presenting content it was easy to imply the rules from the property patterns by combining linear and flow properties.

<item id="page1" linear-"yes" properties-"page-spread-left rendition:spread-both ">
<item id="page2" linear="no" properties-"page-spread-right rendition:spread-both">
<item id="page3" linear="no" properties-"page-spread-right rendition:spread-both">
<item id="page4" linear="no" properties-"page-spread-right rendition:spread-both">

This approach uses the combination of two properties to explicitly put linked no-flow pages on the right of the flow page if the left page

Linked Fixed Flow

Please note the links are not interactive in this concept demonstration interface.

Why do all of this?

It is important to be able to create new digital content that is not just a simile of print books. It's not about ignoring print book simulations, rather building new alternatives. The fact is content Apps cost too much,  so the flexibilty of the IDPF FLO specification and the interpretation of it in a reading system context is important for the speed and cost of content innovation.

For publishers interested in creating and distributing fixed/flow content of distinction AZARDI is the reading system that will make it happen. It is fully standards compliant, fails gracefully and transparently for systems that don't use the advanced interpretation features of rendition, and pushes digital content forward.

While the present fixed layout book approach has been created as a metaphor for a print book, the combination of fixed layout and reflowable text is potentially much more powerful.

The interpretations of the FLO properties is finite. Assuming all ePub3 reading system developers put the content and user experience first amazing things can happen with digital content. 

The IDPF must ensure they don't build rigidity into the ePub specifications which appears to be a danger some aspects of the current approach. The elasticity and interpretability of the current specification makes it very special and useful to publishers for addressing a wide range of innovative content presentation requirements into the future.

If novels are your thing this will be of no interest. If learning, education, training and experiential content is what you do these new features in AZARDI will make creating new content experiences for readers a fast and straightforward process under real cost control.