Issue 1598 - Display multiple pages beside each other while editing
Summary: Display multiple pages beside each other while editing
Alias: None
Product: Writer
Classification: Application
Component: viewing (show other issues)
Version: 633
Hardware: All All
: P3 Trivial with 154 votes (vote)
Target Milestone: ---
Assignee: stefan.baltzer
QA Contact: issues@sw
Keywords: oooqa, rfe_eval_ok, usability
: 4307 21729 24772 30443 32898 33070 34364 39586 75713 78683 (view as issue list)
Depends on:
Reported: 2001-08-31 22:49 UTC by burnus
Modified: 2013-08-07 14:43 UTC (History)
21 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---

Mockup of current and preferred edit view (facing pages). (253.07 KB, image/jpeg)
2005-06-10 20:34 UTC, danboarder
no flags Details
2 Page view in MS Word Mac X (37.00 KB, image/png)
2007-04-01 03:33 UTC, benjchristensen
no flags Details
3 Page view in MS Word Mac X (39.04 KB, image/png)
2007-04-01 03:34 UTC, benjchristensen
no flags Details
Draft Specification - v001 (13.62 KB, application/vnd.oasis.opendocument.text)
2007-07-20 18:22 UTC, discoleo
no flags Details
DRAFT v002 - Extended slightly the draft (15.97 KB, application/vnd.sun.xml.writer)
2007-07-23 18:18 UTC, discoleo
no flags Details
Experimental Context Menu Design - a radically different approach to the (future) 'Select Multiple Page View'-context menus. (16.83 KB, image/jpeg)
2007-11-02 18:47 UTC, discoleo
no flags Details
OO Screenshot - 2 page view (528.21 KB, image/png)
2007-11-18 10:21 UTC, janderk
no flags Details
OOo Screenshot - 3 page view (492.24 KB, image/png)
2007-11-18 10:24 UTC, janderk
no flags Details
Mockup for the combined ZOOM-/Page-Layout DIALOG (9.85 KB, application/vnd.sun.xml.draw)
2007-11-18 22:05 UTC, discoleo
no flags Details
Initial Specification Draft (TRUE Spec) - Pre-Alpha (229.32 KB, application/vnd.sun.xml.writer)
2007-11-25 20:10 UTC, discoleo
no flags Details
Case showing effect of pages with different Layout (36.33 KB, image/jpeg)
2007-11-26 08:58 UTC, discoleo
no flags Details
OOo_2.4.0_071213_Win32Intel_install_ruler.png (65.49 KB, image/png)
2007-12-16 11:14 UTC, norbert2
no flags Details
Specification (NOT FINAL!) Version of Jan 14th 2008 (198.77 KB, application/vnd.oasis.opendocument.text)
2008-02-07 18:12 UTC, stefan.baltzer
no flags Details
Slightly improved Spec-Draft (201.06 KB, application/vnd.oasis.opendocument.text)
2008-02-17 02:28 UTC, discoleo
no flags Details
Test cases (12.36 KB, text/html)
2008-03-06 18:55 UTC, stefan.baltzer
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description burnus 2001-08-31 22:49:10 UTC
In order to have an better view of facing pages, OpenOffice should support a
facing page mode (I can think of either two pages shown side by side with some
space between, or even with out space, so that they have an edge in common.)
Note that the view should start with one page only, so you get
        |     |
        |     |
        |     |
+-----+ +-----+
|     | |     |
|     | |     |
|     | |     |
+-----+ +-----+

per default. Reasoning: The odd numbered pages are always on the rigtht.
This should be a [x] Check box, since it is independed of the zoom factor, I

Additionally, you may offer an multipage view, you open a menu similar to the
table icon in which you can select how many rows and columns of pages you want
to see. In this case the pages are order after each-another. The col/row numbers
are used to calculate the zoom factor. If there is still space below the given
number of rows, show them also.

A nice study would be how Word does it, I remember that I saw something like
that in the old days of Word 6 ;-)
Comment 1 stefan.baltzer 2001-09-03 14:30:47 UTC
REassigned to Falko.
Comment 2 falko.tesch 2001-09-17 09:49:48 UTC
Yes, this should be possible.
Comment 3 falko.tesch 2003-10-06 11:38:29 UTC
In order to have an better view of facing pages, OpenOffice should
support a facing page mode (I can think of either two pages shown side
by side with some space between, or even with out space, so that they
have an edge in common.)
Note that the view should start with one page only, so you get
        |     |
        |     |
        |     |
+-----+ +-----+
|     | |     |
|     | |     |
|     | |     |
+-----+ +-----+

per default. Reasoning: The odd numbered pages are always on the rigtht.
Comment 4 goon2 2004-04-06 20:12:02 UTC
Is someone working on this bug? This is only a small reminder: with new laptops
with wide screens (16/9 or so), it would be very useful to work on two pages
that are displayed face-to-face. Keep up the good work anyway!
Comment 5 lohmaier 2004-08-12 21:23:51 UTC
*** Issue 21729 has been marked as a duplicate of this issue. ***
Comment 6 lohmaier 2004-08-12 21:24:41 UTC
*** Issue 32898 has been marked as a duplicate of this issue. ***
Comment 7 lohmaier 2004-08-17 22:09:19 UTC
*** Issue 33070 has been marked as a duplicate of this issue. ***
Comment 8 lohmaier 2004-09-23 19:48:52 UTC
*** Issue 34364 has been marked as a duplicate of this issue. ***
Comment 9 lohmaier 2004-10-23 16:46:53 UTC
defaulting prio, setting keywords,reassigning according to new RFE-process
Comment 10 lohmaier 2004-10-23 16:47:31 UTC
*** Issue 24772 has been marked as a duplicate of this issue. ***
Comment 11 lohmaier 2004-10-23 16:48:36 UTC
*** Issue 30443 has been marked as a duplicate of this issue. ***
Comment 12 lohmaier 2004-10-23 16:49:52 UTC
*** Issue 4307 has been marked as a duplicate of this issue. ***
Comment 13 lohmaier 2004-12-27 17:21:57 UTC
*** Issue 39586 has been marked as a duplicate of this issue. ***
Comment 14 gawron 2004-12-27 17:47:50 UTC
Does OOo later mean that this is not planned at all for 2.0? No offence, but
with modern screens and 1024x768 being standard nowadays, this will be pretty
lame (and it seems that center on zoom bug is also OOo Later...)...
Comment 15 treblig 2004-12-29 00:23:38 UTC
An addition that may be easier to add in the short term (and as useful to many?)
would be an option that allowed horizontal rather than vertical scrolling - i.e.
all sheets are placed next to each other and the scroll area is only ever one
page high.
Comment 16 techgurufloyd 2005-03-17 01:04:57 UTC
You say that there should be a blank before the first page to keep odd numbered
pages on the right:
        |     |
        | Pg1 |
        |     |
+-----+ +-----+
|     | |     |
| Pg2 | | Pg3 |
|     | |     |
+-----+ +-----+

