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

From Apache OpenOffice Wiki
< Writer‎ | ToDo‎ | Layout
Jump to: navigation, search
(Specification: Expanded)
(Specification: Default Layout)
Line 54: Line 54:
 
= Specification =
 
= Specification =
  
== Stack ALL pages Vertically ==
+
== Layout Modes ==
[One Page per Row]
+
* '''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.
 
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
 
* useful for vertical banners
* is the old default
+
* is the old default - needed for compatibility
  
== Facing Pages ==
+
=== 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.
 
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
 
* useful in professional settings: book-editing
  
== Display as Many Pages as Fit ==
+
=== Display as Many Pages as Fit ===
 +
''Automatic Layout''
  
 
Writer shall compute dynamically how many pages fit along the screen width.
 
Writer shall compute dynamically how many pages fit along the screen width.
 
* highly requested
 
* highly requested
  
== Stack ALL Pages Horizontally on a Single Row ==
+
=== Stack ALL Pages Horizontally on a Single Row ===
  
 
All pages will be displayed stacked horizontally on a single row.
 
All pages will be displayed stacked horizontally on a single row.
 
* useful for horizontal banners
 
* 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
 
* 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.
 +
 +
== UI ==
 +
 +
== File Format ==
  
 
= Specification: Conceptual Problems =
 
= Specification: Conceptual Problems =

Revision as of 12:05, 21 November 2007

Introduction

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:

Specification

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.

UI

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

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

UI

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

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

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)
    • ------------------------------------------------------------
    • Paint empty pages (est. 1d)
    • Multiple Views (est. 1d)
    • Repaint issues (est. 1d)
    • Ruler? (est. 1d)
    • RTL page layout (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)

A prototype of the feature can be found here:

http://ooo.services.openoffice.org/pub/OpenOffice.org/cws/upload/fme/

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

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