EPUB 3 Fixed-Layout Documents

Working Group Draft 20120305

This version:
http://www.idpf.org/epub/fxl/epub-fxl-20120305.html
Latest version:
http://idpf.org/epub/fxl/
Previous version:
http://www.idpf.org/epub/fxl/epub-fxl-20120301.html

Editors

Markus Gylling (IDPF), Dave Cramer (Hachette)

Authors

Takeshi Kanai (Sony), Peter Sorotokin (Adobe), Roger Webster (Barnes & Noble), James Lester (Barnes & Noble), Brady Kroupa (Barnes & Noble), Garth Conboy (Google), Brady Duga (Google), MURATA Makoto (JEPA), Theresa O’Connor (Apple), Luc Audrain (Hachette Livre), Hadrien Gardeur (Feedbooks)

Status of this Document

This is an IDPF Working Group draft that has no official status at this time. It may be updated, replaced, or rendered obsolete by other documents at any time. Its publication does not imply endorsement by the IDPF membership or the IDPF EPUB 3 Working Group.

Purpose and Scope

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.

note

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 rendition:layout property

Name

rendition:layout

Description

Specifies whether the given Publication or spine item is reflowable or pre-paginated.

Value

reflowable | pre-paginated

Usage

Package Document meta element

Package Document itemref element

Initial

In meta: reflowable

In itemref: inherited from meta

Cardinality

In metadata: zero or one

In itemref: zero or one

Usage

When the rendition:layout property is specified on the Package Document meta element, it indicates that the paginated or reflowable layout style (refer to Allowed values below) applies globally for the given Publication (i.e. for all spine items).

As ‘reflowable’ is the initial value of this property in the meta usage context, this value must be assumed by Reading Systems as the global value if no meta element carrying this property occurs in the Package Document instance.

The rendition:layout property may also be specified locally on the Package Document spine itemref element, and will, in this case, override the global value for the given spine item. (Refer to Specifying name-value pairs on the spine itemref element for syntactical rules specific to local specification.)

Allowed values

The following values are defined for use with the rendition:layout property:

reflowable
The given spine item is not pre-paginated. Reading Systems may apply dynamic pagination when rendering this spine item.
pre-paginated
The given spine item is pre-paginated. Reading Systems must produce exactly one page when rendering this spine item. (Refer to Content dimensions for rules regarding dimensional declarations.)

note

Reading Systems typically restrict or deny the application of User or User Agent stylesheets to pre-paginated documents, since as a result of intrinsic properties of such documents, dynamic style changes are highly likely to have unintended consequences. Authors should take into account the negative impact on usability and accessibility that these restrictions have when choosing to use pre-paginated instead of reflowable content. Refer to Guideline 1.4 - Provide text configuration of the W3C User Agent Accessibility Guidelines for related information.

The rendition:orientation property

Name

rendition:orientation

Description

Specifies which orientation(s) the Author intends for the given Publication or spine item to be rendered in.

Value

landscape | portrait | auto

Usage

Package Document meta element

Package Document itemref element

Initial

In meta: auto

In itemref: inherited from meta

Cardinality

In metadata: zero or one

In itemref: zero or one

Usage

When the rendition:orientation property is specified on the Package Document meta element, it indicates that the intended orientation applies globally for the given Publication (i.e. for all spine items).

As ‘auto’ is the initial value of this property in the meta usage context, this value must be assumed by Reading Systems as the global value if no meta element carrying this property occurs in the Package Document instance.

The rendition:orientation property may also be specified locally on the Package Document spine itemref element, and will, in this case, override the global value for the given spine item. (Refer to Specifying name-value pairs on the spine itemref element for syntactical rules specific to local specification.)

Allowed values

The following values are defined for use with the rendition:orientation property:

landscape
The given spine item is intended for landscape rendering.
portrait
The given spine item is intended for portrait rendering.
auto
The given spine item is not orientation constrained.

Reading Systems that support multiple orientations should, unless the given value is 'auto', convey the intended orientation to the user. The means by which the intent is conveyed is implementation-specific.

The rendition:spread property

Name

rendition:spread

Description

Specifies the intended Reading System synthetic spread behavior for this Publication or spine item.

Value

none | landscape | portrait | both | auto

Usage

Package Document meta element

Package Document itemref element

Initial

In meta: auto

In itemref: inherited from meta

Cardinality

In metadata: zero or one

In itemref: zero or one

Usage