I partially agree. This should happen, except for when there is an additional
'title' page. I'd want there to be an option to disable the 'blank' for a
specific document:
+-----+ +-----+
|     | |     |
|Title| | Pg1 |
|     | |     |
+-----+ +-----+
+-----+ +-----+
|     | |     |
| Pg2 | | Pg3 |
|     | |     |
+-----+ +-----+
Or, else there needs to be some help tip or something that suggests that the
user add an additional blank page (that can be disabled from printing. I hope
there's a way to do that.) between the title page and page 1 for a more
intuitive layout.
Comment 17 stefan.baltzer 2005-06-01 13:40:20 UTC
SBA:New summary: (Borrowed from closed duplicate issue 39586): Display multiple
pages beside each other while editing. (Old summary: "Zoom should also allow
facing page view and/or multiview") 

The main thing (call it BASIC FEATURE) is to have two pages beside each other
while being able to edit them.

Some notes (so far, this description in total is a little "too collective",
mixing page (print) preview, edit view and the "odd spages left/right" stuff and
how t access this together,  although all this is separate areas)

(1) Where and how to access this is a minor thing to clarify while this is being
(2) The (non-editable) page preview in OOo 2.0 already has a table-like
selection in order to "scroll" whether 2x2, 5x8, ... pages should be shown at once.
(3) The "odd page left or right" stuff is relevant for the page preview (to see
what pages will be printed out toghther)
(4) When EDITING a document, it is convenient to have a free choice what pages
to see (1+2, 2+3, 3+4 or 4+5...), so "scrolling horizontally" must be taken into
account too.
Comment 18 stefan.baltzer 2005-06-01 13:44:55 UTC
SBA: One more note: TWO pages to edit require TWO horizontal rulers. According
to OC, this would be a convenient opportunity to add "further vertical ruler
instances", too. Currently, the vertical ruler is shown only for the page where
the cursor is located, thus "vanishing" when the scroll bar is used to scroll
through a document.
Put CJ on c/c.
Comment 19 stefan.baltzer 2005-06-01 13:49:51 UTC
Comment 20 danboarder 2005-06-10 20:34:21 UTC
Created attachment 27085 [details]
Mockup of current and preferred edit view (facing pages).
Comment 21 mfab 2006-01-18 22:05:59 UTC
Also see this RFE in Abiword for progress / comparison:
Comment 22 bobharvey 2006-07-18 09:20:54 UTC
Has there been any update?  is anything happening?
Comment 23 matthias.mueller-prove 2006-11-13 13:04:16 UTC
add my votes
Comment 24 faustop 2007-02-04 22:31:57 UTC
I think the user should be able to view the two first pages, not limited to
starting with one page only.

And I think the administrators and developers forgotten this bug, it is open
since 2001 and never received to much attention (a shame for a bug as important
as this).
Comment 25 weaselitb 2007-02-24 05:10:37 UTC
The description by techgurufloyd is spot-on. I use a 1920x1200 resolution on my
desktop computer, and 1920x1080 on the media computer in my living room, and it
is frustrating to say the least to see all that blank grey space on the right
hand side of my document.

I sincerely hope that this bug is not forgotten, as faustop implies, as that
would be a very big shame, especially considering that widescreen monitors are
more popular now than they have ever been (most prominently on laptops).
Comment 26 madbop 2007-02-24 10:51:02 UTC
Still wondering if there is any facility around that takes on orders for
developing such extensions? - This issue is "NEW" since 6 years by now...

Actually this feature should also be available in the "web layout" in respect to
the "print layout" (rather should be flexible or fixed border layout" BTW).
Specifying multiple columns for display or a combination view with different
magnifications is usable independently of the actual formatting style.
Right now the OO-writer interface looks like stuck in the last millennium.

What is actually the difference between Mozilla Firefox and OO in terms of
architecture? Why are loads of small, medium and big enhancements
(add-ons/extensions) available? - Is the software architecture of Mozilla
Firefox so much more programmer friendly?
Comment 27 junismith 2007-02-28 02:03:50 UTC
This would be a very useful feature for those of us working on large widescreen
monitors.  Thanks.
Comment 28 cjeculver 2007-03-13 17:01:45 UTC
In fact, what about a multi-page view, a la MS Office? From the MSO zoom menu,
simply click-and-drag the View button to define the number of pages you wish to
see. Exceptionally useful to get a quick overview of your document.
Comment 29 Mathias_Bauer 2007-03-25 18:05:23 UTC
*** Issue 75713 has been marked as a duplicate of this issue. ***
Comment 30 saidlp 2007-03-27 16:39:47 UTC
This is the ONE point why I still keep Windows in dual boot : MS Word does it,
and I need it... 
I'm working on 12" wide screen, the ideal would be a kind of "two pages, text
width" option, to avoid wasting precious centimeters of white margins on each side,
but a plain 2-pages display would already allow me to say goodbye to Microsoft.
Comment 31 alexnihilo 2007-03-28 15:26:55 UTC
Sure, it's really useful and it doesn't seem so difficult to fix as it is almost
set for print preview and presentation edition... 
Comment 32 faustop 2007-03-29 12:38:15 UTC
This bug is really old and is even more important nowadays due to widescreen
monitors. I wonder what we could do (apart from voting) to make developers aware
of it?
Comment 33 alexnihilo 2007-03-29 14:30:05 UTC
Faustop is right: it has been noticed for several years ! But in Abiword they 
seem no to have solved the bug either... 
I don't know what we can do. The issue has not a lot of votes neither and I 
don't know if number of messages can attract their interest...
Comment 34 benjchristensen 2007-04-01 03:33:46 UTC
Created attachment 44118 [details]
2 Page view in MS Word Mac X
Comment 35 benjchristensen 2007-04-01 03:34:50 UTC
Created attachment 44119 [details]
3 Page view in MS Word Mac X
Comment 36 benjchristensen 2007-04-01 03:41:03 UTC
Earlier explanations of this have made this much more complex than it needs to be.

This does not need to try and be a book layout feature, but simply "show pages
horizontally if the window has enough pixels".

With high-resolution screens and widescreen laptops/displays commonplace, it is
expected to be able to place pages side by side ... and not just 2, but 3 or more.

Please see the two attachments with filenames:


These show the simple implementation from Microsoft dating back several years
that works very simply and very well.

The basic logic is:

   IF page1.width+page2.width < window.width THEN show 2 pages

Of course ... this expands out to a slightly more flexible feature by
calculating how many pages it should show through something akin to:

   window.width / page.width == number of pages to show

The page.width adjusts depending on my zoom setting, and automatically shows
that number of pages.

It doesn't try to do anything with odd/even, title pages, etc ... just shows me
X number of pages horizontally according to my window size and zoom setting.

What is needed to encourage this being implemented?

Comment 37 alexnihilo 2007-05-21 21:22:42 UTC
the most surprising is that the system is already working for print preview -  
Well, almost: you have to choose the number of displayed pages in the toolbar 
and, of course, you cannot edit pages since its print preview. But the idea is 
here... Almost the same in Ooo Presentation: you can see different slides side 
to side...  I really don't understand why it's so difficult to fix this bug.
Comment 38 dannep 2007-05-31 00:17:28 UTC
A quick and dirty feature that might be simpler to provide at this time....after
6 years is:
When a "new window" is started on the help menu there is an option somewhere
to link the scrolling of these 2 windows.
If these 2 windows are put side by side you do get a similar functionality
as multipage view, provided that the scrolling is linked.

Comment 39 norbert2 2007-05-31 20:27:53 UTC

This is no solution because it is impossible to edit the same document (file) in
two Writer instances at the same time!
Comment 40 alexnihilo 2007-05-31 20:44:26 UTC
I'm not sure to understand what you mean. We do can edit the same text in two 
windows after opening a 'new window' as dannep said. There's juste ONE 
instance of writer, but two views of the same doc. Whatever, this would be 
really a poor ersatz. 

By the way, OpenOffice is an open software, no ? So why couldn't create a kind 
of patch to fix this stupid bug if nobody else cares about ? That's really a 
kind of pain in the (_*_)
Comment 41 norbert2 2007-06-01 17:59:43 UTC

Sorry, this was my mistake. You and dannep are right. I did not know about this
feature to open one document in two windows.
Comment 42 benjchristensen 2007-06-18 19:28:42 UTC
This is not for having two "views" of the same document.

It should be one instance of the writer ... just allow side-by-side pages.

Look at the screenshots of Word on Mac OSX I attached to have a visual
representation of how it already works great there.


As for it being Opensource and creating a patch for it ... I wish I could, but
I'm an Enterprise Java developer (webapps, web services, etc) and have no clue
how to code this type of solution. Otherwise I'd love to help.

Comment 43 matthias.mueller-prove 2007-06-19 12:47:42 UTC
Oliver, Mathias,
who likes to take this task and form an iTeam for "the near future"?
I know we already took up speed to improve the display of pages in Writer
(center pages on zooming out - looks great BTW).
Comment 44 Mathias_Bauer 2007-06-21 08:04:36 UTC
*** Issue 78683 has been marked as a duplicate of this issue. ***
Comment 45 discoleo 2007-07-20 18:20:16 UTC
I began writing a draft specification, what this feature should accomplish. It
is still very much pre-alpha. See attached odt-document.

Please feel free to correct and comment on the proposed features.
Comment 46 discoleo 2007-07-20 18:22:40 UTC
Created attachment 46947 [details]
Draft Specification - v001
Comment 47 Mathias_Bauer 2007-07-20 19:04:57 UTC
Thanks for your document! I will have look on it in a few weeks. Tomorrow I will
go on vacation. :-)
Comment 48 treblig 2007-07-21 20:14:17 UTC
  That document looks like a nice start; I'm not sure that '2' page view needs
to be a special case; 'n' is certainly the one I'm interested in but I don't
think it is that hard to generalize the '2' page view; I suggest that you just
keep adding boundaries after the 2nd page in the same way you worked out the
spacing from the left edge to the first margin.
  As for dealing with landscape pages and the like I'd go for a simple solution
where you work out the sizing based on one page (e.g. the one currently on the
display at the time the user selects the multipage view?) and then where there
is a larger page let that spill over to the side (and in an n page view push the
next page out of the way?).
  It seems to me that the hardest thing is the way the 'x-pages' view interacts
with explicit zoom requests.

  As mentioned previously in the thread I'd also be interested in something that
I've not seen in any other similar programme but feels like it fits in at the
same point;   I think it should be possible to set a mode where the number of
page vertically is 1 and *all* pages are side by side horizontally.  I think
that might work really well on high res widescreen monitors or (as I have at
work) a pair of monitors next to each other.
Comment 49 discoleo 2007-07-22 11:54:48 UTC
Added this issue to the page (Writer TODO page).
Comment 50 discoleo 2007-07-23 18:18:49 UTC
Created attachment 47004 [details]
DRAFT v002 - Extended slightly the draft
Comment 51 Oliver Specht 2007-08-02 13:54:37 UTC
os removed from cc
Comment 52 seidelin 2007-08-19 22:48:35 UTC
It is nice to see that this feature is being worked on; it's really a useful
feature. Thanks and keep up the good work. Looking forward to see this in OO
Writer in the future. :)
Comment 53 Mathias_Bauer 2007-08-20 17:43:14 UTC
I had a look into the spec and I found a lot of details about the way the pages
should be distributed - for me that's the part that comes at the end of the
whole feature. We have to do quite some work before we can discuss about that,
the two biggest parts are:

(1) The object positioning of Writer must be changed; currently Writer has a
continuous layout for the whole document and the visible part (per window) is
defined by a rectangular part that is “cut out” from this whole continuous
document area. The upper left corner of that cut out area is aligned to the
upper left screen coordinate of the view area. What we need now is that each
object must remember its position not in absolute “document” coordinates only
but also addionally in coordinates relative to the upper left corner of the page
it is currently located on. When a particular page is displayed the view code
must be changed to reflect that. This is a huge effort that roughly(!) estimated
will take 3 months of code rework and testing. 

(2) The ruler and scrollbar code must be changed considerably.

The exact algorithm of how pages shall be arranged is the smallest part of all;
I think not more than 10-20% of the development and testing time, roughly 1-2 weeks.

In general I don't want to go for an “editable print preview” but for a “multi
page edit view”. This means: no “matrix” like display of pages, just one “row”
of pages should be enough to make better use of wide screens. Having two
editable pages above each other will result in very small pages (as long as
screens are “landscape” oriented) and editing them will be quite hard. So I
don't see a reason to invest additional time for this, at least in the first

And I don't see a reason to take care for "odd" and "even" pages in an edit
view, this is something I still want to keep for the Print Preview (and I want
to keep this one non-editable).

(As a western european inhabitant I described my ideas in a “left to right” and
“top to bottom” logic, I hope you can translate that into other writing directions.)

Comment 54 alexnihilo 2007-08-20 19:13:47 UTC

I'm not sure to understand what you mean there:
<<no “matrix” like display of pages, just one “row”
of pages should be enough to make better use of wide screens.>>

Do you still aim to fix the original issue: "Display multiple pages beside 
each other while editing" or do you prefer to give up the idea ?

thank you
Comment 55 discoleo 2007-08-20 19:19:36 UTC
A.) Even-vs-Odd pages?

