Warning:
This wiki has been archived and is now read-only.

Functional Requirements for Pagination

From Digital Publishing Interest Group
Jump to: navigation, search

Note: although these are simply functional requirements, we do hope that many of these will be implemented in a declarative fashion. CSS, even if it's in the form of custom properties talking to JS prolyfill libraries, is going to be much easier to use for document authors than writing Javascript.

Describing Pages

Document authors should be able to control:

  1. page margins
  2. page orientation (if device allows orientation changes)
  3. page display
    1. number of pages to display in viewport—one page (one-up), two pages (two-up) etc.
    2. spatial arrangement of pages—horizontal, vertical, other
  4. the entire viewport (i.e. prevent UA chrome from interfering with content)
  5. ability to simulate bleeds (art extending beyond edge of viewport)
  6. running headers and footers
  7. page numbers or other progress indicators
  8. master pages or named pages
    1. support for sequencing of master pages that content flows through—often the first page or two of a document may use a different page style

In many of the above cases (especially things like margins and orientation), end users should be able to override the author and user-agent stylesheets

Content Rendering in Pages

Latinreq covers various typographical requirements for laying out content in pages.

  1. Control of widows
  2. Alignment of facing pages
  3. Displaying no fewer than n lines on the last page of a section (n is often around 5)
  4. Multiple columns in pages
  5. Mechanism for controlling line breaks to meet typographic requirements
    1. details TK
  6. Mechanism for copyfitting
    1. details TK

Changing Page Content

  1. Use alternate content for running heads etc. (if chapter title is too long, editors sometimes specify a shorter version)
  2. Rewrite link text to be more user friendly ("next page" instead of "page 391" if appropriate)

Page Transitions

  1. User can go to next page, previous page, or random [suggest "specific" not "random"] page via a user interface provided by the user agent
  2. Page transitions work not only within HTML files, but across separate files (for example, a page turn gesture should move between the last page of ch01.html and the first page of ch02.html)

Interacting with Pages

Page Representation in the DOM (or box tree?)

  1. Provide a mechanism for accessing pages and their contents
  2. Provide a mechanism for changing properties of a page (eg margins, background, etc)
  3. Provide a mechanism for accessing lines (may be needed to address many other requirements)

Page from Element

  1. An API for determining a page or pages associated with a particular element
  2. An API for determining which page a given offset into a text node is on.

Page Identification

  1. A mechanism to identify a specific page in an ebook.
  2. Must be storable.
  3. Must be sortable.
  4. Must adjust to reflowable content (eg get a reasonable page when the size of the viewport changes).

Page Events

  1. Define a list of events a User Agent should fire related to pages.

Support for Existing Specifications