Bug 117995 - Faulty page numbering sequence when using paragraph style page break
Summary: Faulty page numbering sequence when using paragraph style page break
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Fields-Page-Number
  Show dependency treegraph
 
Reported: 2018-06-04 14:26 UTC by ajlittoz
Modified: 2023-09-04 08:21 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Sample document exhibiting faulty page number sequence (34.66 KB, application/vnd.oasis.opendocument.text)
2018-06-04 14:28 UTC, ajlittoz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ajlittoz 2018-06-04 14:26:44 UTC
Description:
Text flow for a paragraph style is set to cause page break "before" to a dedicated page style with page number forced to restart. This page style (for the first page in a book part) has a "Next Style" rule to make subsequent pages use another style (common pages of the book part, so that header is different from first page).

The book part is written, styling the first paragraph with said paragraph style. Subsequent paragraphs are styled according to "Next Style" rule until style settles in a "Text Body"-like one.

Page break occurs as expected switching to desired page style and subsequent pages have the  expected style.

However, page number sequence is n, 1, 2, 3, … where n is the forced page number in the "Text Flow" tab of the paragraph style.

I've tried various workarounds but they don't survive save-exit-open cycle. The only effective workaround is to remove the page break from style definition and insert a manual page break with the same properties.

Why does it work with manual page break and not with specially crafted paragraph style?



Steps to Reproduce:
Use the attached document. Go to the license chapter to see the effect where page number is forced to 25. To revert to a "normal" situation:

1. Modify "GNU FDL Title" paragraph style to uncheck the "Insert break" check box in "Text Flow" tab
2. Insert a manual page break before the heading of the license chapter with page style LicenceStart and page number 25
3. Sequence is now correct

Actual Results:  
Page number to forced value on first page after break, then sequence restarted at 1

Expected Results:
Monotonically increasing page number


Reproducible: Sometimes


User Profile Reset: Yes



Additional Info:
The problem appeared a few releases back with a template applied to many documents. The attached sample inherits directly from this template.

Since the template is in constant evolution, I don't remember which editing steps brought it to its present state.

I've even tried to delete and re-create the involved styles (paragraph + page) to no avail. If I try to build from scratch a small sample document with same characteristics, it works like a charm. I don't know if it's a matter of size.

I had a look to the XML.

The paragraph style with break <style:style … > has an attribute style:master-page-name="…" with a nested <style;paragraph-properties … style:page-number="25" … >

Both data are missing in the "revised" paragraph style (without break).

In the faulty document, usage is:

     <text:h text:style-name="name_of_the_style" … />

In the "corrected" document, a new paragraph style is defined to account for the manual page break as:

     <style:style style:name="P39" style:family="paragraph"
                  style:parent-style-name="name_of_the_style"
                  style:master-page-name="page_style_to_switch_to">

with an embedded element

    <style:paragraph-properties style:page-number=25"/>

At the point of use we have:

     <text:h text:style-name="name_of_the_style" … />
     <text:h text:style-name="P39" …> … </text:h>

These are the only differences I've noticed, but I'm no XML specialist.


User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Comment 1 ajlittoz 2018-06-04 14:28:46 UTC
Created attachment 142516 [details]
Sample document exhibiting faulty page number sequence
Comment 2 Buovjaga 2018-06-22 11:58:48 UTC
It looks the same in 3.3.0.

It is a bit problematic that you cannot find steps to reproduce, but let's set to NEW and some guru can comment.

Arch Linux 64-bit
Version: 6.2.0.0.alpha0+
Build ID: 5b42a17dc99fba2ccf8dd8d0a8e0e4e836e30120
CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on June 22nd 2018

Arch Linux 64-bit
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 3 ajlittoz 2018-06-22 15:14:32 UTC
(In reply to Buovjaga from comment #2)
> It looks the same in 3.3.0.
> 
> Arch Linux 64-bit
> LibreOffice 3.3.0 
> tag libreoffice-3.3.0.4

Are you sure you really mean version 3.3.0? Up-to-date version is already in the 6.0-6.1 series.
Comment 4 Buovjaga 2018-06-22 15:22:22 UTC
(In reply to ajlittoz from comment #3)
> (In reply to Buovjaga from comment #2)
> > It looks the same in 3.3.0.
> > 
> > Arch Linux 64-bit
> > LibreOffice 3.3.0 
> > tag libreoffice-3.3.0.4
> 
> Are you sure you really mean version 3.3.0? Up-to-date version is already in
> the 6.0-6.1 series.

https://wiki.documentfoundation.org/QA/BugTriage#Step_7:_Regression_Testing
Comment 5 QA Administrators 2019-06-23 02:52:20 UTC Comment hidden (obsolete)
Comment 6 ajlittoz 2019-06-26 17:05:00 UTC
Bug still present in 6.1.x
Comment 7 ajlittoz 2021-08-29 14:31:16 UTC
Still present in 7.0.5.2

A Writer user reported me a similar case in his book. He restarts (or tries to) numbering in every chapter but this is what he gets:

- first page of chapter is (previous chapter page number)+1
- second page of chapter is 1
- following pages have standard sequence 2, 3, …

I checked his document (cannot be attached because of size and privacy). It uses separate page styles for first, left and right pages. To the best of my knowledge, they are correctly configured.

Mis-hap is very sensitive to editing history. When he prepared a sample for me, the problem randomly disappeared. He had to erase the end of the file and to keep the beginning, which resulted in a big file.
Comment 8 QA Administrators 2023-08-30 03:05:48 UTC Comment hidden (obsolete)
Comment 9 ajlittoz 2023-09-04 08:21:24 UTC
Bug still present in 7.5.5.2 (which is the "production" release in my Fedora 38 distro)