> And I don't see a reason to take care for "odd" and "even" pages in
> an edit view

Does this refer to first row should have 1 or 2 pages?

Well, it makes sense to have then even/odd pages. Consider, the user works on a
book/booklet where opposing pages make functional units (e.g. a table spanning
horizontally on the 2 adjacent pages; or a calendar; ...). and the 1st page is
some other stuff, not part of such a unit (because it being the first page is
really alone, see any book for this).

Then, the user wants to see:
2  3 => make really sense together
4  5 => make really sense together

IF, on the other hand, the program will implement:
1  2
3  4
5  6
Then every view will be broken as the wrong pages will be displayed adjacent.

On the other hand, IF the program increments sequentially:
1  2 => 2  3 => 3  4 => ..., it still would be a lot of fuss for the user,
because he would have to change the pages twice, i.e. 2  3 => => 4  5 => => ...,
but at least he could have the right views (which in the previous situation was
not possible).

Therefore I strongly support having the option of starting with a single page in
the first row vs 2 pages.

B.) Matrices
I also strongly support having the view implemented as a matrix. This is
basically a consequence of my Adobe Acrobat-experience: when Acrobat encounters
a page that does NOT fit on the screen, everything gets resized, and this is
often quite annoying.

Having every row independently displayed and zoom-factors calculated, will
create various page sizes, which will be hard to read. Therefore, it makes sense
to have everything computed globally.
Comment 56 Mathias_Bauer 2007-08-20 21:45:50 UTC
I meant not to have 2x2 pages or 2x3 pages (a "matrix") or so - I think having a
single row of pages (as much as fit to the screen width) is enough. 

Please take even the biggest screen you can get your hands on and zoom down
until you can have two complete pages above each other - do you think that it
makes sense editing them in this size?

Comment 57 Mathias_Bauer 2007-08-20 22:09:10 UTC
discoleo: if having more pages on the screen to make better use of the screen
space is the primary motivation for this issue (at least I assume that it is for
the majority of people that voted here) - why should we leave half of the screen
empty before the first page? 

I would go for e.g. "1+2 - 3+4 - 5+6" etc instead of "1 - 2+3 - 4+5 - 6" as we
would get when we followed the "book" logic.

The "odd/even" page logic IMHO also adds an unnessary complexity. Consider a
"landscape" page between some "portrait" formatted pages - this would create

        |     |
        |     |
        |     |
 |     ||     |
 |     ||     |
 |     ||     |
 |         |
 |         |
        |     |
        |     |
        |     |
 |     ||     |
 |     ||     |
 |     ||     |

