Bug 138907 - Format - Title Page dialog specifies a Page 1 restart for non-title page, but that is lost on fileopen.
Summary: Format - Title Page dialog specifies a Page 1 restart for non-title page, but...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: medium minor
Assignee: Justin L
URL:
Whiteboard: target:7.2.0 target:7.1.0.2
Keywords:
: 35136 140433 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-12-14 17:26 UTC by Alan Robinson
Modified: 2021-05-12 13:33 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Document demonstrating problem (21.81 KB, application/vnd.oasis.opendocument.text)
2020-12-14 17:27 UTC, Alan Robinson
Details
titlePage.odt: run format-titlePage twice and first-page's page number changes (10.62 KB, application/vnd.oasis.opendocument.text)
2020-12-25 18:43 UTC, Justin L
Details
Title page - setting and behavior (84.80 KB, image/jpeg)
2020-12-30 09:42 UTC, Martin Srdoš
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Robinson 2020-12-14 17:26:41 UTC
Description:
When a document containing a title page is opened, the existence of the title page is not taken into account in page number fields.

The title page has to be added again every time the document is opened.

Steps to Reproduce:
1. Open the attached document.
2. Follow instructions in document.

Actual Results:
Page numbering in the footer starts at 2, despite the presence of the title page.

Expected Results:
Existence of title page should be taken into account.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 7.0.3.1 (x64)
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded
Comment 1 Alan Robinson 2020-12-14 17:27:21 UTC
Created attachment 168158 [details]
Document demonstrating problem
Comment 2 [REDACTED] 2020-12-14 17:49:10 UTC
Don't understand the instructions within the document. Why to add a second title page - the document attached already contains a title page. Forcing insertion of another page shows me 3 / 3 pages on page containing instruction which is page 2 when opening the document.
Comment 3 Alan Robinson 2020-12-14 18:00:06 UTC
Uwe,

This is not about adding an *extra* title page.

When opening the document, the second page, which shows as page 2 of 2 in the footer, should show as page 1 of 2 because the page numbering excludes the title page.

If you open the document and click Format->Title Page you will see that there is a title page, but this is not taken into account in the page number field in the footer. If you then simply click OK without entering any info the footer shows page 1 of 1, which is correct.

The nuisance is that you have to do this every time the document is opened to get the footer showing the correct page 1 of 1, instead of the incorrect page 2 of 2. While this is a workaround, it is far too easy to forget to do it.

Regards, Alan R.
Comment 4 Telesto 2020-12-15 09:34:18 UTC
Found in
Version: 7.2.0.0.alpha0+ (x64)
Build ID: 35e471bb4d1388cf5afcdcee214cf5111edf44e3
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

and in
Version: 5.2.5.0.0+
Build ID: a4d4fbeb623013f6377b30711ceedb38ea4b49f8
CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL; 
TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-2, Time: 2016-12-24_14:43:55
Locale: nl-NL (nl_NL); Calc: group

