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
Created attachment 168158 [details] Document demonstrating problem
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.
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.
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]
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 22355042a6fc7aecf3caab69b3fa3be1430b697f source 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.
(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
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.
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.
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.
(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.
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.
(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.
(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.
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.
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.
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.
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
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.
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?
(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.
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.
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.
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.
(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.
(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.
(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.
(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.
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.
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.
(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.
(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.
(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.
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.
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.
(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.
*** Bug 140433 has been marked as a duplicate of this bug. ***
*** Bug 35136 has been marked as a duplicate of this bug. ***