or what else? IMHO a questionable benefit. I would put all pages into a single
"ribbon" and then "scroll" through them, always displaying as much of them as
fit on the screen. Most people should be happy with that.

So from that you can see that I also don't want to have more than one "row" of
pages displayed at a time. This makes everything a lot more complex and I don't
see the big benefit here. Theoretically the number of pages per row can vary and
this makes the positioning algorithm unnecessary complex. Positioning all pages
beneath each other, displaying as much of them as fit to the screen is easier
and costs less development time. And development time is a scarce resource!
Currently there's still noone available who could start working  on the new
positioning algorithm. I'm hoping for the best.
Comment 58 bctech 2007-08-20 22:19:08 UTC
For our purposes a large part of the value/importance of this feature was 
*specifically* in having pages side-by-side. You can already zoom way out on 
the main editing window and get a single line of pages one-above-the-other that 
you can still edit. What makes the MS Word approach nicer is that you can see 
other pages side-by-side and thus maintain a consistent visual formatting page-
to-page (align elements on one page to line up with others on an adjacent/
subsequent page). This becomes important for some people's work, though 
understandably many do not care about this.

So it seems like the simplest approach would be to just allow the option of 
having pages side-by-side *when zoomed out in the normal edit view*. Word 
allows this, in addition to its "editing in print preview" functionality. You 
just zoom out to a certain distance and pages start appearing side-by-side. 
Word can actually display up to 10 pages side-by-side (and as many vertically 
as necessary), and they remain editable. This is what we would like to see in 
Writer as well.
Comment 59 alexnihilo 2007-08-20 23:29:13 UTC
Ok, I haven't caught the idea of "all pages in one row". Well, finaly, mba's 
idea is rather close to what we already have, but the pages would be 
horizontaly ordered rather than verticaly stacked, no ? 

It could suit me as long as the scrollwheel of the mouse make pages scroll 
horizontaly and the ctrl+scrollwheel combination allows me to zoom on the page 
in the center of the window to edit it. It looks like the more useful for me 
to quickly browse your final doc.

Unfortunately I can't do further more than suggesting. Good luck for the job ! 
Comment 60 Mathias_Bauer 2007-08-21 12:40:00 UTC
After some thinking and discussing I agree that we still should display pages
above each other and that we should *optionally* allow to follow the "odd/even
pages" logic. One reason is that we have no editable page preview.
Comment 61 treblig 2007-08-25 17:21:26 UTC
  As previously mentioned I believe that a horizontal row of all pages would be
OK for my needs (on a wide monitor).

  However I'm not sure whether that will be enough for everyone - I agree that
with letter/A4 pages you wouldn't stack them vertically except on the highest
res monitors (I guess it is doable on those lovely 30"ers that are around);
however what about someone working at A5 e.g. on pamphlet or smaller (e.g. a CD
insert) - to them being able to work across multiple pages might be more
important than for the normal A4 user.

  As for the issue of how to display a right facing page without a corresponding
left partner; perhaps this could be indicated by a box behind the page rendering
spanning paired pages?
Comment 62 mcooper 2007-09-06 21:48:00 UTC
I am a sysadmin at a small college, and OO's lack of a multi-page editing view
is the one feature that is blocking adoption. 

Quite a few people say that it is necessary for them to work on class materials
and book chapters. Some faculty have said that they cannot write well without
seeing two pages side by side. And staff have said that they would not be able
to information packets without seeing the booklet view. 

This feature is a show-stopper, because without it, I won't be able to move
these people to OO.
Comment 63 keltick 2007-09-12 21:49:42 UTC
How has this been workd on for 6 years and not fixed yet?
Comment 64 Mathias_Bauer 2007-09-12 23:07:04 UTC
Because it hasn't been worked on for 6 years?

Please try to write something useful; your comment doesn't add anything to the
discussion. The more garbage an issue contains the harder will it be to keep the
overview and the easier it will become to lose important information.
Comment 65 keltick 2007-09-19 22:27:32 UTC
My disappointment was great when 2.3 did not have this option. I guess until
it's fixed, I'm converting to Microsoft Works. Oh well.
Comment 66 bigbirdy 2007-09-20 22:23:23 UTC
For such a fabulous product with such promise it is disappointing that we cant
get something as useful as dual page editing. Given the explosion of cheap
wide-screen monitors you would think that after 6 years this issue would have
been solved. I would LOVE to stop using MS all together but I edit and write
large documents almost every day and so depend on the side-by-side comparison
and editing of Words dual page view. I was so disappointed that after upgrading
to 2.3 this is still not supported. And I really hate having to run Word. All I
can do is hope I guess.
Comment 67 Mathias_Bauer 2007-09-21 08:40:47 UTC
It's really a pity that people don't read before they write. And adding such
useless comments as the last ones also adds to the problem that issues like this
one are so hard to work on because it's so hard to find the really useful
information below all the hot air.

Please, read at least the most recent comments before you write your own ones.
This should have told you that nobody had worked on this issue for years and
that this is the reason why we don't have this feature now. OTOH *now* people
are working on it so there is a good chance that we can get it in one of the
next releases. And that won't go faster by adding comments with zero information.

Issue Tracker is not a complaints box, it's a place to exchange reports and
technical information that helps developers to do their work and users to
describe their needs. I doubt that anything can be added to this issue that
hadn't been written already.
Comment 68 frank.meies 2007-10-05 12:07:13 UTC
Comment 69 discoleo 2007-10-06 16:10:28 UTC
The following OOo wiki-pages address this issue:

and more generally, the Writer-Layout wiki page:

Additional comments/ideas should probably go into the wiki.
Comment 70 frank.meies 2007-10-10 11:37:55 UTC
Comment 71 discoleo 2007-10-22 07:37:24 UTC
As some users may have noted, work has started on this issue.

I encourage everyone to review the specific wiki page and add useful
comments/critiques/ideas to the wiki.

There is an ongoing discussion on the UX-mailing list about the implementation
of this issue, see e.g. one of my posts there:

Basically, there are 2 main concepts/'use cases'. This adds to the complexity of
this issue (and to a somewhat heated discussion on its implementation). Comments
are surely welcomed, and also I may have missed some important use cases.

Put simply, a single - and easy - spec is not  enough. I invested some time in
analysing this issue, I have myself some experience with more complex designs,
and also searched around what people actually want.

As already stated, there are basically 2 big concepts:

  B.) fit as many pages as possible per row
     (and in the extreme case, put ALL pages horizontally
      on a single row - as asked somewhere in this issue)

  This is what most usual/non-professional/(casual) users
  want and expect. This is also what other simple
  applications like *MS Word* and *NeoOffice* do!

  A.) 2 pages per row with facing pages adjacent

  This is what professional designers need!
  And this is indeed what professional applications do.
  [e.g. in Adobe Acrobat 7 and 8, the user can select:
        View -> 'Page Display' -> 'Two Up - Continuous'
        and the 2 pages will be shown adjacent to each other.
      - in Acrobat 8 one can choose: gap vs. NO-gap between pages
      - Acrobat 7: first page is displayed alone
      - Acrobat 8: there is an option to switch on/off the display
         of the first page as a single page:
         View -> 'Page Display' -> 'Show Cover Page During Two-Up'

  Well, OOo is not the best program around for professional designers,
  BUT this option could make the 'almost impossible things'
  still a little bit easier to do. This is also the situation, where
  NO intervening-space is relevant, as professional designers might want
  to align exactly some elements on both pages.

  > I'd vote for B. IMO we shouldn't keep both because they are 
  > near-identical in function.

Unfortuantely, they are quite different, as specified above. In an 
advanced setting, one wants to view only the facing pages side by side 
(and optimally with no space in between). So it makes sense to have both 
views. [Viewing more than 2 pages is distracting, zooms out too much 
rendering any work difficult and creates various other problems, like 
with the notes-functionality.]

There are some significant problems with the following simple scenario:
  > Display as many pages as fit on the row.

  - this means, that at higher Zoom (needed to finely adjust elements on
    both pages), the next page will not necessarily fit on the same row
    - facing pages are NOT displayed adjacent anymore
  - a landscape page might not fit on the same row with the facing page
    and therefore break the facing pages order for all subsequent pages

I therefore strongly support both options. We can later debate about the 
various zoom-possibilities, but in this stage I hope that everybody 
accepts that:
 i.) there are different use cases
