Issue 1598

REassigned to Falko.

Yes, this should be possible.

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.

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!

*** Issue 21729 has been marked as a duplicate of this issue. ***

*** Issue 32898 has been marked as a duplicate of this issue. ***

*** Issue 33070 has been marked as a duplicate of this issue. ***

*** Issue 34364 has been marked as a duplicate of this issue. ***

defaulting prio, setting keywords,reassigning according to new RFE-process

*** Issue 24772 has been marked as a duplicate of this issue. ***

*** Issue 30443 has been marked as a duplicate of this issue. ***

*** Issue 4307 has been marked as a duplicate of this issue. ***

*** Issue 39586 has been marked as a duplicate of this issue. ***

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

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.

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.

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
specified. 
(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.

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.

.

Created attachment 27085 [details]
Mockup of current and preferred edit view (facing pages).

Also see this RFE in Abiword for progress / comparison:
http://bugzilla.abisource.com/show_bug.cgi?id=7913

Has there been any update?  is anything happening?

add my votes

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

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

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?

This would be a very useful feature for those of us working on large widescreen
monitors.  Thanks.

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.

*** Issue 75713 has been marked as a duplicate of this issue. ***

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

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

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?

Faustop is right: it has been noticed for several years ! But in Abiword they 
seem no to have solved the bug either... 
(http://bugzilla.abisource.com/show_bug.cgi?id=7913) 
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...

Created attachment 44118 [details]
2 Page view in MS Word Mac X

Created attachment 44119 [details]
3 Page view in MS Word Mac X

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:

msword-two-page.png
msword-three-page.png

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?

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.

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.

dannep:

This is no solution because it is impossible to edit the same document (file) in
two Writer instances at the same time!

@norbert2:
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 (_*_)

alexnihilo:

Sorry, this was my mistake. You and dannep are right. I did not know about this
feature to open one document in two windows.

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.


alexnihilo, 

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.

Ben

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

*** Issue 78683 has been marked as a duplicate of this issue. ***

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.

Created attachment 46947 [details]
Draft Specification - v001

Thanks for your document! I will have look on it in a few weeks. Tomorrow I will
go on vacation. :-)

Hi,
  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.

Added this issue to the
http://wiki.services.openoffice.org/wiki/Writer/ToDo/Layout page (Writer TODO page).

Created attachment 47004 [details]
DRAFT v002 - Extended slightly the draft

os removed from cc

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

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

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

@mba:

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

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:
   1
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.

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?

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.

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.

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 ! 

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.

Hi,
  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?

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.

How has this been workd on for 6 years and not fixed yet?

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.

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.

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.

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.

.

The following OOo wiki-pages address this issue:
http://wiki.services.openoffice.org/wiki/Writer/ToDo/Layout/Multi_Page_Layout

and more generally, the Writer-Layout wiki page:
http://wiki.services.openoffice.org/wiki/Writer/ToDo/Layout

Additional comments/ideas should probably go into the wiki.

.

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.
(see http://wiki.services.openoffice.org/wiki/Writer/ToDo/Layout/Multi_Page_Layout)

There is an ongoing discussion on the UX-mailing list about the implementation
of this issue, see e.g. one of my posts there:
http://ux.openoffice.org/servlets/ReadMsg?list=discuss&msgNo=819

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.

Sincerely,

Leonard Mada

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

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.

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]

Single row, multiple pages is need for a leporello (children's book, greeting
cards, banner). 

About zoom, please do not forget the possibility to zoom with mouse

About zoom, please do not forget the possibility to zoom with ctrl+mouse wheel 
and to flick through pages with mouse wheel only. Thx !

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.

Dave

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

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

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

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.

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 oo.org 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

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!

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

A.) ZOOM
========
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*.

discoleo->ALL
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.]


B.) UI/MENUS/CONTEXT MENUS
==========================
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


C.) EXPERIMENTAL CONTEXT MENU
=============================
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).

Created attachment 49383 [details]
Experimental Context Menu Design - a radically different approach to the (future) 'Select Multiple Page View'-context menus.

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.

Dave

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:
http://ooo.services.openoffice.org/pub/OpenOffice.org/cws/upload/fme/

The red border around the document is for debugging purposes. There are still a
lot of problems to solve.

discoleo:
  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.

Dave

The code is from Frank (fme). ;-)
But I think nevertheless we can arrange for a Linux build.

fme->treblig: Give me some time, I'll see what I can do.

Created attachment 49720 [details]
OO Screenshot - 2 page view

Created attachment 49721 [details]
OOo Screenshot - 3 page view

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.

> 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

1.) MENU-ENTRIES
================
  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

2.) 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
   c.1.) HORIZONTAL
         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)
 f.) ZOOM-Slider SNAPPING POINTS
     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.

Created attachment 49737 [details]
Mockup for the combined ZOOM-/Page-Layout DIALOG

Linux snapshot available at 

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

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

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!

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

http://wiki.services.openoffice.org/wiki/Writer/ToDo/Layout/Multi_Page_Layout#Implementation:_Progress.2FToDo

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.

Created attachment 49884 [details]
Initial Specification Draft (TRUE Spec) - Pre-Alpha

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
http://wiki.services.openoffice.org/wiki/Writer/ToDo/Layout/Multi_Page_Layout -
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.

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.

discoleo->treblig

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.

Created attachment 49894 [details]
Case showing effect of pages with different Layout

New snapshots (Windows & Linux) available at 

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

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

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

Dave

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'

Hi.

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.

Created attachment 50357 [details]
OOo_2.4.0_071213_Win32Intel_install_ruler.png

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
     horizontally

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

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.

norbert2->fme:
I have filed issue 84723.

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

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.

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 ?

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?

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!

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:

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

New snapshots (Windows & Linux) available at 

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

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

Current snapshot crashes when changing to page preview. Fix in progress.

Add me to CC.

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.

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.

New snapshots (Windows & Linux) available at 

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

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

@fme:

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

Created attachment 51423 [details]
Specification (NOT FINAL!) Version of Jan 14th 2008

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.

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.

Created attachment 51550 [details]
Slightly improved Spec-Draft

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.

fme->sba: Ready for QA.

.

.

Link to spec.:
http://specs.openoffice.org/writer/statusbar/Multiple_Pages_View_and_Zoom_Control.odt

Verified in CWS pages01.

Created attachment 51950 [details]
Test cases

Add CC

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.

You don't need the dialog, just use the buttons and the slide in the status bar.
Fast and easy. :-)

SBA: Still OK in DEV300_m29/OOO300_m0.
Closed.