fine in
Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL
[There might be 'some delay' but's automatically corrected after 3 or 4 seconds]
Comment 5 Martin Srdoš 2020-12-24 20:41:13 UTC
Report from bibisecting:

ed52a497616ced065ffb50560e6e4bfc3af41b96 is the first bad commit
commit ed52a497616ced065ffb50560e6e4bfc3af41b96
Author: TDF builder <tdf@tb83-bytemark.local>
Date:   Fri Dec 14 22:58:07 2018 +0000

    source sha:22355042a6fc7aecf3caab69b3fa3be1430b697f

    source sha:22355042a6fc7aecf3caab69b3fa3be1430b697f

 instdir/program/swlo.dll    | Bin 14767104 -> 14767104 bytes
 instdir/program/version.ini |   2 +-
 instdir/program/xolo.dll    | Bin 5597184 -> 5597184 bytes
 3 files changed, 1 insertion(+), 1 deletion(-)

I am sending mail to Justin Luth (justin_luth@sil.org).
I wanted to add him to CC list, but it doesn't work.

That is true it is about 3~5 second than the page count is actual. But works correctly.
Comment 6 Telesto 2020-12-24 20:50:46 UTC
(In reply to Martin Srdoš from comment #5)
> I am sending mail to Justin Luth (justin_luth@sil.org).
> I wanted to add him to CC list, but it doesn't work.

Added. However it's about a commit from Michael Stahl 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=22355042a6fc7aecf3caab69b3fa3be1430b697f
Comment 7 Justin L 2020-12-25 10:06:39 UTC
There are two issues at stake here with Page 2 of 1.
I confirmed the LO 4.3 bibisect of when Page 1 turned into Page 2, at
commit 22355042a6fc7aecf3caab69b3fa3be1430b697f
Author: Michael Stahl on Wed Dec 18 00:12:09 2013 +0100    
        fdo#72452: ODF import/export: fix handling of style:page-number
    
        Class XMLNumberWithAutoInsteadZeroPropHdl (which appears to be used only
        for this attribute) needs to be adapted to the change that
        "PageNumberOffset" value 0 is no longer invalid; use "void" value for
        invalid instead, which appears more appropriate anyway.
    
        Unfortunately the type of style:page-number is positiveInteger so
        writing 0 would be invalid; write "auto" instead for now.


There may be some strange things going on that I don't know about, but a First Page style doesn't indicate in any way that it is not page 1. Just because it doesn't print a page number in a footer doesn't mean it isn't counted as a page.
If the user wants to restart page numbering at some point, that is done via page-break-with-style-with-page-number.

So I don't see any bug with this "Page 2" or Michael's commit.
Comment 8 Justin L 2020-12-25 11:05:25 UTC
The second issue is "of 1". However, that is not the normal "Page Count" variable that one would expect to be used in this case. It is some "End of Document" marker.

This was fixed in LO 4.4 - so that it immediately showed "of 2" with
commit cd94a84b89c476760ad74bf088a5d6f8ba4ce209
Author: Oliver-Rainer Wittmann on Fri Jun 13 20:32:14 2014 +0200    
        125044: - use field's content cache on <SwTxtFld> construction only    
        ... for clipboard documents
    
        - assure invalidation and updates on code to update fields


It was broken again in LO 5.1 (for which on Linux I only have the ability to bibisect to a one day range) by one of these https://cgit.freedesktop.org/libreoffice/core/log/?id=22355042a6fc7aecf3caab69b3fa3be1430b697f&qt=range&q=a3050f632517137f809d76662170726b518f043a..5a61d7f049a81d6e747d9d097f364ae45f58697b

Perhaps a Windows person can verify with their bibisect, but I highly suspect author	Ashod Nakashian on 2015-07-15 07:46:01 +0000
commit	b0fde7a912ff3aa370496802f20895b1158b072c
> tdf#38837 Reduce power consumption by minimizing idle timers
> Both the document statistics- and state-manager have their
> own modified flags. There is a cyclic dependency between the
> the two in that updating the document's statistics also marks
> the document as modified. Of course when a document is edited
> the statistics modified flag is set to trigger an update.
> 
> To avoid a perpetual cycle, the statistics manager resets the
> document's modified state to that before setting the new
> statistics. However, this doesn't reset the statistics
> modified flag, which was set when the document was modified
> by setting the new statistics. Hence, the statistics thinks
> there are modifications in the document when there isn't.
> 
> This patch is to make DocumentStateManager::ResetModified()
> symmetrical to DocumentStateManager::SetModified() by
> reseting the modified flag of the statistics manager.
> 
> The idle CPU drops to nil on unmodified documents after this.
> However, for modified documents the statistics is recalculated
> perpetually until the document is saved. This will need a
> different patch to fix.

That makes sense with what we are seeing. Any modification causes the End of Document field to update itself. For example, printing or exporting to PDF also update the field. So I'd say this part is a rather minor irritant.

Also, it is hard to reproduce. Adding a third page "fixes" the problem.
Comment 9 Alan Robinson 2020-12-25 11:21:57 UTC
It is not true that the only way the user can control page numbers is to use a page break with page number.

Clicking Format->Title Page launches the Title page dialogue box which includes a check box, 'Reset page numbering after title pages'. In my document this is checked, and the next page number is set to 1.

The problem is that on opening the document, these settings are not applied. But if you open the dialogue box then close it again without changing anything it is applied. It has to be done every time the document is opened.

Regards, Alan R.
Comment 10 Justin L 2020-12-25 11:23:03 UTC
(In reply to Justin L from comment #7)
> There may be some strange things going on that I don't know about,
Umm yeah. I totally missed seeing any reference to Format - Title page. I've never used or noticed that before.
Comment 11 Alan Robinson 2020-12-25 11:27:15 UTC
I had problems with the page count: it appears to be a count of the total number of pages regardless of whether they are included in the page numbering. To get round this, the final field in the footer in the submitted document is a reference to a bookmark at the end of the text.

Regards, Alan R.
Comment 12 Justin L 2020-12-25 11:48:56 UTC
(In reply to Alan Robinson from comment #11)
> I had problems with the page count: it appears to be a count of the total
> number of pages regardless of whether they are included in the page
> numbering. To get round this, the final field in the footer in the submitted
> document is a reference to a bookmark at the end of the text.
Yes, this seems like a good, proper solution. It looks to me like the "of 1" is the cached value (it is written into the ODT) so that is what is displayed until an edit updates the field content.
Comment 13 Justin L 2020-12-25 11:50:29 UTC
(In reply to Alan Robinson from comment #9)
> It is not true that the only way the user can control page numbers is to use
> a page break with page number.
This looks like a wizard that does what I was mentioning about page-style-with-page-number. The problem is that the wizard seems to not work when there is a page break already. So a work-around is to remove the page break first and then do it again.

Format-Title page is already broken in this was as far back as I can test - LO 3.5.

I'll start looking into the code to see why an existing RES_BREAK is preventing it being replaced by a RES_PAGEDESC.
Comment 14 Justin L 2020-12-25 18:43:06 UTC
Created attachment 168489 [details]
titlePage.odt: run format-titlePage twice and first-page's page number changes

Format->Title Page is basically just broken. (sw/source/ui/misc/titlepage.cxx)

1.) GotoPage fails if a blank page exists. [first and follow are both even or both odd]. The result is changes get applied to "random" pages.
2.) GotoPage( bRecord=false ) BY DEFINITION returns false, yet when adding more than one index page, it hopes it will return true before setting the page style.
3.) The wrong pages get changed to Index style. [Apparently layout hasn't recognized the newly added pages yet because I can't access any page higher than 3.]

Well obviously GotoPage is completely worthless if it doesn't even recognize the newly added pages. So if ANYTHING at all works in this wizard, it is just a coincidence... sigh.
Comment 15 Alan Robinson 2020-12-25 23:07:05 UTC
There is therefore an obvious workaround: I have abandoned using the wizard and am now using a manual page break instead. It appears to work.

Regards, Alan R.
Comment 16 Justin L 2020-12-26 10:49:52 UTC
Proposed fix that allows Title Page wizard to be re-run multiple times, and that forces a page style break to accompany a restarted page number can be found at http://gerrit.libreoffice.org/c/core/+/108322.

This will fix OP's problem where "Page 2" returned on fileopen, even though the wizard had set "restart numbering on page 2" it to one.
Comment 17 Justin L 2020-12-26 17:33:46 UTC
Two more proposed patches related in general to this title page.
-http://gerrit.libreoffice.org/c/core/+/108331 NFC sw dialog titlepage.cxx: general code cleanup
-http://gerrit.libreoffice.org/c/core/+/108332   sw TitlePageDlg: enable insert after last page
Comment 18 Commit Notification 2020-12-29 15:39:56 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ccfd8e9d09f9ac0a0ea92d0f378391006faaf934

tdf#138907 sw TitlePageDlg: fix round-tripping

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Kevin Suo 2020-12-30 01:06:19 UTC
Just for the record, there is a similar ticket in the Chinese LibreOffice discussion forum reported some days ago:
https://bbs.libreofficechina.org/thread-2649-1-1.html

And I see it is identical to this bug report.

Justin: it is possible to backport commit ccfd8e9d09f9ac0a0ea92d0f378391006faaf934 to at least branch 7.1, as this is a regression and causes users not able to set page-number-reset of Title Page under this situation?
Comment 20 Justin L 2020-12-30 06:17:15 UTC
(In reply to Kevin Suo from comment #19)
> Justin: it is possible to backport as this is a regression?
Well, this isn't actually a regression, so I'm removing that from the report, but I'm OK with backporting this first patch to 7.1.

There still is a ridiculously large amount of other problems remaining with this title page wizard that I don't intend to backport though.
Comment 21 Martin Srdoš 2020-12-30 09:14:42 UTC
After open document it is same. On the second page I still see that I am on page 2 of 1.
But after again setting the title page, it works good, I think.
Alan should check it also.

With bisecting I was checking only the pages after opening document. And this behavior is still same.
Comment 22 Martin Srdoš 2020-12-30 09:38:12 UTC
Try to do this:
1) Open new writer document
2) to header insert - page number and insert - field - page count. Like "page number" of "page count"
3) by ctrl+enter make more pages, in my example in print screen it is 5 pages
4) go to format - title page. Check "Reset pagee numbering after title pages" and set it to 1
5) Then you can see that page number is ok. After title page is page 1 and so. But count page is counts one page more.
Comment 23 Martin Srdoš 2020-12-30 09:42:23 UTC
Created attachment 168569 [details]
Title page - setting and behavior

