First, sorry if I don't have the good english term, I use the french version of LibreOffice. Now the bug: When you want to have a page number on your page, and put a "correction" (for begin to count at number 3 on the first page of the document for exemple), after the page N, there is no more number on the page. The number N = the number of page of the document. Example: You have a document of 10 pages. Normal numerotation is : 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10(*) If you made a correction of 2 pages, the new numerotation should be : 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12 But with the bug you have: 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10(*) - x - x (*) Same number As you see, the last number is the number of page of the document (stop here to 10). Hope you'll correct it for next version. Thanks. (This bug has be test on MacOS X and Linux (x86)).
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
not reproduced. WFM
I just reproduced it on LibreOffice 3.6.0.4. Steps: - Open or create a document with multiple pages (for example, 10 pages) - Create a footer - Go to the footer, and in the menu 'Insert' / 'Fields' / 'Page Number' Now you have pages from 1 to 10 - Double-click on the page number in the Footer, to have the window 'Edit Fields: Document' - The offset is to 0. Write 2 (to began first page of the document with Number 3) Now what I should have: page number from 3 to 12. BUT what I really have: page number from 3 to 10, and the last two pages without number.
Hi! I set version to the oldest versin where the error occured... @Roman: could you please test it....
Created attachment 66349 [details] Sample file for bug 53694, after setting the logical page number of the 1st page to "3" (In reply to comment #8) > @Roman: could you please test it.... I have tried to do so, but I can NOT reproduce this issue on MacOS X 10.6.8 (Intel), neither with LibreOffice 3.5.6.2 nor with LibreOffice 3.6.1.2. Let me first introduce a bit of terminology, to make it easier to distinguish the two kinds of page numbers which are involved in this issue: * by "physical" page (number), I mean the counting of all pages, starting with 1 for the 1st page; * by "logical" page (numerb), I mean the page number as displayed by LibreOffice when you choose "Insert > Fields > Page number", and which can be changed, e.g. to begin at "3" instead of "1", just like in Guillaume’s bug description. Guillaume did not provide a sample file (this is probably one of the reasons why nobody has tested or confirmed this issue until now; making your own sample file for every bug report is rather time-consuming ;-). So I had to make up my own. You will find it attached to this comment. I have already change the logical page number of the 1st (physical) page to "3" via inserting a page break before the 1st paragraph and, while doing so, given the command to start page counting at "3" (menu: "Insert > Manual Break ...", type: page break with change of page style to "Standard", checked "Change page number", value: "3".) But as you can see from the sample file, the logical page numbering is completely correct: physical page no. 1 2 3 ... 8 9 10 11 logical page no. 3 4 5 ... 10 11 12 13 So everything works as expected for me. But nevertheless it is possible that the bug still exist, maybe Guillaume is just doing something in a different way ... -> We need to find out what makes the difference! @ Guillaume: * If you open my sample file and inspect the (logical) page numbers, which appear both in the text and in the footer of every page: are they correct on your machine, or do you see wrong numbers after (logical) page 10 or 11? * Did you do something in another way than me -- e.g., how exactly did you "made a correction of 2 pages"? * In what file format is the document in which you experienced the problem -- .odt, or .doc, or ... ? * Can you create a simple sample file which shows the problem? This would be the best way to reproduce the issue. Just attach a simple sample file to this bug report, and I will be happy to test (and confirm) the issue.
Created attachment 66350 [details] PDF created from my sample file, to demonstrate that the logical page numbers are correct I attach an additional PDF file created from my sample file. Unlike in the .odt file, the logical page numbers are just plain text in the PDF file, therefore they are displayed in the same way on every machine, and therefore the PDF file demonstrates in an immutable way that/how the page numbering works for me correctly.
(In reply to comment #9) > Created attachment 66349 [details] > Sample file for bug 53694, after setting the logical page number of the 1st > page to "3" Sorry -- It is terrible to be always in a hurry: the file names of my sample files (.odt as well as .pdf) both speak about "bug 53694", but this is just a typo, the first two numbers are interchanged; I really mean "bug 35694", i.e. the present one.
Thanks Roman for your reply. I test your file and I haven't bug with, logical number is ok. But I create myself a document, with the bug on my computer. Steps are the same as I write this morning. I think the problem is that I use Offset. When I try your method, it's working, but I always have a first page with logical number 1. I send the file with bug in next comment, and send it in PDF if you don't have bug on your computer.
Created attachment 66371 [details] The ODT file with logical bug number
Created attachment 66372 [details] The result on my computer : pages number 3->10 and 2 pages without logical number
Thanks for bugreport and sorry for not understand from first attempt Reproduced in 3.3.4 and 3.6.1 on Fedora 64 bit IMHO usually users apply negative numbers for remove page number from title page. May be developers thought that positive offset needed for deleting page numbers from documents where title page placed at the end of document.
@Guillaume: Thank you very much for your example document! A simple sample document like this one, simplified to the minimum which is necessary to show the bug, is always a great help ... Using Guillaume's sample file, this bug is also REPRODUCIBLE on Mac OS X 10.6.8 (Intel) with * LibreOffice 3.3.0 (**) * LibreOffice 3.4.6 * LibreOffice 3.5.6.2 (Build-ID: e0fbe70-dcba98b-297ab39-994e618-0f858f0) * LibreOffice 3.6.1.2 (Build ID: e29a214) * LOdev 3.7.0.0.alpha0+ (Build ID: 3e9f9e5; pull time: 2012-08-27 05:09:55) * ApacheOpenOffice (AOO) 3.4.0 (AOO340m1, Build:9590) - Rev. 1327774 (***) (**) (***) This implies that this bug was inherited from OOo. -> Adapting Version information (the Version field should always contain the number of the first version in which the bug appeared).
There is the same bug https://bugs.freedesktop.org/show_bug.cgi?id=50061 Please check example file from it.
*** Bug 50061 has been marked as a duplicate of this bug. ***
*** Bug 51005 has been marked as a duplicate of this bug. ***
LibreOffice not gave me page number.
Lowerings severity. This devinitely is no blocker BTW: have you tried it with a fresh user profile...?
Confirming the bug in LibO 4.2.4.2. Actually, I was planning to open a bug report about it but then I found this one. Steps to reproduce: - insert a page number field - select it, right-click on it and select "Fields" - set "offset" to something >0 - page numbering stops when the number reaches the total number of pages in the document For instance, if your document has 10 pages and you set offset to 5, your 1st page will get number 6, ...., your 5th page will get number 10, and pages 6 to 10 will get no number. This is even more obvious when you set the offset to something higher than the actual page count: the page numbering field just shows nothing, on any page.
Sorry, I forgot to mention I'm using Win 7 x64
Confirming the bug in LibO 4.0.3.3. Actually, I was planning to open a bug report about it but then I found this one.
Please don't change the importance/priority. Thanks
*** Bug 64958 has been marked as a duplicate of this bug. ***
*** Bug 80625 has been marked as a duplicate of this bug. ***
*** Bug 67083 has been marked as a duplicate of this bug. ***
There is an interesting point about the behaviour required by the OpenDocument specification in bug 67083 comment 12 (even though it still seems wrong) To quote: <quote> 19.845.2 <text:page-number> The text:page-adjust attribute specifies an adjustment of the value of a page number field, in order to display of page numbers of following or preceding pages. The specified value is added to the current page number. If a page with the resulting page number does not exist, no number is displayed. </quote> http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1419094_253892949
(In reply to Matthew Francis from comment #29) > ... behaviour required by the OpenDocument specification > (even though it still seems wrong) > <quote> > 19.845.2 <text:page-number> > The text:page-adjust attribute specifies an adjustment of the value of a > page number field, in order to display of page numbers of following or > preceding pages. The specified value is added to the current page number. If > a page with the resulting page number does not exist, no number is displayed. > </quote> Actually, I filed the same bug years ago against OOo 1.0 or 1.1 under another name and was told by the developers then that this was a WONTFIX bug. If it IS as per specification - and the specification seems very wrong if it is - wouldn't it make sense to remove the feature altogether instead of frustrating users who can't make it work? There is a nice workaround: 1. go to "Insert" menu 2. Pick "manual break" 3. Choose "page break" 4. Choose a page template 5. Choose a page number and check "Change page number" With this workaround, the feature (that doesn't work anyway, or only works for frankly unsatisfactory values of "work"), the feature won't be missed. If the workaround is well enough documented and indexed in the online help, it can also be easily found.
Today, I've been bitten by this bug on a machine with OOo 3.3 installed, so changing earliest version to "Inherited from OOo". I think that this bug should be fixed despite the workaround given in the previous comment, because it may not be uncommon to split up larger documents in smaller ones for easier editing, thus needing positive offsets for the page numbers when the whole document shall be printed.
*** Bug 86728 has been marked as a duplicate of this bug. ***
I can confirm this bug on LibreOffice 5.1.3.2. This may be "intended behavior", although a slight change to the feature would make it much more usable. As it stands, I think we can consider it a "misfeature". CURRENT BEHAVIOR: After applying offset, any page that would have an offset number > actual number of pages has an empty field. EXPECTED BEHAVIOR: When most people apply an offset, they expect for the counting to begin at the specified number and continue *ad infinitum*. Thus, on a three-page document, with a page number autofield in the footer with an offset of 20 would number the pages "20, 21, 22". USE CASE: As an author, I frequently need to isolate a portion of a document for others to review, but want to maintain the page numbers so I know where in the larger document the change should be made. This is trivial on Microsoft Word, but decided non-trivial on LibreOffice. Fixing this mis-feature would make the process considerably more obvious and easier to use. FIX: Don't stop incrementing on offset page numbers for anything.
After isolating the problem in the code, I'm going to attempt to fix this. I'll place it up for grabs again in the off-chance that I fail.
DEV NOTE: This bug was rooted in a third part of this conditional statement on sw/source/core/fields/docufld:120: if (0 > nTmp || SVX_NUM_NUMBER_NONE == nTmpFormat) | (!bVirtual && nTmp > nMaxPage) If the offset page number was greater than the actual number of pages, then everything comes down to bVirtual, which was in turn set by `SwPageNumberFieldType::SwPageNumberFieldType::Expand()`. This was why the historic workaround for the bug worked - it forced Expand() to raise bVirtual.
Proposed Patch: https://gerrit.libreoffice.org/#/c/25529/
There is nothing to fix. The current behavior of "offset" is correct. If you want to start your document with a different number than 1, the correct way is to set the desired number in the paragraph, which contains the page break. But the explanation of the behavior of "offset" in the documentation needs to be improved.
(In reply to Regina Henschel from comment #37) > There is nothing to fix. The current behavior of "offset" is correct. If you > want to start your document with a different number than 1, the correct way > is to set the desired number in the paragraph, which contains the page break. > > But the explanation of the behavior of "offset" in the documentation needs > to be improved. I have to *strongly* disagree. LibreOffice is unique in its definition of "offset" - anyone coming from Microsoft Word or another program is going to expect the behavior I outlined. The old behavior lends no benefit to the user, whereas the new behavior does. It's a basic principle of software design: if many users are confused, that doesn't mean the documentation needs to be updated, it means the design needs to be updated.
The specification is very clear: "19.845.2<text:page-number> The text:page-adjust attribute specifies an adjustment of the value of a page number field, in order to display of page numbers of following or preceding pages. The specified value is added to the current page number. If a page with the resulting page number does not exist, no number is displayed." And here the text from ODF 1.1 page 103 "Page Adjustment The value of a page number field can be adjusted by a specified number, allowing the display of page numbers of following or preceding pages. The adjustment amount is specified using the text:page-adjust attribute. When this attribute is used, the application: 1.Adds the value of the attribute to the current page number. 2.Checks to see if the resulting page exists. 3.If the page exists, the number of that page is displayed. 4.If the page does not exist, the value of the page number field remains empty and no number is displayed." If we wanted another behavior than specified, it would need an own loext- attribute. I have seen now, that the documentation has already a warning, look at item "Offset" in topic "Edit Fields". But a sentence similar to "If a page with the resulting page number does not exist, no number is displayed." from the spec should be added. Perhaps the UI needs improvement, to prevent users from using "offset" for a purpose it is not designed for.
(In reply to Regina Henschel from comment #39) > The specification is very clear: > "19.845.2<text:page-number> > The text:page-adjust attribute specifies an adjustment of the value of a > page number field, in order to display of page numbers of following or > preceding pages. The specified value is added to the current page number. If > a page with the resulting page number does not exist, no number is > displayed." > > And here the text from ODF 1.1 page 103 > "Page Adjustment > The value of a page number field can be adjusted by a specified number, > allowing the display of page numbers of following or preceding pages. The > adjustment amount is specified using the text:page-adjust attribute. When > this attribute is used, the application: > 1.Adds the value of the attribute to the current page number. > 2.Checks to see if the resulting page exists. > 3.If the page exists, the number of that page is displayed. > 4.If the page does not exist, the value of the page number field remains > empty and no number is displayed." > > > If we wanted another behavior than specified, it would need an own loext- > attribute. > > > I have seen now, that the documentation has already a warning, look at item > "Offset" in topic "Edit Fields". But a sentence similar to "If a page with > the resulting page number does not exist, no number is displayed." from the > spec should be added. > > Perhaps the UI needs improvement, to prevent users from using "offset" for a > purpose it is not designed for. I still believe the feature, and apparently the spec, need to be revisited, based on nearly a decade of user complaints. We really should find out what the logic was behind that element of the specification, as again, it does not appear to have a use case. If it does turn out to be either arbitrary or misguided, it needs to be revised. However, if it does have a good reason, then I would be all for adding an additional property to page numbers to allow for this sort of behavior. Starting page numbers on a custom number on a single-style document should *not* be this complicated.
Just a fly-by observation, the page offset works correct if page numbers are actually created the way they are supposed to and not just placed on the wild meadow of a footer, i.e. defined in the paragraph style of the first paragraph of the page. Page number settings are always anchored to the first paragraph. The offset number is a display feature.
*** Bug 100536 has been marked as a duplicate of this bug. ***
Created attachment 126209 [details] Yet Another Sample File Reproduced in LibreOffice 4.3.3.2 430m0(Build:2) on Debian. Attached sample file with instructions to reproduce. Page number fields with offsets greater than number of pages in the document appear as blank fields. Sometimes. Actually, it’s unclear what the pattern is. Sometimes they’re filled out, sometimes blank. The point of the offset is to let you create a document with page numbers that start at a high number. For example, a document of attachments that will be stapled to a government form, where the page number on the document should start at one greater than the number of pages on the form. This is an EXTREMELY USEFUL feature and should be included. From the perspective of KISS in programming, the calculation of an offset page number should be as simple as possible: the current page number plus the offset value of the field. Bringing in an extra atom of information about how many pages the document currently has adds unnecessary complexity and does not DWIM.
*** Bug 100997 has been marked as a duplicate of this bug. ***
This is a very annoying bug that was reported 6 years ago. Is someone working on it ?
It is not a bug, but the specified behavior. Please use a forum or mailing list to get help how to start a document with a number other than 1.
More like "specified bug" - for anyone reading this, I did fix this, but the change was rejected because the behavior is specified. Someone (anyone?) is going to have to find out how to contact the board that wrote the spec and ask them to reconsider - no one has yet been able to demonstrate a use case for this behavior.
(In reply to Jason C. McDonald from comment #47) > More like "specified bug" - for anyone reading this, I did fix this, but the > change was rejected because the behavior is specified. Someone (anyone?) is > going to have to find out how to contact the board that wrote the spec and > ask them to reconsider - no one has yet been able to demonstrate a use case > for this behavior. I demonstrated a very useful use case for fixing it. The example is to create additional pages to be stapled onto the end of a government form. Say the form has pages 1 to 4, but it says "insert additional pages if needed." The subsequent pages should be numbered from an offset of 4, starting at 5. Currently, the only way to achieve this, is to create a document with 4 blank pages at the beginning, and only print from page 5 onward. This is what the whole notion of page number offset is for. You're right, no one has demonstrated a use case for the current specified behavior, because it does not make sense. How does one contact the board? Or the engineering steering committee?
(In reply to Mark Hedges from comment #48) > I demonstrated a very useful use case for fixing it. Oh, yes, I didn't mean that there wasn't one for the desired behavior. I mean, there isn't a use case for the CURRENT behavior. > How does one contact the board? Or the engineering steering committee? I wish I knew.......
(In reply to Jason C. McDonald from comment #49) > > How does one contact the board? Or the engineering steering committee? > > I wish I knew....... One looks up their e-mails individually. Which I did. Not that I need this actively anymore... that ship has sailed. Happy to help. -Mark
(In reply to Jason C. McDonald from comment #47) > More like "specified bug" - for anyone reading this, I did fix this, but the > change was rejected because the behavior is specified. Someone (anyone?) is > going to have to find out how to contact the board that wrote the spec and > ask them to reconsider - no one has yet been able to demonstrate a use case > for this behavior. That's not completely true. The patch was abandoned due to a lack of work. Please see last comment in https://gerrit.libreoffice.org/#/c/25529/. You can reopen it at any time, and bear in mind comment 39 and comment 41
(In reply to Xisco Faulí from comment #51) > (In reply to Jason C. McDonald from comment #47) > > More like "specified bug" - for anyone reading this, I did fix this, but the > > change was rejected because the behavior is specified. Someone (anyone?) is > > going to have to find out how to contact the board that wrote the spec and > > ask them to reconsider - no one has yet been able to demonstrate a use case > > for this behavior. > > That's not completely true. The patch was abandoned due to a lack of work. > Please see last comment in https://gerrit.libreoffice.org/#/c/25529/. You > can reopen it at any time, and bear in mind comment 39 and comment 41 I'm afraid you misunderstood both comments. This isn't "lack of work" - comment 39 outlined the necessary discussion involved in revising the spec (which I already stated was the blocking factor), and comment 41 was suggesting an *alternative* change. As far as fixing *this* behavior, my fix was indeed complete. The adjusted behavior was rejected because the original offset behavior as described in the bug report was in the spec.
*** Bug 112058 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The help has been changed in the meantime, tested with LO 5.4. In /text/swriter/01/04090004.xhp, title DocInformation "With an Offset value of 1, the field will display a number that is 1 more than the current page number, but only if a page with that number exists. On the last page of the document, this same field will be empty." /text/swriter/01/02140000.xhp, title Edit Fields "If you want to change the actual page number and not the displayed number, do not use the Offset value. To change page numbers, read the Page Numbers guide." In /text/swriter/01/04090001.xhp, title Document "If you want to change the actual page number and not the displayed number, do not use the Offset value. To change page numbers, read the Page Numbers guide." If you find a place, where the help can be improved in regard to using Offset for page numbers, please write a new bug report. The behavior is as specified, the help is correct now. Nothing to do.