ii.) option A.) is used in professional settings,
      while B.) is probably warranted for simple uses

The zero-space option between facing pages is intimately related to the B.)
scenario ans is needed for greatest utility in professional settings.

Please add any further comments to the wiki page.


Leonard Mada
Comment 72 gawron 2007-10-22 10:36:35 UTC
Sorry to add this comment here instead of wiki, but I think it is important.
What about more than two pages per row, and more than one row at the same time?
This is something that eg. MS Word is capable of (so it is possible to have eg.
3 rows of pages with 4 pages per row imho), contrary to that what is stated in
the last comment (...or I do not understand it perhaps?).

Does it fall under option B or option A? Note that going for extremely simple
implementation (option B, just one row) is again only a partial solution to the
problem described by the original poster - OK, it gives many small pages on the
screen, but again a lot of wasted screen space, but this time on the bottom and
not on the left :-) 
Comment 73 discoleo 2007-10-22 19:26:44 UTC
disocleo -> gawron:
 > What about more than two pages per row, and more than one row
 > at the same time?

This will be the case!

A.) 2 pages per row
    as many rows as fit

B.) as many pages per row as fit (computed dynamically)
    as many rows as fit

discoleo -> ALL:

Is there a need for a single row with ALL pages stacked horizontally on this row?
[This is somewhere described within this issue.]

Is there a genuine need for an arbitrary (BUT constant) 'n pages' per row (with
n > 2)?
I hardly believe that there is a use case for this.

Have I forgot any useful layout method?
As I am the spec owner and represent the User-Experience (UX) in the iTeam
responsible for implementing this issue, please complain now, before this issue
gets implemented.
Comment 74 discoleo 2007-10-22 19:29:13 UTC
disocleo -> gawron:
 > What about more than two pages per row, and more than one row
 > at the same time?

This will be the case!

A.) 2 pages per row
    as many rows as fit

B.) as many pages per row as fit (computed dynamically)
    as many rows as fit

discoleo -> ALL:

Is there a need for a single row with ALL pages stacked horizontally on this row?
[This is somewhere described within this issue.]

Is there a genuine need for an arbitrary (BUT constant) 'n pages' per row (with
n > 2)?
I hardly believe that there is a use case for this.

Have I forgot any useful layout method?
As I am the spec owner and represent the User-Experience (UX) in the iTeam
responsible for implementing this issue, please complain now, before this issue
gets implemented.

Various problems need still to be addressed and solved prior to implementation:
 - see first the wiki page
 - ZOOM -> 'Page Width'
    - does NOT make much sense with option B.)
      [dynamically display as many pages as fit]
Comment 75 Regina Henschel 2007-10-22 22:02:49 UTC
Single row, multiple pages is need for a leporello (children's book, greeting
cards, banner). 
Comment 76 alexnihilo 2007-10-22 22:15:45 UTC
About zoom, please do not forget the possibility to zoom with mouse
Comment 77 alexnihilo 2007-10-22 22:17:14 UTC
About zoom, please do not forget the possibility to zoom with ctrl+mouse wheel 
and to flick through pages with mouse wheel only. Thx !
Comment 78 treblig 2007-10-27 19:49:52 UTC
I thnik the 'Competitive Product analysis' is missing the main MS Word option;
it isn't on the print layout section, it is in the 'zoom' dialogue where you can
select the number of pages in each direction that is shown.

Another comment asked whether n>2 across was useful; with a 2 monitor 1600x1200
display (which these days isn't that expensive and is what I have at work) you
can fit 4 A4 pages across easily readable - it's absolutely great for scanning
through large documents; however in this situation a 'everything on one row'
would work fine.

I would think for pamphlets however n>2 would be useful.

Comment 79 discoleo 2007-10-27 20:11:01 UTC
> Another comment asked whether n>2 across was useful;
> with a 2 monitor 1600x1200 display (which these days isn't that
> expensive and is what I have at work) you can fit 4 A4 pages
> across easily readable

This would be equally well done with the option:
 *display as many pages as fit*

Therefore, the question is, is there really a need for the option:
 - display exactly n pages per row
   [or alternatively x*y pages per screen/window]

I have serious doubts about it.
Comment 80 treblig 2007-10-27 20:23:24 UTC
Yes I think a 'as many will fit' will work; some users might have to reduce the
size of their window to get the layout right however; the classic problem with
two monitors is getting a page split over the gap; so with a 'as many as will
fit' you might end up with 3 shown with one split over the gap, where 2
straddling the gap would be preferable - however in these cases you normally
have to fiddle with the window size to get the alignment with the gap right.

Now the question is lets say you have 4 pages across and you want to get page 5
- what happens?  Do you press page down and get pages 5,6,7,8 - which means if
you are editing a section that spans 3,4,5,6 it's a pain; or (my preference) you
scroll accross so that you now see pages 2,3,4,5.  I think in the '2 pages
accross' mode I suspect the right thing is to move down to the next set of 2
like reading a book and is probably right for publishing guys; I'm mostly
involved with technical docs where I want to see the whole section I'm working
on, and I want to see that paragraphs don't get split over page boundaries and
diagrams are in the right place relative to the text, but I don't actually care
if they are left/right pages.

I do wonder what happens for pamphlet authors.
Comment 81 asedelst 2007-10-30 23:36:56 UTC
come on, I have a widescreen flat panel, and I just want to see and edit two
pages at once.  word does it and i dont want to use vmware for word processing
thats just awful.  dont make this challenging. just allow the user to view two
pages at once side by side.  

even on a non widescreen i want this
Comment 82 Mathias_Bauer 2007-10-31 11:15:47 UTC
asedelst: this attitude is the best way to screw up an application. Only caring
for the own requirements and not looking beyond one's own nose is the number one
reason for most user interface disasters.

Considering different possible requirements and their influence on the design is
absolutely indispensable for software development. That doesn't mean that you
have to include them all but it is careless not to think about them.

I understand that your requirement wrt. the display of multiple pages is limited
to a certain case but you should take into account that other users might have
other or even different requirements that deserve attention also.
Comment 83 asedelst 2007-10-31 16:26:58 UTC
I just wanted to offer my apologies.  There are no excuses so I'm not going to
bother with any attempted rationalization.  I'm just glad to know that this is
being worked on actively now.  It worried me when the top results when googling
for this issue (an idea posted on the forums) points you back at several
threads (although they do at least all usually point back a single thread) on
the forums where they discuss this has been a known lacking feature for several
years.  That said, it is surprising that so few have voted for it.  
   Granted I haven't looked too much at what new features people seem to be
desiring instead, but its hard for me to think of them.  That of course doesn't
preclude them from existing.  Shame on me for not checking the dates on the
attachments above.

I am all too aware of the tendancy with gui's to not get rid of them once they
get started, the option to throw a quick stub in to be fixed later hasn't seemed
to pan out well.  That said it follows that there would be significant planning
before anything is laid down.  It looks like things are progressing well, and I
really hope for the best.

I can't get another shot a first impression / first post; but I can step forward
from it to supplement it with better impressions.  Again my apologies to all
those hard at work on this endeavor.  Thanks
Comment 84 lengo 2007-10-31 17:05:47 UTC
I'm just watching this issue as I've got nothing to add in terms of programming
and development skills . . . But just let me say: Wow! That was big of you,
asedelst. Good to hear a 'cheer' instead of a 'jeer'. Apology accepted from me!
Comment 85 Mathias_Bauer 2007-10-31 17:16:26 UTC
acedelst: Thanks for your great reply, it's appreciated.

I'm glad to see that your comment was just caused by the wrong assumption that
no work is done for this important issue. I hope that finally as much people as
possible will be pleased with the result. Frank (fme) and Leonardo (discoleo)
are doing a great work so I'm very confident about that. :-)
Comment 86 discoleo 2007-11-02 18:44:25 UTC
There were some extensive discussions on the UX-mailing list regarding the
*ZOOM*-feature in OOo. Indeed, the *ZOOM*-dialog/menu looks somewhat
unprofessional and needs some major refurbishing.

But because of this, I would like to split the ZOOM from this issue, and devise
a more general approach to the ZOOM-problem independently of the *Multi Page View*.

What is your opinion on this? Should the ZOOM-menus/dialogs/slider be handled
independently of this issue?
[There are some common things between ZOOM and 'Multi Page View', but the ZOOM
is still distinct enough to warrant a separate implementation.]

What options should be available to change the *Page View Mode*?
 1.) MENU: VIEW -> separate entries for the different view modes
 2.) CONTEXT MENU: right click on:
       status bar/'zoom slider' (when implemented)/special button
 3.) CONTEXT MENU: right click on gray area around the document pages

