Difference between revisions of "Writer/ToDo/Layout/Multi Page Layout"

From Apache OpenOffice Wiki
< Writer‎ | ToDo‎ | Layout
Jump to: navigation, search
(Million of other questions: UI extended)
Line 94: Line 94:
=== UI ===
=== UI ===
* '''Menu Entry:''' how many entries?
* '''Menu Entry:'''
** Print Layout: a single page
** How many entries?
** Facing Pages
**# '''Print Layout:''' old style single page
** Multiple Pages:
**# '''Facing Pages'''
*** separate option in the View Menu
**# '''Multiple Pages'''
*** or should it be combined with the 'Print Layout'
**# '''ALL Pages Horizontally'''
*** then offer a 'Tools' -> 'Options' to enable/disable this behaviour
** Menu structure
*** display separate options in the View Menu
*** I would go against a separate submenu
*** should the '''Multiple Pages''' be combined with the old '''Print Layout'''?
**** in the latter case, offer a 'Tools' -> 'Options' -> 'Layout' to enable/disable this behaviour
* '''Context Menus'''
** right click on Zoom-Slider
** right click on gray area around the document
* '''Accessibility'''
* '''Navigating through the document pages'''
* '''Navigating through the document pages'''
** scroll using the mouse wheel
** scroll using the Mouse wheel
** ZOOM using CTRL + Mouse whell
=== Saving Document Settings ===
=== Saving Document Settings ===

Revision as of 14:41, 31 October 2007


This page shows the planning and progress of the Multi Page Layout feature,see i1598.

Background/Short Description

With the increasing availability of wider monitors as well as of computer configurations using dual monitors, there is increasingly unused space on the screen. As the most common screen resolutions are significantly wider than tall, there is enough horizontal space to display simultaneously 2 or more pages side by side.

There are 2 common, but slightly different use scenarios in current practice:

  • Casual users: users expect to use the extra space on wide screens to view additional pages side by side. The number of pages should be computed dynamically as many as fit.
  • Professional designers need often to adjust elements on facing pages and fine tune these various elements depending on a different element on the corresponding opposite page.

Competitive Product Analysis

There are 2 major groups of Office packages:

  • entry level suites
  • professional publishing tools