When the rendition:spread property is specified on the Package Document meta element, it indicates that the intended synthetic spread behavior applies globally for the given Publication (i.e. for all spine items).

As ‘auto’ is the initial value of this property in the meta usage context, this value must be assumed by Reading Systems as the global value if no meta element carrying this property occurs in the Package Document instance.

The rendition:spread property may also be specified locally on the Package Document spine itemref element, and will, in this case, override the global value for the given spine item. (Refer to Specifying name-value pairs on the spine itemref element for syntactical rules.)

Allowed values

The following values are defined for use with the rendition:spread property, where synthetic spread is defined as the rendering of two adjacent pages simultaneously on the device screen:

none
Reading Systems must not incorporate this spine item in a synthetic spread.
landscape
Reading Systems should incorporate this spine item in a synthetic spread only when the device is in landscape orientation.
portrait
Reading Systems should incorporate this spine item in a synthetic spread only when the device is in portrait orientation.
both
Reading Systems should incorporate this spine item in a synthetic spread regardless of device orientation.
auto
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.

When synthetic spreads are used in the context of XHTML and SVG Content Documents, the dimensions given via viewport/viewBox metadata represents the size of one page in the spread.

note

Refer to 3.4.12 The spine Element for information about declaration of global flow directionality using the page-progression-direction attribute and that of local page-progression-direction within content documents.

Refer also to Issue 205 for discussions on forthcoming specifications of precedence rules for the page-progression-direction attribute and the writing-mode and direction properties within XHTML Content Documents.

The page-spread-* properties

Names

rendition:page-spread-center

and, as defined in [Publications30]
page-spread-left and page-spread-right

Description

Specifies the forced placement of a Content Document in a synthetic spread

Usage

Package Document spine itemref element

Cardinality

Zero or one

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.

The page-spread-left and page-spread-right properties are defined in [Publications30]. This document defines one additional property, rendition:page-spread-center, 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.

The page-spread-left, page-spread-right and rendition:page-spread-center properties apply to both pre-paginated and reflowable content, and they only apply when the Reading System is creating synthetic spreads.

Usage of rendition properties in the EPUB 3 Package Document

Prefix Mapping

When the metadata properties defined in this document are included in an EPUB 3 Package Document, they must be mapped to the URI http://www.idpf.org/vocab/rendition/# using the prefix attribute, as defined in EPUB Publications 3.0 vocabulary association.

<package …  prefix="rendition: http://www.idpf.org/vocab/rendition/#"> 
    … 
</package> 

Implementors should note that future revisions of [Publications30] may establish the vocabulary represented by the URI http://www.idpf.org/vocab/rendition/# as a reserved vocabulary. In this case, the result will be that a) explicit mapping declaration using the prefix attribute will no longer be applicable, and b) the prefix ‘rendition’ will be reserved for this vocabulary. Future revisions of [Publications30] may also integrate the properties defined here into the Package Document default vocabulary. In this case the properties defined herein will be allowed to occur in Package Documents without a prefix.

Note that Package Documents may include additional proprietary metadata properties that pertain to layout expressions (refer to Vocabulary Association Mechanisms for further information on extensibility). Reading Systems must ignore such expressions if they conflict behaviorally with the property semantics defined in this document.

Specifying name-value pairs on the spine itemref element

In the context of the properties defined in this document, and when specifying property name-value pairs in the properties attribute on the Package Document spine itemref element, the following syntax must be used.

The property name and value is concatenated into a single string using a hyphen-minus character (U+002D) as separator. Note that leading and trailing whitespace around the separator character is not allowed.

For example, to express that the rendition:layout property has the value ‘reflowable’ for the given spine item, the string ‘rendition:layout-reflowable’ is used:

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

Content dimensions

This section defines rules for the expression and interpretation of dimensionality properties of XHTML and SVG Content Documents [ContentDocs30] and bitmap images.

This document does not define how the content (and, specifically in the case of XHTML and SVG, the initial containing block) will be placed within the Reading System content display area.

Content dimensions for XHTML and SVG

Each XHTML and SVG spine item which has the ‘pre-paginated’ value set for its rendition:layout property must contain the viewport (for XHTML) or viewBox (for SVG) dimension expressions as defined below.

For both XHTML and SVG Content Documents, the dimension (viewport/viewbox) expressions define the CSS initial containing block (ICB) expressed in CSS Pixels [CSS].

Expressing ICB dimensions in XHTML

In XHTML, the ICB dimensions are expressed using the viewport meta tag using syntax as per [MetaTags]. In this version of this document, only the width and height expressions are required to be recognized by Reading Systems.

