(In reply to Mike Kaganski from comment #0)

> TBH, I have no idea how to implement such an option (how it should even look
> in the UI). OTOH, this could be unneeded (or its need at least somewhat
> lessened), if we extend our "not same content on left/right/first page" page
> style setting to mean really different headers/footers/ not only content
> (which, I believe, is possible with ODF, but not supported in LO), so that
> one could disable or resize headers/footers independently for the
> first/left/right case.

I think we're facing two different goals.

The first one is traditional typography: a first page to start a chapter then simple alternation between left and right pages.

This is perfectly implemented in the current page style concept. Except, "geometric" attributes, i.e. margins, area colour, footnote disposition, are shared by the variants. However, recent LO release have improved the case by providing the Gutter configuration which is the main reason for "geometric" variants. Unfortunately other effects can't be achieved.

The second one is a more complex scheme using the Next style parameter. Her we can have more complex schemes than simple dual alternation. The style cycle may be longer than 2 styles. And, yes, if some styles of the cycles are assigned odd/even constraints, managing the sequence (synchronising its starting point) becomes extremely difficult.

One approach would be to consider that a manual break requesting a page style doesn't in fact switch to the designated page style but to the sequence as a whole.

This may need some post-processing whenever the Next style parameter is altered to flag the any member of the sequence that there is an odd/even constraint somewhere. May prove difficult if the sequence may be entered from several points as:

- E1 P1 P2 P3 P1 …    (E1 = page style entry #1 into sequence P1 P2 P3)
- E2 P2 P3 P1 P2 …    (E2 = page style entry #2)

When the sequence has a single style (most common case), we have the present behaviour to switch unconditionally to the designated page style, eventually skipping a blank page.

With an alternating 2-style odd/even sequence, if the first page is not synchronised, the sequence is followed to find a "compatible" page style, i.e. the correct parity or unconstrained page style. If none is found, a blank page is inserted and the first page style is activated.

This means we can have odd/odd or even/even to print on every other page.

BUT, this breaks compatibility with present documents unless there is a setting requesting the "synchronising" behaviour. Failing that, we have the present behaviour.

Things get really complicated with a longer sequence. It should be scanned to find the first compatible page style with next page parity.

Maybe the idea of the sync setting could be an attribute of the manual break: unconditionally apply the sequence if not set or scan sequence if set and stop on first parity-compatible style.

In any case, this only applies to manual breaks. Implicit breaks, i.e. when reaching the bottom of the page, switch to next style in sequence.

While writing this, I realise that this does not solve the case of a "first page style" before a cycle as in E1 P1 P2 P1 … because the syncing behaviour must occur on the style following E1.

So I think this boils down to being able to identify style cycles and flag them as "unconditional" or "sync'ing". Synchronisation occurs when we switch from a "normal" style to a "cycle" style.

Anyway, this needs a thorough thinking about and pondering if it worth it.

Currently in ODF, the to be used page style is determined by a style:master-page-name attribute in the paragraph style, which is assigned to the paragraph.

I can imagine to have a new attribute "style:master-page-names" (notice the plural) with data type styleNameRefs for a list of two styles, one for even and the other for odd pages.

The corresponding API property is PageDescName of type string.

Heiko, is it up to design team to decide here or how can we come to a decision (UNCONIRMED for more than 1 1/2 years).

Mike, please remember to hang RTL bugs on the RTL-CTL meta-bug, as otherwise we (RTL-interested users and other developers) don't notice them... I noticed this one because it got onto the design meeting agenda.

(In reply to Mike Kaganski from comment #0)
> You need an alternating left/right page style layout

Actually, almost no user ever needs "Left page"'s or "Right page"'s as they exist currently. There are mis-named and mis-designed artifacts which were added at some point without sufficient thought and need to be removed / revamped-and-renamed. It is also not at all clear what a "left page" is left _of_. "Left-of-gutter" could be a meaningful characterization of a page; one can therefore have recto, verso [1], left-of-gutter, right-of-gutter. But remember that these labels need to change when the gutter is vertical rather than horizontal. This has been partially discussed on bug 153534, specifically opening comment items (9.) and (10.); comment #2 first paragraph; most of comment #5.

> having a first page,
> assigned to a Heading N paragraph style - so that each chapter starts with a
> dedicated "first chapter page" style, followed by alternating left/right
> style sequence.

While this can be be achievable by an alternating sequence of page styles, I would claim that this should be just a single page style. Page styles already support differences between alternating pages (although - in a way that's either vague and confusing or just broken, haven't fully checked): There's gutter support and support for different header and footer content on alternating pages. Support for other differentiation should be added IMNSHO.


> You need different page styles for that - e.g., to have
> different header/footer height (so you can't use a single style with
> different header/footer content);

So, I would say that's a bug.

> but *you don't want your chapter be fixed
> on, say, right page* - so that chapter may start on left or on right pages,
> as needed.

OK, but remember that it is very common for chapters to always start on a recto page.

> This can't be done currently - because you can't define in the paragraph
> style and/or page style, that a page style must be chosen based on some rule
> (e.g., left/right). The page after "first chapter page style" will be
> *either* fixed left, *or* fixed right - but not "left or right, as required".
> 
> TBH, I have no idea how to implement such an option (how it should even look
> in the UI). OTOH, this could be unneeded (or its need at least somewhat
> lessened), if we extend our "not same content on left/right/first page" page
> style setting to mean really different headers/footers/ not only content
> (which, I believe, is possible with ODF, but not supported in LO), so that
> one could disable or resize headers/footers independently for the
> first/left/right case.

I support this latter option. But - once we remove the "Left Page" / "Right Page" styles, and replace the "Left Page" / "Right Page" mess in UI labels with something meaningful, we may want to be able to have a toggle "This page style starts on a ___ page: Recto / Verso / Left-of-gutter / Right-of-gutter / Any". Of course, we may want to support paragraphs having a text-flow-control feature of "starts a new ____ page: Recto / Verso / Left-of-gutter / Right-of-gutter / Any".

This also relates to the question of Start/End vs Left/Right, see bug 131192.


  [1] - https://en.wikipedia.org/wiki/Recto_and_verso

(In reply to Mike Kaganski from comment #0)

> OTOH, this could be unneeded (or its need at least somewhat
> lessened), if we extend our "not same content on left/right/first page" page
> style setting to mean really different headers/footers/ not only content
> (which, I believe, is possible with ODF, but not supported in LO),...
Miklos knows more on the background.

(In reply to Eyal Rozenberg from comment #5)

> Actually, almost no user ever needs "Left page"'s or "Right page"'s as they
> exist currently.
I doubt.

> There are mis-named and mis-designed artifacts which were
> added at some point without sufficient thought and need to be removed /
> revamped-and-renamed.
'Left' and 'Right' is in various cases not factual correct indeed. It is a concept however that is understandable.

> While this can be be achievable by an alternating sequence of page styles, I
> would claim that this should be just a single page style. Page styles
> already support differences between alternating pages (although - in a way
> that's either vague and confusing or just broken, haven't fully checked):
The 'different first page' doesn't cater for the use case that Mike suggests. It is a copy of the Ms Word behavior, basically not needed since we can define a style sequence.

> I support this latter option. But - once we remove the "Left Page" / "Right
> Page" styles, and replace the "Left Page" / "Right Page" mess in UI labels
> with something meaningful, ...
Do you have a suggestion for an alternative naming?


cheers - Cor

The topic was on the agenda of the design meeting.

Seems to me that we have plenty of options to control the page style. Whether H1 is assigned to "Left Page" (or "Odd Page") followed by Left/Right, or to "Right Page" - this works well. And is more or less easy to understand.

The complications are hard to follow, and the question is what real use case requires this.

Dear Mike Kaganski,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp