Bug 168272 - Simplify Page Break and Page Style Handling in Writer
Summary: Simplify Page Break and Page Style Handling in Writer
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
25.8.1.1 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyInteresting, easyHack, skillCpp
Depends on:
Blocks: Writer-Page-Break Writer-Styles-Page
  Show dependency treegraph
 
Reported: 2025-09-03 23:16 UTC by Dragan
Modified: 2025-09-25 20:35 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dragan 2025-09-03 23:16:52 UTC
Description:
Current page break and page style handling in LibreOffice Writer is confusing and unintuitive.
    • Insert → Page Break only moves the cursor to the next page without affecting the current style.
    • Insert → Manual Break → Page Style is overly complex and requires knowing the target style in advance.
Proposed: Introduce a Page Break feature that breaks the page, ends the current style (any style the user is on), and allows choosing a new style immediately.

Steps to Reproduce:
    1. Open a document in Writer.
    2. Apply any page style.
    3. Attempt to insert a page break while changing the style.
    4. Observe that current options are either confusing or redundant.

Actual Results:
    • Insert → Page Break does not change the page style.
    • Insert → Manual Break → Page Style requires multiple steps and prior knowledge of the style.

Expected Results:
    • Page Break should break the page, end the previous style (any style the user is on), and prompt the user to select a new style from predefined or custom options.
    • User should be able to update the style immediately.


Reproducible: Always


User Profile Reset: No

Additional Info:
Users often lose productivity due to complicated handling of page styles. Simplifying this workflow would reduce frustration and save time, especially in multi-section documents.
Comment 1 m_a_riosv 2025-09-04 00:06:10 UTC
I'm not sure that the pages are being managed in the best way.
Please ask for help at https://ask.libreoffice.org/c/english/5/l/latest.
There are people there with extensive knowledge of Writer.
Comment 2 V Stuart Foote 2025-09-04 12:24:13 UTC
No real advantage to reworking current work flow. "Eve" users accustomed to working with page styles already are well served. "Benjamin" users rarely make use of page styles other than 'default' in their documents.

Process is well documented in the WGs and in the Help.