Example:

<head>
    …
    <meta name="viewport" content="width=1200, height=600"/>
    …
</head>  

Reading Systems must clip XHTML content to the ICB dimensions declared in the viewport meta tag, and therefore content positioned outside of the initial containing block is not going to be visible. When the ICB aspect ratio does not match the aspect ratio of the Reading System content display area, Reading Systems may position the ICB inside the area to accommodate the user interface; in other words, added letter-boxing space may appear on either side (or both) of the content.

Expressing ICB dimensions in SVG

In SVG, the ICB dimensions are expressed using the viewBox attribute [SVG11].

Example:

<svg xmlns="http://www.w3.org/2000/svg"
    version="1.1" width="100%" height="100%"
    viewBox="0 0 844 1200">
    …
</svg> 

Content dimensions for bitmap images

Bitmap image dimensions are expressed through the intrinsic physical dimensions (i.e the actual physical pixel counts for width and height) of the given bitmap, not considering “resolution tags” or any form of transformation.

Note that this method of retrieving content dimensions only applies when bitmap images are referenced directly from the spine (i.e. not embedded in XHTML or SVG Content Documents).

Appendix A. Examples

Example 1

Fully fixed-layout content, intended to be rendered using synthetic spreads in landscape orientation, and no spreads in portrait orientation.

Package Document

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

XHTML

All content documents contain:

<meta name="viewport" content="width=512, height=600"/>

Note: to leave the spread behavior up to the Reading System, the rendition:spread element is either omitted or set to ‘auto’.

Example 2

Fully fixed-layout content, intended to be rendered without synthetic spreads, and locked to landscape orientation.

Package Document

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

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

XHTML

All content documents contain:

<meta name="viewport" content="width=1024, height=600"/>

Example 3

Reflowable content with a single fixed-layout page (title page), where the fixed-layout page is intended for right-hand spread slot if the device renders synthetic spreads.

Package Document

<meta property="rendition:layout">reflowable</meta>
<meta property="rendition:spread">auto</meta>        
…

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

XHTML

The content document representing the title page contains:

<meta name="viewport" content="width=684, height=1024"/>

Note that in this example, both the rendition:layout and rendition:spread properties are set to their initial values, which means that these two meta elements can be omitted without any impact on the resulting expression.

Example 4

Fully fixed-layout content where synthetic spreads — if used — must be disabled for a center plate.

Package Document

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

<meta property="rendition:spread">auto</meta>        
…
<itemref id="center-plate" properties="rendition:page-spread-center"/>

XHTML

The content document representing the center plate contains:

<meta name="viewport" content="width=1024, height=600"/>

Note that even though the center plate viewport dimension expression indicates landscape orientation, the author has omitted the orientation property, leaving it to the Reading System to decide how to handle the situation. Note also that the rendition:spread=none expression is not needed here, as the rendition:page-spread-center property already specifies semantics that dictates that synthetic spreads be disabled.

Note finally that in this example, the rendition:spread property is set to its initial value, and so it can be omitted without any impact on the resulting expression.

Example 5

Reflowable content with a fixed-layout two-page center plate that is intended to be rendered using synthetic spreads in any device orientation. The author has left spread behavior for the other (reflowable) parts of the publication undefined, since the global value of rendition:spread is initialized to ‘auto’.

Package Document

<spine page-progression-direction="ltr">                
    …
    <itemref id="center-plate-left" properties="rendition:spread-both page-spread-left"/>
    <itemref id="center-plate-right" properties="rendition:spread-both page-spread-right"/>
    …
</spine>

XHTML

The two content documents representing the center plate contains:

<meta name="viewport" content="width=512, height=600"/>

Example 6

Fully fixed-layout content which includes three separate stylesheets used for three different device categories, using [MediaQueries].

Package Document

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

XHTML

<link rel="stylesheet" href="eink-style.css" media="(max-monochrome: 3)"/>
<link rel="stylesheet" href="skinnytablet-style.css" media="((color) and
    (max-height:600px) and (orientation:landscape), (color) and (max-width:600px)
    and (orientation:portrait))" />
<link rel="stylesheet" href="fattablet-style.css" media="((color) and
    (min-height:601px) and (orientation:landscape), (color) and (min-width:601px)
    and (orientation:portrait)" />

Example 7

Japanese manga in the right-to-left page progression direction. Each content document is a very simple HTML containing a bitmap and nothing else, and does not have associated CSS stylesheets.