I am working on an experimental context menu. It is radically different from
existing designs and customs. [Though I do not believe it will be implemented
very soon.]

I will attach a mockup and will NOT describe the details. I am curios IF
everybody gets the meaning.

Just a small hint: the whole dialog shall behave as a button, i.e. the user
shall be able to click everywhere., and upon click the corresponding action is
executed (change of 'View Mode' as depicted using the icons).
Comment 87 discoleo 2007-11-02 18:47:15 UTC
Created attachment 49383 [details]
Experimental Context Menu Design - a radically different approach to the (future) 'Select Multiple Page View'-context menus.
Comment 88 treblig 2007-11-04 02:49:26 UTC
Ah pie menus :-)

My gut feeling is that if the page view stuff isn't actually in the same dialog
as Zoom then it should hang off the View menu.

I think a context menu is useful for things that you often need to change, or
which are relevant to the context you are editing - I don't see either of those
cases being true of this; I'd expect this to be something that people set up for
the particular document they are editing or the way in which they work (due to
screen sizes or preference) and just leave it.

I think zoom and page layout are mostly independent; but I think the 'entire
page', 'page width' and 'optimal' settings in zoom are bound to interact with
the page layout; if I have selected a two-page across view then when I say
'entire page' I think I mean I want it to zoom such that both pages fit on, not
to scale for the height of one page and end up with the 2nd page off the screen.

Comment 89 discoleo 2007-11-16 13:32:40 UTC
An experimental version of the 'Multi Page View' is already available.

BUT before installing this version, some words of caution:
 1.) this version will install as OOo 2.3
 2.) it will overwrite the existing OOo 2.3
 3.) it is NOT a final version
      - it might crash
      - the GUI is NOT implemented

You can change various parameters through the 'ZOOM'-dialog, BUT these options
are put inside the 'ZOOM'-dialog just for testing purposes, and almost sure
won't be left in place.

IF you still want to install this version, the link is:

The red border around the document is for debugging purposes. There are still a
lot of problems to solve.
Comment 90 treblig 2007-11-17 22:24:24 UTC
  This is great news; I don't have a windows machine at my disposal to try that;
if you had a really easy way to throw your code through a Linux build I'd
appreciate it.

Comment 91 Mathias_Bauer 2007-11-17 22:56:54 UTC
The code is from Frank (fme). ;-)
But I think nevertheless we can arrange for a Linux build.
Comment 92 frank.meies 2007-11-18 08:07:51 UTC
fme->treblig: Give me some time, I'll see what I can do.
Comment 93 janderk 2007-11-18 10:21:22 UTC
Created attachment 49720 [details]
OO Screenshot - 2 page view
Comment 94 janderk 2007-11-18 10:24:02 UTC
Created attachment 49721 [details]
OOo Screenshot - 3 page view
Comment 95 janderk 2007-11-18 10:26:55 UTC
For those who don't have Windows I just uploaded two screenshots of the nov 16
test version at a 1920x1200 resolution. Brilliant. Especially the dynamic layout
where OO shows as many pages as fit on the screen is highly appreciated.
Comment 96 discoleo 2007-11-18 22:03:00 UTC
> I don't have a windows machine at my disposal to try that;
> if you had a really easy way to throw your code through a Linux build
> I'd appreciate it.

Unfortunately I can't help either, but I believe Frank will arrange a Linux build.

Now, back to some problems.  The iTeam had an internal discussion last week, to
decide on the best UI-design.

Unfortunately, this is ridden with problems.

What I want, and I hope to get some feedback, are the following GUI-items,
exactly in this order of importance:
1.) Menu-Entries
2.) Zoom/Layout-Dialog
3.) Status-Bar Control
4.) Context-Menu

  A.) VIEW -> Layouts
      A.1.) Print Layout (unchanged -> old default)
      A.2.) Fit as Many Pages (new DEFAULT)
      A.3.) Book Layout (2 pages without intervening space)
      A.4.) Web Layout
      These entries should be first order entries!
      NOT a submenu!
      More options will be available through the Zoom-dialog.
  B.) VIEW -> ZOOM => opens 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 are
NOT possible. I would have preferred a non-modal dialog, but this will have to
wait for a later time.

Now, lets see what is best for a MODAL Dialog.

As I sad:
 a.) separate ZOOM- and PAGE-Layout options.
 b.) ZOOM-SLIDER: it is so much more intuitive to ZOOM
 c.) should the slider be HORIZONTAL or VERTICAL
         Advantage: permits longer text;
           (fits better without overlap)
   c.2.) VERTICAL: no real advantage
 d.) Page-Layout Options
   d.1.) 'As many pages as fit' (new DEFAULT)
   d.2.) 'Exactly ... pages' -> default '2' (user may change this)
   d.3.) 'All pages in one row'
   d.4.) 'A single page per row' (was the old default style)
 e.) special options:
   e.1.) Book Mode (Facing Pages) (checkbox)
     This is very problematic!
     As told, in a modal dialog we can't recalculate various items.
   f.1.) I believe 50% and 200% values are really irrelevant.
   f.2.) There should be really something like '2 pages',
         '3 pages' and the like
   f.3.) 100% should be left

I have created a mockup (NOT really a dialog) with vertical sliders. (I will
attach it after this post.)

The ZOOM slider has the following snapping points:
  1.) 100% (DEFAULT)
  2.) 'Fit width'/'Fit Height' (precalculated, depending on
       page orientation)
  3.) 'Fit Page' (fit entire page)
  4.) '2 Pages'
  5.) '3 Pages'

The slider can take values between the snapping points. These points are only to
ease selecting the right ZOOM-Level.

There is an additional option:
  i.)  Fit to text size (aka Ignore page margins) (CHECKBOX)
  ii.) Lock ZOOM (CHECKBOX selected by default)