This is print screen of my work. There is current page and page count in header, settings of setting title page (I just select the "Reset numbering after title page") and left down is counting pages in status bar.
Comment 24 Alan Robinson 2020-12-30 09:45:27 UTC
(In reply to Martin Srdoš from comment #21)
> After open document it is same. On the second page I still see that I am on
> page 2 of 1.
> But after again setting the title page, it works good, I think.
> Alan should check it also.
> 
This is the behaviour I first discovered and reported, so it looks like that problem hasn't been fixed yet.

There's no need even to enter info into the wizard. Just Format->Title Page and OK does it.

Since finding out this feature is just a wizard I abandoned using it and use a manual page break instead.
Comment 25 Alan Robinson 2020-12-30 09:47:49 UTC
(In reply to Martin Srdoš from comment #22)
....
> 5) Then you can see that page number is ok. After title page is page 1 and
> so. But count page is counts one page more.

The page count is the total number of pages in the document. See my comment 11.
Comment 26 Justin L 2021-01-02 13:46:43 UTC
(In reply to Martin Srdoš from comment #22)
> 5) But count page is counts one page more.
Even though you only see 5 pages in your screenshot, there really are six pages. If you switch into book view, then you will notice a "blank page" for left side, even page 2. That's because you started what you consider the second page to have an odd number, so the computer has to force an empty page to keep the odd number on a right-side page.

So there is nothing wrong with what is happening here.
Comment 27 Justin L 2021-01-02 13:51:38 UTC
(In reply to Martin Srdoš from comment #21)
> After open document it is same. On the second page I still see that I am on
> page 2 of 1.
I have absolutely no intention of trying to "fix" the initial opening of the document. Nor is there much value in doing so. The first edit will automatically fix it, and a subsequent save will also save the new page number and the problem will "go away".

The fix in comment 18 should prevent this from occurring in new documents.
Comment 28 Alan Robinson 2021-01-03 23:18:58 UTC
There may be value in either fixing it, or making changes elsewhere.

If I open the document then export it as a PDF, the exported page numbers are wrong. It says "Page 2 of 2".

Format->Title Page followed by OK and a second export gives "Page 1 of 1".

Forgetting to correct the page numbering before exporting is too easy a mistake to make.

I haven't tried downloading the patch to see if the PDF export problem still exists in that.
Comment 29 Commit Notification 2021-01-04 11:04:16 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/4f7d5b0ed8df89dec6cc2ae45be5885f5f4ebae6

tdf#138907 sw TitlePageDlg: fix round-tripping

It will be available in 7.1.0.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 30 Martin Srdoš 2021-01-06 12:46:54 UTC
(In reply to Justin L from comment #26)
> (In reply to Martin Srdoš from comment #22)
> > 5) But count page is counts one page more.
> Even though you only see 5 pages in your screenshot, there really are six
> pages. If you switch into book view, then you will notice a "blank page" for
> left side, even page 2. That's because you started what you consider the
> second page to have an odd number, so the computer has to force an empty
> page to keep the odd number on a right-side page.
> 
> So there is nothing wrong with what is happening here.

Isn't it also bug, when there is the blank page? Don't you know who should look at this issue? QX?

Thank you for your time.
Comment 31 Justin L 2021-01-06 12:50:43 UTC
(In reply to Martin Srdoš from comment #30)
> Isn't it also bug, when there is the blank page?
No, this is definitely not a bug. The key to understand is that documents/page numbering are connected to the book standard where odd page numbers on are the right side of the book, and even numbers on on the left side of the book.
Comment 32 Alan Robinson 2021-01-06 13:36:04 UTC
(In reply to Justin L from comment #31)

> No, this is definitely not a bug. The key to understand is that
> documents/page numbering are connected to the book standard where odd page
> numbers on are the right side of the book, and even numbers on on the left
> side of the book.

I'd echo that. But it does seem to me there may be cases where the user might want to override this. A document option to apply the rule or not (default = apply) would achieve that.

But that's a feature request, not a bug report.

Regards, Alan R.
Comment 33 Commit Notification 2021-01-21 08:21:09 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/22ee887346ef870fbf9b758fe2bcaa9aeae04a82

tdf#138907 sw TitlePageDlg: Goto correct (existing) page

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 34 Commit Notification 2021-01-27 12:01:51 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a9fb193b1dce89e45522e2c68b1b839017facea8

tdf#138907 sw TitlePageDlg: Goto correct (inserted) page

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 35 Justin L 2021-01-27 12:52:20 UTC
(In reply to Justin L from comment #14)
> Format->Title Page is basically just broken.
I think I have completely fixed the Format - Title Page wizard. If someone is willing to put it through its paces and report back, that would be great.

It inserts the correct number of pages in the correct position.  (Note - I have ADDED a content page as well as the requested title pages if the inserted pages are done at end of the document.)

It assigns the "First page", "Index page", and "Default page" styles to the correct pages.

It clears any "restart numbering" from all the Index pages, and sets the requested page number on the title page and the first content page.

These values are all saved properly.


Please note that these fixes only apply to new changes. It has no effect on whatever happened with past documents created by the wizard.
Comment 36 Timur 2021-05-12 13:28:28 UTC
*** Bug 140433 has been marked as a duplicate of this bug. ***
Comment 37 Timur 2021-05-12 13:33:20 UTC
*** Bug 35136 has been marked as a duplicate of this bug. ***