Writer/ToDo/Layout/Multi Page Layout

From Apache OpenOffice Wiki
< Writer‎ | ToDo‎ | Layout
Revision as of 12:27, 23 October 2007 by Fme (Talk | contribs)

Jump to: navigation, search

Introduction

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

Background/Short Description

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

  • With the availability of wider screens, users expect to use the extra space to view additional pages.
  • Professional designers need often to adjust elements on facing pages and fine tune these various elements depending on a different element on the opposite page.

Competitive Product Analysis

  • 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

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

Notes

  • 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

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.

ADVANTAGE:

  • 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 ...)

DISADVANTAGE:

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:

  • PROBLEMS:
    • ZOOM-options are scattered all across OOo,
    • BUT look pretty unprofessional and non-functional
  • SOLUTIONS:
    • 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.)

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)
    • Why is DOCUMENTBORDER in SwTabColItem? (est. 1d)
    • Check GetDocSz(), GetAnyCurRect() (est. 3d)
    • 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)
    • 1.000.000 more yet unknown problems (est. 1.000.000d)
  • Define new algorithm to layout pages (SPEC)
  • Implement algorithm (est. 3d)

Contact

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