IMHO => WF
Comment 3 Heiko Tietze 2025-09-09 09:52:55 UTC
(In reply to Dragan from comment #0)
>     • Insert → Manual Break → Page Style is overly complex and requires
> knowing the target style in advance.
I disagree with "overly complex". If you strip off the Line and Column Break you end up in the same situation as suggested: you have to decide how to proceed after the break (resp. a PgS that exists). If you argue to remove Line and Column Break it would come on cost of more dialogs, more commands and more menu items. 
 
> Expected Results:
>     • Page Break should break the page, end the previous style (any style
> the user is on), and prompt the user to select a new style from predefined
> or custom options.
>     • User should be able to update the style immediately.
You can click the thin line between the pages and edit the page break (actually the paragraph). Admittedly, it requires some expertise.

> Users often lose productivity due to complicated handling of page styles.
> Simplifying this workflow would reduce frustration and save time, especially
> in multi-section documents.
Agreed. Bug 161078 discussed to "Allow direct formatting for page sequences instead of editing the style". How about to jump onto this train and make the ticket a duplicate?
Comment 4 V Stuart Foote 2025-09-09 11:02:47 UTC
OP aligns with discussion of bug 161078, IMHO also a dupe.
Comment 5 Eyal Rozenberg 2025-09-18 22:04:44 UTC
So, this bug report approach a messy situation from one specific angle, which is 
how page breaking is presented to the user, and what the user can do within the confines of page styling as it now exists.

In LibreOffice, 

* (single) pages aren't first-class citizens: They are merely the result of applying pagination to page sequences.
* In fact, one can't even change the style of a single sequence of pages - one can only change named page styles; there is no direct formatting of page sequences, unlike Character, Paragraph and List styles; that is my bug 161078. Thaty means, that if you change the formatting of your current page, not just the current page _sequence_ changes, but all pages with the same named style, which is rarely what you want.
* Page (sequence) styles don't inherit - at all, it seems; just filed this as bug 168471, although there may be a dupe.
* One can't apply multiple styles to a page sequence, despite the ODF format supporting multiple styles per element quite readily; that's bug 149271. That means you can't mix-and-match named styles corresponding to your interests, e.g. Blue Background and frilly edge decoration, which might each be their own style on top of Landscape.
* Many of the default styles we have on display are rather nonsensical IMNSHO, and should actually not be used: https://bugs.documentfoundation.org/show_bug.cgi?id=153534

Now, changes to some of these aspects of the current state of affairs could have interesting synergy with this bug report. A particular example would be having a page create a new DF style when the user breaks the paragraph - whereas with the current proposal, the user must select a named page style. Why?
Comment 6 Heiko Tietze 2025-09-19 06:55:45 UTC
We discussed the topic in the design meeting.

The use case is clear and common: Benjamin wants to add a landscape oriented page to the document to show a large table. 

MSO offers a toggle portrait/landscape but changes the whole document as well.

The action requires a deep understanding of the software: 
* add a manual page break after the last paragraph with a new page style
* insert content
* add a manual page break after the last paragraph with the previous page style

This can be simplified with a function that does exactly this: find the last paragraph, add a page style with the same variables as the current but toggle the page orientation, add a page break with the current style. 

It would be convenient to consider a selection, also when spanning multiple pages. One shortcoming of this procedure might be to toggle it again: in this case we would add blank pages before/after that a user has to delete manually.

Bug 161078 is not focused on behavior when breaking pages, nor on the style of individual pages; it is somewhat orthogonal to this proposal. => not a duplicate
The proposal also talks around the actual request "Introduce a Page Break feature that breaks the page, ends the current style (any style the user is on), and allows choosing a new style immediately.", which was assessed as WF. Dragan: if you disagree with the proposal as solution please comment.

This might be an easyhack. Code pointer are welcome.
Comment 7 Eyal Rozenberg 2025-09-19 20:35:21 UTC
(In reply to Heiko Tietze from comment #6)
> The use case is clear and common: Benjamin wants to add a landscape oriented
> page to the document to show a large table. 

Reading those words, a thought has occurred to me.

Is the use case you described really that simple? It seems to complect two things: Adding a new page (sequence), and switching page sequence style.

Think about the equivalent w.r.t. paragraphs. When you want to add a new paragraph to your document, with different styling, is there a special UI function for doing so? No, there isn't: You add a new paragraph, then format it differently, either with DF or by choosing a named style.

Why should this be different for page sequences? It shouldn't!

The user should not care about page sequence styles when adding a page break. Instead, _after_ the break, the user should be able to DF the current page sequence (e.g. make the pages landscape), or switch to a different named page sequence style. Naturally, that DF or named style would only applied to the pages beginning with the break.

If we went this way, we could actually _eliminate_ page sequence styles from the page break insertion dialog altogether.

What do you all think? Dragan, Heiko?
Comment 8 Mike Kaganski 2025-09-20 05:56:00 UTC
(In reply to Eyal Rozenberg from comment #7)

So your imagined function would be limited to (up to) two already existing manual page breaks, one before the start of current selection, and one after the end of it? IMO, it makes sense.
Comment 9 Eyal Rozenberg 2025-09-21 14:19:53 UTC
(In reply to Mike Kaganski from comment #8)
> So your imagined function would be limited to (up to) two already existing
> manual page breaks, one before the start of current selection, and one after
> the end of it? IMO, it makes sense.

Hi Mike :-)  I missed you at LibOCon this year...

Assuming by the "imagined function" you mean the application of DF, then yes, it's just as you said: If you Format > Page... without selecting anything, it would affect the page sequence between the last page break before the cursor, and the first page break after it (or the start/end of the document if there are no such breaks).

Entering Format > Page... with a selection present actually "muddies the waters" somewhat - as the user's intent becomes less obvious:

* A selection typically doesn't agree with page sequence boundaries; does the user mean to affect those pages which are half-selected?
* Does the user want to introduce page breaks right before and after the selection? Or do they want to style existing page sequences, intersecting the selection?

I would suggest a conservative interpretation in such cases: Assuming that no new breaks are to be introduced, and having all page sequences intersecting the selection be affected. This is also what we do, IIANM, when we have a selection intersecting multiple paragraphs, but not fully covering them, when we apply some paragraph-level DF, like inter-line vspacing.
Comment 10 Mike Kaganski 2025-09-21 15:19:07 UTC
(In reply to Eyal Rozenberg from comment #9)
> Entering Format > Page... with a selection present actually "muddies the
> waters" somewhat - as the user's intent becomes less obvious:
> 
> * A selection typically doesn't agree with page sequence boundaries; does
> the user mean to affect those pages which are half-selected?
> * Does the user want to introduce page breaks right before and after the
> selection? Or do they want to style existing page sequences, intersecting
> the selection?
> 
> I would suggest a conservative interpretation in such cases: Assuming that
> no new breaks are to be introduced, and having all page sequences
> intersecting the selection be affected.

Well - what should then happen to the page-breaks-with-page-style in the middle of the selection?

I imagine problems e.g. in the most obvious choice: "Let's unassign all of them! Let them be simple page breaks."
=> every heading that defines a "first page of chapter" will break.

Keeping them would also surprise everyone who has this mental model: "I selected it, and asked to apply a page style! I expect it to do just what I requested".
Comment 11 Eyal Rozenberg 2025-09-21 21:08:21 UTC
(In reply to Mike Kaganski from comment #10)
> Well - what should then happen to the page-breaks-with-page-style in the
> middle of the selection?

First, in the "mental model" of the document - or at least my mental model - the page sequence style is a feature of a page sequence. The fact that it's literally written in a page break element in the ODF is not very fundamental to my view. But - that's just an observation regarding phrasing.

Anyway, the answer is the same as for the case of paragraphs. That is, instead of whatever page style they had before, they would now get a different page style - either a named one, if the page formatting action was choosing a named style, or a generated unnamed one, if the formatting action was applying DF.

> I imagine problems e.g. in the most obvious choice: "Let's unassign all of
> them! Let them be simple page breaks."

If I understand what the quote means, then - that is not what I'm suggesting.

> Keeping them would also surprise everyone who has this mental model: "I
> selected it, and asked to apply a page style! I expect it to do just what I
> requested".

User would expect it a page style to be applied - And it would be applied. But since the page sequences covering the selection involved more pages before and after it - then a larger range of pages got the formatting change / named page sequence style applied.

Just like with paragraphs. Can illustrate with a screen grab if that helps clarify what I'm saying.
Comment 12 Mike Kaganski 2025-09-22 04:37:48 UTC
(In reply to Eyal Rozenberg from comment #11)
> First, in the "mental model" of the document - or at least my mental model -
> the page sequence style is a feature of a page sequence. The fact that it's
> literally written in a page break element in the ODF is not very fundamental
> to my view.

IMO, this *is* fundamental. I may agree, that it's not very fundamental, that it's part of *paragraph* properties. I can envision, that another type of a page break appears some day, allowing to break pages without breaking paragraphs. But it is a fundamental thing, that a page style assignment happens in a page break (of any kind); and that page break is part of text flow. The idea of "page sequence" can't be useful mental model, unless it *somehow* joins to text flow - and page break is that connecting point.

> Anyway, the answer is the same as for the case of paragraphs. That is,
> instead of whatever page style they had before, they would now get a
> different page style - either a named one, if the page formatting action was
> choosing a named style, or a generated unnamed one, if the formatting action
> was applying DF.

I see: your idea is neither "unassign them all", nor "keep them as they were", but "reassign them". Makes sense.