The ZOOM-Slider sets a ZOOM-Level AND NOT the Page-Layout, i.e. '2 Pages' means
setting a Zoom-Level so that 2 pages could fit, NOT that actually 2 pages are
displayed. IF the 'Layout-Slider' is set to 3 pages/row, then 3 pages are
displayed on one row, even IF the 3rd will scroll horizontally outside the window.

The 'Lock Zoom' readjusts the Zoom-Level, when the document window is resized.
When it is unchecked, NO readjustments happen.
Comment 97 discoleo 2007-11-18 22:05:35 UTC
Created attachment 49737 [details]
Mockup for the combined ZOOM-/Page-Layout DIALOG
Comment 98 frank.meies 2007-11-20 10:27:43 UTC
Linux snapshot available at

For the 'release notes' please see discoleo's comment from Fri Nov 16 13:32:40
+0000 2007.
Comment 99 lengo 2007-11-21 00:27:09 UTC
This is awesome! Most useful! One thing: you note that "There are still a lot of
problems to solve." I'm not sure if you've come upon this, but I have pictures
to which I have added text and lines (with Writer's 'drawing' tools). These are
in 'caption' frames (i.e. the frames that are added when one adds a caption).
The pictures do not show in OOo, but if I export to pdf the pictures display in
their proper places, but all the text and lines are anchored to the top right
corner of the page . . . I hope I've been able to explain this well enough. Hope
it helps. And thanks again!
Comment 100 frank.meies 2007-11-21 07:40:32 UTC
fme->lengo: Thank you for your feedback. You are right, the object positioning
algorithms still assume that the pages are aligned top-to-bottom. I have this on
my list
Comment 101 treblig 2007-11-24 16:30:50 UTC
Thanks! I've just tried the Linux build and it is great.
(For reference I'm trying this on Ubuntu having alien'd the RPMs)
I've just got it on my laptop here rather than my dual monitor work setup.

One thought which I suspect is a bug; I've got a 14 page document in 4 pages
book mode (also happens in 4 column mode); the layout is slightly odd:

first line is:
    gap|page   page|page
   page|page   page|page
   page|page   page|page
     page|page   page|

That is the last row of 3 pages is offset to the right a bit so that the
centre of the first two pages don't line up - all the pages are the same size
(I just took the original document and copy and pasted it repeatedly until I had
14 pages).  I'll attach a snapshot after this showing the corner at the top left
of the bottom row.
(This is on a 45% variable zoom).

I think the comments about the modal zoom dialogue might be the other issue I
have; that certainly I was fiddling to try and get a page as large as possible
with the variable zoom and I keep having to click 'OK' to see it - not directly
associated with this bug I guess, but related.  Personally I'd find an 'apply'
button would solve this problem.

However, with all that said - I'd be perfectly happy to take what you have
already got; I'm not even sure the Zoom dialogue stuff actually needs that much
work - what you currently have is very simple; but it's simple and it works
which has got to be a good thing.
Comment 102 discoleo 2007-11-25 20:10:53 UTC
Created attachment 49884 [details]
Initial Specification Draft (TRUE Spec) - Pre-Alpha
Comment 103 discoleo 2007-11-25 20:21:13 UTC
I began working on the proper Specification draft. Please note, there are still
many things to do and I am desperately needing some help.

I would welcome any help in writing the spec. There should be a functional spec
by the end of the next week, or else we risk that the implementation of this
feature gets postponed. Unfortunately, I have to prepare a lecture for next week
(for my own work), so I will be under significant pressure.

Work is possible both inside the wiki-page (see -
you will need a different login for editing the wiki), or inside the attached
document. So feel free to contribute. That's what the community is for.
Comment 104 frank.meies 2007-11-26 07:32:14 UTC
fme->trblig:Thank you for your feedback. As for the modal dialog stuff: We plan
to have a zoom slider in the status bar. This should resolve your problem. The
strange page layout problem is not reproducible with my current working version
(which hasn't been uploaded yet). Looks like I already fixed this issue.
Comment 105 discoleo 2007-11-26 08:55:06 UTC

I too can't reproduce your behaviour, even though I am using the already posted
(public) version. I examined the display in various zoom-modes and everything
seems ok. All pages in the last row default to the standard left position of any
other row. There is one instance where this is not true: IF a row contains a
page with a different page layout, then this will break the previous logic.

I will attach a picture showing this effect, though I am not so sure, what the
algorithm should do in this instance.
Comment 106 discoleo 2007-11-26 08:58:32 UTC
Created attachment 49894 [details]
Case showing effect of pages with different Layout
Comment 107 frank.meies 2007-12-14 13:11:37 UTC
New snapshots (Windows & Linux) available at

For the 'release notes' please see discoleo's comment from Fri Nov 16 13:32:40
+0000 2007.

Comment 108 treblig 2007-12-15 01:25:40 UTC
Very nice!
That seems to have cured my offset problem that I previously reported.
The slider at the bottom is interesting - it feels about right - what is the
logic as to where the little vertical marks are placed? (Is it just 50% and 100%
or something smarter? Having a mark at the 'fits 2 pages at maximum size' would
be nice).


Comment 109 frank.meies 2007-12-15 18:18:58 UTC
fme->treblig: [...] The slider at the bottom is interesting - it feels about
right - what is the
logic as to where the little vertical marks are placed? (Is it just 50% and 100%
or something smarter? Having a mark at the 'fits 2 pages at maximum size' would
be nice). [...]

There is one mark for 100%, then in

a) Automatic mode, you have a mark for '1 whole page' and for '2 whole pages'.
In case these two zoom values are too close to each other, there's only one mark.
c) n Columns mode, you have a mark for 'n whole pages'
Comment 110 norbert2 2007-12-16 11:13:21 UTC

I just have tested "OOo_2.4.0_071213_Win32Intel_install.exe".

There is a regression with the ruler. Please have a look at the attached
screenshot "OOo_2.4.0_071213_Win32Intel_install_ruler.png".

If a zoom factor < 90% is chosen, the "19" is displayed and overlaps the ruler.

Solution: The "19" should not be displayed, like in current final releases.
Comment 111 norbert2 2007-12-16 11:14:39 UTC
Created attachment 50357 [details]
Comment 112 discoleo 2007-12-16 21:00:26 UTC
There is some bug/unwanted behaviour with the Zoom-slider:

Actually, I thought that the snapping points should be set to fit horizontally
one page or 2 pages, not the whole page. This is far more useful, as I
understand. [But I am open to discuss this issue. ;-) ]

When OOo is maximised on a 1024 x 768 resolution and set to Automatic-mode:
 - the first snapping point should be set
   to fit 2 pages horizontally
   - actually, the zoom-level is 48% and there is
     enough space left around the 2 pages
     (both left and right and top-bottom)
   - at a zoom-level of 58%, both pages still fit

 - the 2nd snapping point is set to 100% (!)
  [not yet decided what is better: 100% or fit one page horizontally]
   - however, there is a jump from 100% to 139%
     when moving the slider to the right (zoom in)
   - therefore, it is not possible to zoom to something
     close to the width of the screen
    [at 100% there is still enough white space around the document]

I hope this gets improved. :-)

> a) Automatic mode, you have a mark for '1 whole page'
>    and for '2 whole pages'.
> In case these two zoom values are too close to each other,
> there's only one mark.

I bet this will never happen for any document having *non-zero width* pages. ;-)