OOo and its various flavours, as well as MS Office and other office suites belong to the former category. Adobe Pagemaker and other publishing software belong to the professional tools. Other programs like Adobe Acrobat (both Reader & Professional version) have adopted the trait of the advanced publishing software.

  • MS Word XP: implemented inside the 'Print Layout'
    • upon zooming out, as many pages are displayed within the same row as will fit on the row
    • does NOT pair facing pages
    • only active page displays a horizontal ruler
  • NeoOffice: implemented, see example image
    • upon zooming out, as many pages are displayed within the same row as will fit on the row
    • does NOT pair facing pages
    • all pages have distinct horizontal rulers
  • Adobe Acrobat 7.0: implemented as 'Page Layout' -> 'Facing' and 'Continous Facing'
    • the 2 facing pages will be displayed adjacent
    • first page is displayed single: TRUE facing
    • there is a space between the adjacent pages
    • ZOOM: 'fit width' will adapt the zoom level so that the 2 adjacent pages will span the whole width of the window
  • Adobe Pagemaker: (available since the early '90s)
    • option for setting 'Facing pages' when creating a new document
    • see this tutorial from Rice University

Entry level tools adopt a simple approach: display as many pages a fit on the screen.


Facing Pages

  • useful in professional settings

Display as Many Pages as Fit

  • highly requested

Stack ALL Pages Horizontally on a Single Row

  • useful for banners

Specification: Conceptual Problems

These still need to be solved and agreed on before starting the implementation.

LTR vs RTL Text

  • Arabic, Hebrew and other RTL languages

Hebrew and Arabic pages should be tiled RTL/TTB.

For documents with some pages in an RTL language and some in an LTR language, direction would be determined by the text-direction setting in the document's default style

  • Japanese:
    • traditional Japanese is written Top-to-Bottom with RTL for the secondary axis
    • both LTR/Top-to-Bottom and Top-To-Bottom/RTL within the same document is possible
    • traditional Japanese pages should be tiled therefore RTL (as other RTL-documents)
    • mixed documents should be tiled in accordance with the text-direction setting in the document's default style

Multiple Page Sizes

  • is there any use case for multiple page sizes within the same document?

Documents that have data tables often require the ability to show pages in alternating portrait and landscape views. That is, landscape pages are interspersed with pages having a portrait layout (normal pages). This should be definitely supported, as many scientific journals contain such formatting.

The question is however more specific about truly different page sizes: like A4 and A3 within the same document (for an example see the attachment for issue 82859). However, as this does not seem to cause any special implementation problems, we may just ignore it. The formatting engine should work correctly for this situation, too.

Horizontal Ruler

  • one global horizontal ruler vs multiple rulers


  • where do we position notes:
    • 'always right' vs 'left & right' depending on even/odd page
  • always right
    • disadvantage: notes for left pages will overlap right pages
    • need to plan for additional space between pages
  • right & left side:
    • there will be some empty space both on the right and the left of the screen
    • need possibly more extensive changes to 'Notes'-code
    • for variable-pages-per-row: IF one changes the zoom-level, the number of pages that are displayed will change resulting also in a change in the position of the notes (can be distracting)

Million of other questions


  • Menu Entry:
    • How many entries?
      1. Print Layout: old style single page
      2. Facing Pages
      3. Multiple Pages
      4. ALL Pages Horizontally
    • Menu structure
      • display separate options in the View Menu
      • I would go against a separate submenu
      • should the Multiple Pages be combined with the old Print Layout?
        • in the latter case, offer a 'Tools' -> 'Options' -> 'Layout' to enable/disable this behaviour
  • Context Menus
    • right click on Zoom-Slider
    • right click on gray area around the document
  • Accessibility
  • Navigating through the document pages
    • scroll using the Mouse wheel
    • ZOOM using CTRL + Mouse whell

Saving Document Settings

Should the Layout Settings be stored with the document? The Facing Pages-option is really an intrinsic property of the document. This is indeed true of Adobe Pagemaker: the user creates either 'Facing Pages'-documents or plain documents.


  • The previous state of the document/layout would be preserved when saving and reopening the document.
  • Could be used to solve some printing issues for 'Facing Pages'-documents. (issue ...)


Does this need a change to the ODF-format? No, it doesn't. We can put this into settings.xml without file format changes.

NOTE: Currently, the zoom factor and the zoom mode are stored:

  • In the Writer configuration (Writer.xcs: Zoom/Type)
  • In the document (settings.xml: ZoomType)

0 = percent 1 = optimal 2 = entire page 3 = page width

If we implement different page layout modes ('facing pages', 'dynamic', 'one page per row'), this page layout mode also has to be stored in the Writer configuration as well as in the settings.xml.

ZOOM: Splitting Issue

Should we split the ZOOM-Issue from this issue and address it within a different issue? The ZOOM needs some major reshaping:

    • ZOOM-options are scattered all across OOo,
    • BUT look pretty unprofessional and non-functional
    • better dialog
    • ZOOM-slider (see NeoOffice)
    • some other advanced/unified concepts

ZOOM: Page Width

IF a user selects a viewing mode where the number of pages that fit horizontally is dynamically computed:

How should the ZOOM -> Page Width behave?
  1. Deactivate this ZOOM-Option
  2. Compute the width only for the active page-row:
  • Adobe Acrobat behaves similarly (although it displays constantly 2 pages)
  • DISADVANTAGE: when a different page-row gets the focus, the ZOOM-Level may change. I perceive this as distracting and annoying.
  • alternatively, compute the ZOOM-level only once and keep this ZOOM-level, even if the cursor is positioned on a different row of pages. Change the ZOOM-Level only if the user selects explicitly to again change/sets the ZOOM.
Computing a global zoom seems very complex. (Actually, I believe that quite often there is NO mathematical solution to compute such a zoom level - at least this is NOT a linear system.)

Multiple Monitors

It is unwise to split a page across multiple monitors. Therefore, how should this be handled?

  1. Can we reliable detect a Multiple Monitors-setting?
  2. ...

Implementation: Progress/ToDo

  • Evaluate OD's hack and start a first prototype (est. 1 week) DONE
  • Find and resolve problems: (est. 3 weeks)
    • Root frame changes (paste page, cut page, change page format) (est. 1d) DONE
    • Resolve repaint issues of page frame (est. 1d) DONE
    • Cursor Traveling (est. 2d) DONE
    • EmptyPages (est. 1d) DONE
    • Printing (est. 1d) DONE
    • PDF export (est. 1d) DONE
    • Browse View (est. 2d) DONE
    • examine DOCUMENTBORDER stuff in sw/source/ui (est. 3d) DONE
    • Why is DOCUMENTBORDER in SwTabColItem? (est. 1d) DONE
    • Check GetDocSz(), GetAnyCurRect() (est. 3d) DONE
    • ------------------------------------------------------------
    • Object positioning (est. 3d)
    • Ruler? (est. 1d)
    • Accessibility?
    • Screen position depending fields (est. 1d)
    • Consider Max' new notes feature
    • Writer OLE objects (browse view and normal view)
    • Who else deals with absolute coordinates?
    • 1.000.000 more yet unknown problems (est. 1.000.000d)
  • Define new algorithm to layout pages (SPEC)
  • Implement algorithm (est. 3d)


The team working on this feature is:

Name OOo Nickname Role
Leonard Mada discoleo User Experience, Spec owner
Stefan Baltzer sba QA
Uwe Fischer ufi Documentation
Frank Meies fme Development
Personal tools