Writer/ToDo/Layout/Multi Page Layout

From Apache OpenOffice Wiki
< Writer‎ | ToDo‎ | Layout
Jump to: navigation, search

Writer Icon.png

Writer Project

Please view the guidelines
before contributing.

Popular Subcategories:

Extension:DynamicPageList (DPL), version 2.3.0 : Warning: No results.

Internal Documentation:

Extension:DynamicPageList (DPL), version 2.3.0 : Warning: No results.

API Documentation:

Ongoing Efforts:

Extension:DynamicPageList (DPL), version 2.3.0 : Warning: No results.



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 both inside the 'View'->'Print Layout' and the 'View'->'ZOOM'-Dialog
    • 'View'->'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
      • the horizontal ruler is displayed only for the active page (that has currently the focus)
    • 'View'->'ZOOM'-Dialog
      • one can explicitly choose how many 'columns * rows' to display
      • Word has also a preview displaying the font at this scaling
  • 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 at least since the early '90s)
    • option for setting 'Facing pages' when creating a new document
      • creating a new document implies specifying explicitly the type of document (book-style or not)
    • see this tutorial from Rice University

Entry level tools adopt a simple approach: display as many pages as fit on the screen. In case of MS Word, one can also specify a fix matrix of (X pages/column * Y pages/row).

Different approaches

Andreas Schuderer implemented some great examples showing some different approaches to this feature:


Layout Modes

  • One Page View - the current 'Printer Layout
  • Automatic Layout - display as many pages as fit horizontally on the screen
  • Book Layout - display facing pages adjacently
  • Horizontal View - display all pages in a single row
  • n-Columns View - display exactly n pages per row

Stack ALL pages Vertically

One Page per Row

This is represented by the already existing Printer View inside the current OOo version. All pages are displayed vertically beneath each other, in one column.

  • useful for vertical banners
  • is the old default - needed for compatibility

Facing Pages

Book Layout

The 2 facing pages shall be displayed adjacent, optimally without any intervening space. This is the so called Book Mode. This mode also implies that the left page is always an even page and the right page is an odd page, therefore necessitating the insertion of empty pages where appropriate.

  • useful in professional settings: book-editing

Display as Many Pages as Fit

Automatic Layout

Writer shall compute dynamically how many pages fit along the screen width.

  • highly requested

Stack ALL Pages Horizontally on a Single Row

All pages will be displayed stacked horizontally on a single row.

  • useful for horizontal banners
  • if the whole page fits on the screen, then the user can navigate easily through the pages, as one needs to scroll only horizontally

n-Pages per Row

Default Layout

This issue is still debated. Because the Automatic Layout offers additional functionality to the current default 'One Page View', without any sensible negative effect, I strongly support making the Automatic Layout the new default.


The 'Page Layout' and the 'Zoom', although different entities, are still intricately related. Although I am a strong proponent for independent 'Page Layout' and 'Zoom'-Controls, they will have to be dealt together. Choosing sensible defaults and taking account of these intricacies is therefore relevant to designing the GUI.

INTRO: GUI Elements

  • Menu-Entries
  • Zoom/Layout-Dialog
  • Status-Bar Control
  • Context-Menu


It should be possible to change both the Page Layout and the Zoom through the Menu. Frequent options should be available as direct Menu commands, while less frequent options should be settable inside a special dialog.

VIEW -> Layouts
  1. Print Layout (unchanged -> this is the old default)
  2. Dynamic Layout: as many pages as fit (new DEFAULT)
  3. Book Layout: 2 pages without intervening space
  4. Web Layout (unchanged)
  • These entries should be first order entries within the View-Menu!
    • NOT a submenu!
    • additional options will be available through the Zoom-dialog
will open the ZOOM Dialog


There should be a combined ZOOM/Layout-Dialog. Although I believe that the Zoom-options and the Page Display-options are separate entities, they work hand in hand, so a single dialog covering both aspects is warranted.

Unfortunately, because of lack of resources, this dialog will be first implemented as a *MODAL Dialog*. This means, dynamic changes to its content, as well as live previewing the changes, is NOT possible. I would have preferred a non-modal dialog, but this will have to wait for a later time (OOo 3.x time-frame).

Status Bar Control

This control should allow easily switching the Page Layout and the Zoom Level from the status bar. The most common use scenarious should be covered.

  • Page Layout-Control
  • ZOOM-Control

Page Layout Switch

This should allow switching the Page Layout. To prevent a complex and non-functional design, only some common scenarios shall be covered. Complex settings can be set within the Zoom/Layout-dialog.


ZOOM Control

This should be implemented using a slider. The slider allows for easier changing the zoom-level and selecting the optimal value. Please note that this is done dynamically and the user can preview the changes (unlike the modal dialog discussed previously).

Because absolute values of 25%, 50%, 150%, ... are rarely used by the user and do not correlate well with desired outcomes, I strongly favour dropping these absolute values from the slider.

  • the middle position shall set a zoom factor of 100%
  • the slider should behave exponentially (non-linearly), to allow fine adjustments for zoom-levels around 100%
    • most of the slider (80% of it) should cover the zoom-levels 30% to 150%
    • the rest of the slider should cover extreme zoom-levels

Instead, the slider should have some properly chosen snapping points:

  • 100% should remain as the default (middle of slider)
  • page width:
    • this is a snapping point for a zoom-level, so that exactly one page fits horizontally;
    • it does NOT set the page-layout, NOR does it set the dynamic zoom 'page-wdith'
  • 2 pages:
    • this is a snapping point for a zoom-level, so that exactly two pages fit horizontally;
    • it does NOT set the page-layout, NOR does it set a dynamic zoom, therefore, the zoom level will not change when the window is resized
  • when the snapping points fall adjacent, therefore obscuring the vision, they should be drawn slightly skewed (at least 1 mm apart), except when they are almost identical, when only one should be drawn

Dynamic vs NON-Dynamic ZOOM
  • the dynamic zoom: readjusts the zoom-level when the program window is resized
  • non-dynamic zoom: the zoom level will not change when the window is resized

Context Menu

File Format

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
  • 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) DONE
  • Paint empty pages (est. 1d) DONE
  • Multiple Views (est. 1d) DONE
  • Repaint issues (est. 1d) DONE
  • RTL page layout (est. 1d) DONE
  • Store view settings to file (est. 1d) DONE
  • Store view settings to configuration (est. 1d) DONE
  • Check Writer Web (est. 1d) DONE
  • Screen position depending fields (est. 1d) DONE
  • Table Row/Column selection (est. 2d) DONE
  • Check Ruler (est. 1d) DONE
  • Implement ViewLayout slot and item (est. 1d) DONE
  • Implement ViewLayout control (est. 1d) DONE
  • Implement ZoomSlider slot and item (est. 1d) DONE
  • Implement ZoomSlider control (est. 2d) DONE
  • Implement new Zoom Dialog (est. 1d) DONE
  • Check Writer OLE objects (browse view and normal view) DONE
  • Check Accessibility (est. 1d) DONE
  • ------------------------------------------------------------
  • Merge with Max' new Notes feature

A prototype of the feature can be found here:


Please note that this is a *prototype* and most likely is buggy beyond belief.


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