100% and 'Fit one page horizontally' might collide on a lower resolution, while
100% and 'Fit 2 pages horizontally' might come very close on a higher
resolution, but not '1 page' and '2 pages' (except when the 2nd page has 0 width).
Comment 113 frank.meies 2007-12-17 08:19:02 UTC
fme->norbert2: Thank you for your feedback. But the reported behavior (showing
19" at certain zoom levels) can also be observed in the current master (m239).
So this isn't a regression of this cws.
Comment 114 norbert2 2007-12-18 20:45:00 UTC
I have filed issue 84723.
Comment 115 lengo 2007-12-26 05:28:25 UTC
I installed OOo_2.4.0_071213_Win32Intel_install.exe, which, in all respects that
I am able to comment on, looks great! I am wondering, however, if anyone else
has experienced the following: when I try to open (by double-clicking) a *.doc
attachment from Thunderbird ( I get a "Download Error:
C:\folder\folder\folder\*.doc could not be opened, because an unknown error
occurred. Try saving to disk first and then opening the file." Which I do and it
opens fine with Writer. I have the 'Load/Save' option set to 'load and convert'
WinWord documents, but something doesn't seem to be working between Writer and
TB. This behaviour seemed to begin when I installed OOo_2.4.0 . . . Anyway,
wondering if this is just me or if others have experienced something similar.
Comment 116 frank.meies 2007-12-26 11:12:49 UTC
fme->lengo: Thank you for your feedback. But I guess that the OOo/TB issue is
not related to my code changes. Please install a 'regular' OOo 2.4 developer
version and check if you can reproduce the problem with this version. In this
case you should submit a new issue.
Comment 117 alexnihilo 2007-12-28 22:17:14 UTC
hi, sorry if I miss something but is the trick work for Mac OS ? I've downloaded
OOo_SRC680_m241_MacOSXIntel_install.dmg and I cannot see two pages side to side,
nor can find any zoom slider... what did I do wrong ?
Comment 118 treblig 2008-01-01 19:15:39 UTC
As per the discussions on the marks on the slider; my personal points of
interest are multiple full pages - it depends on your display res; I can't do
that on my laptop since I've only got ~800 vertical but on my LCD with 1200
vertical multiple full pages is easy.  How do you make those marks generically
useful irrespective of the display you have?
Comment 119 lengo 2008-01-06 22:07:12 UTC
I have an SXGA+ monitor (1400x1050). I tend to use 'book mode'--i.e., no space
between the two pages--in an attempt to make the best use of my screen's
available space. It seems that the page view is anchored to the top left corner,
or at least the left side, but I'm wondering if it could be anchored to the
centre of the two page view so that the pages are in the middle of the Writer
window w/o having to use the 'slider' to re-centre them whenever the % zoom is
changed. Does that make sense? Basically, I'd like to be able to dictate that
the point where two pages meet in two page view is always in the middle of the
window. NOT a biggie, given how far this has come in such a short time, and how
great it is, but it would be kind of nice. Thanks for your work!
Comment 120 frank.meies 2008-01-07 07:16:24 UTC
fme->alexnihilo: This feature hasn't been integrated into the master code line
yet, I only provided a windows and a linux snapshot of the cws:
Comment 121 frank.meies 2008-01-14 12:42:43 UTC
New snapshots (Windows & Linux) available at

For the 'release notes' please see discoleo's comment from Fri Nov 16 13:32:40
+0000 2007.
Comment 122 frank.meies 2008-01-14 15:55:14 UTC
Current snapshot crashes when changing to page preview. Fix in progress.
Comment 123 jbf.faure 2008-01-19 22:22:13 UTC
Add me to CC.
Comment 124 lengo 2008-01-30 18:40:49 UTC
I'm finding that doing ctrl+z (undo) more than once(?) crashes this version of
Writer. It also undoes any character formatting (e.g., small caps, italics) in
the paragraph in which ctrl+z was performed, even though they were not part of
the 'undo' action, per se.
Comment 125 frank.meies 2008-01-30 19:15:51 UTC
fme->lengo: Sorry, I cannot reproduce this here, can anybody else? Did you check
if this also happens with a 'regular' SRC680m242? I doubt that this is related
to this feature.
Comment 126 frank.meies 2008-02-04 09:47:47 UTC
New snapshots (Windows & Linux) available at

For the 'release notes' please see discoleo's comment from Fri Nov 16 13:32:40
+0000 2007.
Comment 127 max.odendahl 2008-02-04 11:01:19 UTC

not sure if this is intentional or a bug, but when you switch from book or
multiple mode to web layout and back, this setting is gone, you always end up in
single page mode
Comment 128 stefan.baltzer 2008-02-07 18:12:52 UTC
Created attachment 51423 [details]
Specification (NOT FINAL!) Version of Jan 14th 2008
Comment 129 lengo 2008-02-16 18:38:17 UTC
Does anyone else have a problem installing dictionaries (with the Wizard) in
this version? I got through to the Start DicOOo button and then to the
Dictionaries installer however once there and on clicking the "Retrieve the
List" button it says "You don't seem to be contected to the internet. Please
verify that OOo has access to the internet." This works fine in OOo 2.3 on the
same machine.
Comment 130 discoleo 2008-02-17 02:09:29 UTC
I presume there is a bug with the Undo-Method (though I cannot currently test IF
it is present in the other branches of OOo):

When selecting 'Undo' after OOo performs a table-autoformatting (to remove the
auto-inserted table after a: | | <ENTER>), Writer (including the cursor) jumps
to the first page.

This does NOT happen with the ordinary Undo's.
Comment 131 discoleo 2008-02-17 02:28:25 UTC
Created attachment 51550 [details]
Slightly improved Spec-Draft
Comment 132 frank.meies 2008-02-18 15:02:24 UTC
fme->discoleo: [...] I presume there is a bug with the Undo-Method (though I
cannot currently test IF
it is present in the other branches of OOo) [...]

This is also reproducible with a common SRC680m245.
Comment 133 frank.meies 2008-02-26 12:52:05 UTC
fme->sba: Ready for QA.
Comment 134 frank.meies 2008-02-26 12:53:54 UTC
Comment 135 frank.meies 2008-02-26 12:54:55 UTC
Comment 137 stefan.baltzer 2008-03-06 18:38:07 UTC
Verified in CWS pages01.
Comment 138 stefan.baltzer 2008-03-06 18:55:46 UTC
Created attachment 51950 [details]
Test cases
Comment 139 helenrussian 2008-03-07 08:26:46 UTC
Add CC
Comment 140 cjeculver 2008-06-30 01:34:19 UTC
I see this is already RESOLVED, so I suspect I'm a bit late (can one open an
issue on a not-yet-published feature?), but I've just downloaded and installed
Beta 1 of the upcoming 3.0. I'm excited to see the new multi-page layout
feature; all that unused real estate on my widescreen was a big annoyance, so
congratulations on (finally! :-) ) implementing this one.

Unfortunately, however, I find the Zoom dialog a bit clunky and confusing. After
manually specifying the number of rows, it took me a few tries before I figured
out I needed to select the "Fit width and height" zoom factor to get where I was
trying to go. The meanings of "Optimal", "Fit width and height", etc., just are
not clear to me when what I want is multiple row and column display.

I hate to suggest copying MS, but I think the click-and-drag approach in Word is
both easier and more visually intuitive.

That being said, *thank you* also for Book Mode, the lack of which always
annoyed me in Word.
Comment 141 Mathias_Bauer 2008-06-30 07:26:32 UTC
You don't need the dialog, just use the buttons and the slide in the status bar.
Fast and easy. :-)
Comment 142 stefan.baltzer 2008-08-01 16:22:53 UTC
SBA: Still OK in DEV300_m29/OOO300_m0.