Package Document

<meta property="rendition:layout">pre-paginated</meta>
<meta property="rendition:spread">landscape</meta>
…
<spine page-progression-direction="rtl">
    …
</spine> 

Note that the page progression direction for the HTML content documents is 'ltr' rather than 'rtl'. This is because the reading system typically uses the default CSS stylesheet and the page progression direction implied by it is 'rtl'. Each spread is created by first using the right page and then the left page.

XHTML

All XHTML content documents contain:

<meta name="viewport" content="width=512, height=600"/> 

Example 8

A fully fixed-layout publication with bitmap images as the top-level content representation, using XHTML fallback.

Package Document

                    
<meta property="rendition:layout">pre-paginated</meta>
…
<manifest>
    <item id="ch1" href="ch1.png" fallback="ch1x" … />
    <item id="ch2" href="ch2.png" fallback="ch2x" … />
    <item id="ch1x" href="ch1.xhtml" … />
    <item id="ch2x" href="ch2.xhtml" … />    
</manifest>
<spine>
    <itemref idref="ch1" />
    <itemref idref="ch2" />
</spine> 

XHTML

All fallback XHTML content documents contain:

<meta name="viewport" content="width=1024, height=600"/> 

Appendix B. Mapping Tables

The tables below describe how the vocabulary defined in this document maps to some of the pre-existing proprietary metadata vocabularies for fixed-layout expressions.

Amazon KF8 Children’s Format

Amazon Property IDPF Equivalent (prefixes omitted for clarity)

fixed-layout (true | false)

layout (reflowable | pre-paginated)

original-resolution (width, ‘x’, height)

viewport (XHTML meta)

orientation (portrait | landscape)

orientation (portrait | landscape | auto)

book-type (children | comic)

not applicable

RegionMagnification (true | false)

not applicable, proprietary

Sony Fixed-Layout

Sony Property IDPF Equivalent (prefixes omitted for clarity)

fixed-layout (true | false)

layout (reflowable | pre-paginated)

orientation (portrait | landscape | auto)

orientation (portrait | landscape | auto)

page-spread (full | double | auto)

rendition:spread (none | portrait | landscape | both | auto)

overflow-scroll (true | false)

defined in CSS

viewport

viewport (XHTML meta)

Note that for page-spread, the values for 'portrait' and 'both' would all map to 'double', 'landscape' would map to 'auto', and 'none' would map to 'full'.

Apple Fixed-Layout

Apple currently stores some of this metadata in an XML file in META-INF.

Apple Property IDPF Equivalent (prefixes omitted for clarity)

fixed-layout (true | false)

layout (reflowable | pre-paginated)

viewport (XHTML meta)

viewport (XHTML meta)

orientation (landscape-only | portrait-only | none)

orientation (landscape | portrait | auto)

platform name

no equivalent

open-to-spread (true | false)

no equivalent

Appendix C. Note on the use of CSS absolute positioning in EPUB 3

An informative note at the end of Section 3.3.1 ("CSS 2.1") of EPUB 3 Content Documents has been a source of some confusion relative to fixed layout and EPUB 3. This appendix intends to clarify that note until the specification is updated accordingly.

The note states: “The ability of Reading Systems to paginate absolutely positioned layouts is not guaranteed, so reliance on absolute positioning is discouraged. Reading Systems might not support these property values.”

First, given its location in the CSS section of the specification, it should be noted that this statement is only applicable to fixed-layout documents that utilize CSS. Second, this note does not imply that the “absolute” value of the position property is not in the EPUB 3 CSS profile; position:absolute is in fact part of the profile, since it is part of its baseline (CSS 2.1). Only the fixed value is excluded from the EPUB 3 CSS Profile (as stated in normative prose above the note).

Lastly, this note does not discourage use of CSS for absolutely positioned layouts but only reliance on such for content expected to be delivered to arbitrary Reading Systems, which as stated may not support these values. In particular, EPUB 2.x Reading Systems will likely not support these values, as they were not included in the EPUB 2 CSS Profile. Many uses of absolutely-positioned CSS will gracefully degrade if these property values are ignored, and such graceful degradation behavior (non-reliance) is encouraged.

References

[ContentDocs30]EPUB Content Documents 3.0

[CSS]Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification

[MediaQueries]Media Queries

[MetaTags]Supported Meta Tags (informative)

[Publications30]EPUB Publications 3.0

[SVG11]Scalable Vector Graphics (SVG) 1.1 (Second Edition)