Bug 35694 - "Page number" automatic field stops counting before last page if offset >0 (see comment 22)
Summary: "Page number" automatic field stops counting before last page if offset >0 (s...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL: http://docs.oasis-open.org/office/v1....
Whiteboard:
Keywords: needsUXEval
: 50061 51005 64958 67083 80625 86728 100536 100997 112058 114071 131194 133466 144987 148187 149479 153811 154928 (view as bug list)
Depends on:
Blocks: Fields-Page-Number
  Show dependency treegraph
 
Reported: 2011-03-26 07:44 UTC by Guillaume
Modified: 2024-03-26 19:29 UTC (History)
33 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample file for bug 35694, after setting the logical page number of the 1st page to "3" (9.47 KB, application/3dr)
2012-08-30 16:23 UTC, Roman Eisele
Details
PDF created from my sample file, to demonstrate that the logical page numbers are correct (34.46 KB, application/pdf)
2012-08-30 16:26 UTC, Roman Eisele
Details
The ODT file with logical bug number (9.15 KB, application/vnd.oasis.opendocument.text)
2012-08-30 20:01 UTC, Guillaume
Details
The result on my computer : pages number 3->10 and 2 pages without logical number (28.76 KB, application/pdf)
2012-08-30 20:01 UTC, Guillaume
Details
Yet Another Sample File (34.49 KB, application/vnd.oasis.opendocument.text-flat-xml)
2016-07-14 20:37 UTC, Mark Hedges
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Guillaume 2011-03-26 07:44:50 UTC
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)).
Comment 1 Björn Michaelsen 2011-12-23 11:51:18 UTC Comment hidden (obsolete)
Comment 2 Florian Reisinger 2012-08-14 14:03:15 UTC Comment hidden (obsolete)
Comment 3 Florian Reisinger 2012-08-14 14:04:10 UTC Comment hidden (obsolete)
Comment 4 Florian Reisinger 2012-08-14 14:08:42 UTC Comment hidden (obsolete)
Comment 5 Florian Reisinger 2012-08-14 14:10:44 UTC Comment hidden (obsolete)
Comment 6 sasha.libreoffice 2012-08-30 11:47:18 UTC
not reproduced. WFM
Comment 7 Guillaume 2012-08-30 15:23:54 UTC
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.
Comment 8 Florian Reisinger 2012-08-30 15:29:14 UTC Comment hidden (obsolete)
Comment 9 Roman Eisele 2012-08-30 16:23:55 UTC
Created attachment 66349 [details]
Sample file for bug 35694, 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.
Comment 10 Roman Eisele 2012-08-30 16:26:21 UTC
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.
Comment 11 Roman Eisele 2012-08-30 16:55:31 UTC Comment hidden (obsolete)
Comment 12 Guillaume 2012-08-30 20:00:16 UTC
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.
Comment 13 Guillaume 2012-08-30 20:01:00 UTC
Created attachment 66371 [details]
The ODT file with logical bug number
Comment 14 Guillaume 2012-08-30 20:01:59 UTC
Created attachment 66372 [details]
The result on my computer : pages number 3->10 and 2 pages without logical number
Comment 15 sasha.libreoffice 2012-08-31 05:33:53 UTC
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.
Comment 16 Roman Eisele 2012-08-31 08:10:33 UTC
@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).
Comment 17 Maks 2012-11-06 22:54:37 UTC
There is the same bug https://bugs.freedesktop.org/show_bug.cgi?id=50061
Please check example file from it.
Comment 18 Maks 2012-11-06 22:56:55 UTC
*** Bug 50061 has been marked as a duplicate of this bug. ***
Comment 19 Maks 2012-11-06 22:57:39 UTC
*** Bug 51005 has been marked as a duplicate of this bug. ***
Comment 20 Christian Tillinger 2013-02-12 13:22:10 UTC
LibreOffice not gave me page number.
Comment 21 Florian Reisinger 2013-02-12 18:33:22 UTC Comment hidden (obsolete)
Comment 22 patheticcockroach 2014-05-11 15:23:18 UTC
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.
Comment 23 patheticcockroach 2014-05-11 15:24:57 UTC Comment hidden (obsolete)
Comment 24 Owyn 2014-06-10 10:14:10 UTC
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.
Comment 25 Joel Madero 2014-06-26 01:29:58 UTC Comment hidden (obsolete)
Comment 26 Matthew Francis 2015-01-21 10:18:54 UTC
*** Bug 64958 has been marked as a duplicate of this bug. ***
Comment 27 Matthew Francis 2015-01-21 10:19:29 UTC
*** Bug 80625 has been marked as a duplicate of this bug. ***
Comment 28 Matthew Francis 2015-01-21 10:21:59 UTC
*** Bug 67083 has been marked as a duplicate of this bug. ***
Comment 29 Matthew Francis 2015-01-21 10:25:28 UTC
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
Comment 30 G.Ostner (LOBugs) 2015-04-15 16:15:21 UTC
(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.
Comment 31 Jens Mildner 2015-08-30 21:25:27 UTC
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.
Comment 32 Buovjaga 2015-08-31 10:18:27 UTC
*** Bug 86728 has been marked as a duplicate of this bug. ***
Comment 33 Jason C. McDonald 2016-05-25 19:30:53 UTC
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.
Comment 34 Jason C. McDonald 2016-05-25 21:55:51 UTC Comment hidden (obsolete)
Comment 35 Jason C. McDonald 2016-05-28 16:54:17 UTC
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.
Comment 36 Jason C. McDonald 2016-05-29 18:23:45 UTC
Proposed Patch: https://gerrit.libreoffice.org/#/c/25529/
Comment 37 Regina Henschel 2016-05-29 23:26:53 UTC
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.
Comment 38 Jason C. McDonald 2016-05-29 23:30:21 UTC
(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.
Comment 39 Regina Henschel 2016-05-30 09:29:18 UTC
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.
Comment 40 Jason C. McDonald 2016-05-30 15:16:52 UTC
(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.
Comment 41 Eike Rathke 2016-06-10 12:54:14 UTC
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.
Comment 42 Daniël van Vuuren 2016-06-23 10:01:11 UTC
*** Bug 100536 has been marked as a duplicate of this bug. ***
Comment 43 Mark Hedges 2016-07-14 20:37:57 UTC
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.
Comment 44 Aron Budea 2016-07-19 22:50:39 UTC
*** Bug 100997 has been marked as a duplicate of this bug. ***
Comment 45 Ophir LOJKINE 2017-06-23 10:15:37 UTC
This is a very annoying bug that was reported 6 years ago. Is someone working on it ?
Comment 46 Regina Henschel 2017-06-23 15:50:22 UTC
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.
Comment 47 Jason C. McDonald 2017-06-23 15:58:17 UTC Comment hidden (obsolete)
Comment 48 Mark Hedges 2017-06-23 16:36:26 UTC
(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?
Comment 49 Jason C. McDonald 2017-06-23 16:44:25 UTC
(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.......
Comment 50 Mark Hedges 2017-06-23 16:59:14 UTC
(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
Comment 51 Xisco Faulí 2017-06-27 09:58:01 UTC
(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
Comment 52 Jason C. McDonald 2017-06-27 15:26:12 UTC
(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.
Comment 53 m_a_riosv 2017-08-27 16:27:42 UTC
*** Bug 112058 has been marked as a duplicate of this bug. ***
Comment 54 QA Administrators 2018-08-29 02:41:41 UTC Comment hidden (obsolete)
Comment 55 Regina Henschel 2018-08-29 11:07:16 UTC
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.
Comment 56 Timur 2022-03-31 13:31:55 UTC
I didn't test but in general: WFM is when there was a bug and NAB is when explained it's not. If Help is not good enough, the new duplicate can be used as Documentation.
Comment 57 Xisco Faulí 2022-05-02 11:53:37 UTC
*** Bug 148187 has been marked as a duplicate of this bug. ***
Comment 58 Timur 2022-05-17 14:23:05 UTC
*** Bug 144987 has been marked as a duplicate of this bug. ***
Comment 59 Mike Kaganski 2022-10-15 16:40:50 UTC
*** Bug 131194 has been marked as a duplicate of this bug. ***
Comment 60 Eyal Rozenberg 2024-03-23 23:02:06 UTC
I just encountered this behavior, and was about to file a bug but found this one.

I claim this is a bug, despite these other comments made here. Let me explain:

When a user inserts page numbers and wants them to start at a value higher than one, it is reasonable, and I would argue necessary, that the user be able to do this via the "Edit Field(s)..." dialog.

Now, given that:

* The dialog has a text box for "Offset"
* The natural interpretation of the meaning of that field is "apply the specified offset to the Page Number field value"
* The app-prescribed meaning of that field is "offset value that you want to apply to the page number field" (quoting the help pop-up bubble)

The field _must_ show the original value with the added offset, rather than become empty.

Whatever other behavior developers thought about originally, or is specified in the ODF - is irrelevant. Such different behavior must have a different UI, not this UI; and this UI _must_ adhere to users' expectation, which also a required feature we are currently missing.

(In reply to sasha.libreoffice from comment #15)
> IMHO usually users apply negative numbers for remove page number from title
> page.

That's not true. Users are told almost explicitly that applying a negative offset must result in a negative number. If something else happens - they would  discover this only accidentally, and it would be a hack which needs different UI (e.g. a checkbox for "hide zero-or-lower page numbers"; or perhaps a text box for the minimum or maximum page number to show).

(In reply to Matthew Francis from comment #29)
> There is an interesting point about the behaviour required by the
> OpenDocument specification in bug 67083 comment 12 (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>

This is an interesting ODF feature. However, it cannot be implemented in LO using the Offset field in the Page Number field dialog, especially not with the specified meaning in the offset field:

1. The label "Offset" does not correspond to the semantics of the text:page-number ODF attribute.
2. The pop-up help button clarifies that the text box has nothing to do with the semantics of the text:page-number ODF attribute.
3. There is a single text box in the dialog, and it must correspond to the obvious and commonly desired feature, of applying a simple numeric offset to the page number.
4. text:page number regards the desire to refer to following or preceding pages. The "Page Number" field refers to the number of the current page, hence its name. Users are not very likely to want to refer to specific other pages, as pages in Writer aren't "first-class citizens" - a derivative result of pagination of sequences of non-page content. If we wanted to allow for references to pages, that should probably be made possible via the cross-reference dialog.

(In reply to Regina Henschel from comment #37)
> There is nothing to fix. The current behavior of "offset" is correct.

The behavior is incorrect, as is the presumption to associate the text:page-number attribute with the offset text box of the Page Number field editing dialog.


> 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.

This bug is not about starting documents with a number different than 1; it is about applying an offset to a page number. We're not talking about the case of users wanting to insert page breaks.

The possibility of "really" starting documents on a page different than 1 is interesting and merits discussion; but there's no UI for it that I know of.

(In reply to Regina Henschel from comment #39)
> The specification is very clear:

It's actually not super-clear, but that's irrelevant, since the spec cannot apply to this text box.

> 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.

Again, that's not what the "Offset" feature is about and not what users are trying to achieve.

> If we wanted another behavior than specified, it would need an own loext-
> attribute.


There is no "if". That's the behavior users want. Either it is achieved by a field-inspecific offset attribute (i.e. one which can apply to any numeric field), or a field-specific offset attribute.
Comment 61 Mike Kaganski 2024-03-24 13:51:58 UTC
(In reply to Eyal Rozenberg from comment #60)

There definitely is a bug in the wording (and maybe placement, etc.) of this "offset" thing. It definitely provokes the problem in understanding of its goal.

However, there should be no way to *set* the page number through the field. In LibreOffice, the page number is set through properties of a page break. That must stay, and there should be no hidden connections between fields and page breaks. Convenience features like "insert break" dialogs are fine.

Arguing that "this is what users want" may indicate a problem in UX; but this is definitely *not* a definitive "this is how it must work" - otherwise, this PoV forces "every program is bound to what another, most widespread program does" - just because people naturally want to do the same as they are accustomed to in another software; and the percentage of these users would necessarily be dominant. This just prevents any innovation / other ways of implementing features.
Comment 62 Heiko Tietze 2024-03-25 04:57:14 UTC
How about "Reference page" for the label and "Change to display the page numbers of following or preceding pages" as tooltip. I'd also make it a spinedit.
Comment 63 Eyal Rozenberg 2024-03-25 09:07:20 UTC Comment hidden (obsolete)
Comment 64 Eyal Rozenberg 2024-03-25 09:22:39 UTC
(In reply to Heiko Tietze from comment #62)
> How about "Reference page" for the label and "Change to display the page
> numbers of following or preceding pages" as tooltip. I'd also make it a
> spinedit.

(In reply to Mike Kaganski from comment #61)
> There definitely is a bug in the wording (and maybe placement, etc.) of this
> "offset" thing. It definitely provokes the problem in understanding of its
> goal.

That  would bring the UI in alignment with the ODF attribute. It would be an improvement in the sense of not misleading users; but there are two problems with this approach.

The first problem is the implicit choice of legitimization. We currently have a feature the exact semantics of which disagrees with its UI. But the UI is for a feature users need and want much more (but see my reply to Mike below), and the spec is for a feature of questionable semantics and motivation. Your suggestion legitimizes and commits to the latter rather than the former. It would be better to keep the UI, change he LO implementation to meet users' need , and report a specification bug to OASIS which they should fix with the next version. 

If we did that, users who used the field as specified to refer to existing fields would still get the same effect, and it is only users who tried to do something invalid - referring to non-existing fields - which would see any change of behavior. And most users would get the offset feature they actually wanted. So - everyone should be happy, or happier at least.

Alternatively, we could devise a more robust generalization of what the UI offers now, anticipating what a future specification might provide. It might be a field arithmetic mechanism, so that users could insert a field which is an arithmetic expression combining other fields. That way they could insert something like "= {PageNumber} * 2 + 7" - something they currently they can't do.


The second problem with your suggestion is that a "refer to page by offset from current page" should just not be placed in the Edit Field... dialog of a Page Number field. 
 Like I wrote above, users would look to cross-reference other pages in the Insert | Cross-Reference dialog; and the Edit Fields for that kind of a field should be the same dialog we offer now for references to numbered paragraphs, headings etc.
Comment 65 Eyal Rozenberg 2024-03-25 09:27:56 UTC
(In reply to Mike Kaganski from comment #61)

> However, there should be no way to *set* the page number through the field.

Agreed, I did not mean to suggest that there should be.

> In LibreOffice, the page number is set through properties of a page break.

Which is a problem, as it doesn't cover the first page; nor does it allow for defining a progression rule for page numbers; nor does it properly cover the case of implicit page transitions, paragraphs which begin on a new page, etc. But again, I believe that's a different discussion for a different and perhaps deeper bug. This bug is about working with the page numbering mechanism LO has right now.

> Arguing that "this is what users want" may indicate a problem in UX; but
> this is definitely *not* a definitive "this is how it must work" -
> otherwise, this PoV forces "every program is bound to what another, most
> widespread program does" - just because people naturally want to do the same
> as they are accustomed to in another software; and the percentage of these
> users would necessarily be dominant. This just prevents any innovation /
> other ways of implementing features.

I am arguing that users want to be able to show the current page number plus an offset; and that they should be allowed to do that.

But thinking about the point of view of feature innovation, I would say that users may want two distinct and IMHO valid things:

* A more flexible mechanism for setting page numbers, and
* The field-arithmetic-expression idea I mentioned above, which is much more expressive, and in particular allows users to "play" with the page number value for display purposes regardless of what the "real" page number is.
Comment 66 Heiko Tietze 2024-03-25 10:26:11 UTC
Alternatively to a different naming we could hide the field. There are plenty of other methods to address the previous/next page number.

I admit the motivation for this ODF attribute is unclear to me. But what we should not do is to tinker around and break all existing documents and all compatibility.
Comment 67 Eyal Rozenberg 2024-03-25 11:29:16 UTC
(In reply to Heiko Tietze from comment #66)
> Alternatively to a different naming we could hide the field. There are
> plenty of other methods to address the previous/next page number.

Are there other methods to get a page number with an offset?

> I admit the motivation for this ODF attribute is unclear to me. But what we
> should not do is to tinker around and break all existing documents and all
> compatibility.

Agreed, but it seems we could change the semantics of this field _without_ breaking existing documents. We would have a problem with backwards compatibility - but then, features from new versions of the spec also have that problem with older versions of LO.
Comment 68 Mike Kaganski 2024-03-25 11:53:35 UTC
(In reply to Eyal Rozenberg from comment #65)
> (In reply to Mike Kaganski from comment #61)
> > In LibreOffice, the page number is set through properties of a page break.
> 
> Which is a problem, as it doesn't cover the first page;
It does. The very first paragraph can have the page break with respective properties as well.

> nor does it allow for defining a progression rule for page numbers;
Why *page number is set through properties of a page break* is the problem here? It is completely orthogonal. The mechanism is lacking completely, but can be implemented there as well.

> nor does it properly cover the case of implicit page transitions,
No idea what does that mean.

> paragraphs which begin on a new page,
Same here - no idea what could this be in the frame of the topic.
But maybe better to discuss elsewhere anyway.

> But again, I believe that's a different discussion for a different and
> perhaps deeper bug. This bug is about working with the page numbering
> mechanism LO has right now.
Agree.

Now to the topic. Note that the wish to show numbers outside of the existing range is wrong *in principle*. There is bug 149480; please think about it. The page field must not show any "random" number: it must show the number *flexibly* assigned to a specified page. Only having that page physically, can you know what page number is assigned to it - it could be an arbitrary number, say, 1 again (because user specified that manually). Its type may be arbitrary, say, Roman or Arabic.

So no, there is *no* meaningful number in an absent page, which a field could show.
Comment 69 Eyal Rozenberg 2024-03-25 12:59:46 UTC
(In reply to Mike Kaganski from comment #68)

(not continuing the discussion about how "real" page numbers are set.)

> Note that the wish to show numbers outside of the existing
> range is wrong *in principle*. There is bug 149480; please think about it.
> The page field must not show any "random" number: it must show the number
> *flexibly* assigned to a specified page. Only having that page physically,
> can you know what page number is assigned to it - it could be an arbitrary
> number, say, 1 again (because user specified that manually). Its type may be
> arbitrary, say, Roman or Arabic.

That logic applies is when the user wants to cross-reference a different page. What most users want when setting the offset field - and what motivates this bug report and its 12 (!) dupes - is to show the number of the _current_ page, but with an offset. In other words, users want (and are told by the UI that they will get):

ApplyOffset(GetNumberOf(CurrentPage()), N )

while the behavior the spec allows us to offer using the page-adjust attribute is:

GetNumberOf(ApplyOffset(CurrentPage(), N))
Comment 70 Mike Kaganski 2024-03-25 13:17:05 UTC
(In reply to Eyal Rozenberg from comment #69)
And we are back to the wording. It should be fixed. Generally, "ApplyOffset(GetNumberOf(CurrentPage()), N )" implies a numeric "page number", which is not a requirement. Any such arithmetics will not give you a *number*, but a "page number" - thus, the only sensible thing is "GetNumberOf(ApplyOffset(CurrentPage(), N))".

Now we have a *different* field, namely, Insert Formula field, allowing to use arbitrary calculations. The problem with its use is absence of a pre-defined variable for current page (the PAGE means actually "total number of pages" [1]). An improvement could be introducing such a pre-defined variable (with a problem of naming, given how awful the current name of PAGE was chosen).

Also, there is a Page Variable, allowing to do additional magic...

[1] https://help.libreoffice.org/24.2/en-US/text/swriter/02/14020000.html?&DbPAR=WRITER
Comment 71 Mike Kaganski 2024-03-25 13:37:39 UTC
*** Bug 114071 has been marked as a duplicate of this bug. ***
Comment 72 Mike Kaganski 2024-03-25 13:37:56 UTC
*** Bug 154928 has been marked as a duplicate of this bug. ***
Comment 73 Mike Kaganski 2024-03-25 13:38:04 UTC
*** Bug 149479 has been marked as a duplicate of this bug. ***
Comment 74 Mike Kaganski 2024-03-25 13:47:25 UTC
*** Bug 153811 has been marked as a duplicate of this bug. ***
Comment 75 Mike Kaganski 2024-03-25 13:55:54 UTC
*** Bug 133466 has been marked as a duplicate of this bug. ***
Comment 76 Eyal Rozenberg 2024-03-25 20:22:06 UTC
(In reply to Mike Kaganski from comment #70)
> Generally, "ApplyOffset(GetNumberOf(CurrentPage()), N )" implies a numeric 
> "page number", which is not a requirement.

It isn't? Page numbers are numbers, and numbers are numeric, aren't they? If you're referring to the styling of the number, i.e. A B C or i ii iii vs 1 2 3, that's just formatting; the offset applies to the number itself, not its formatted form.

> Any such arithmetics will not give you
> a *number*, but a "page number" - thus, the only sensible thing is
> "GetNumberOf(ApplyOffset(CurrentPage(), N))".

I have argued above that it is not a sensible thing. A user who chooses to [Insert | Page Number] does not want to insert the number of another page. For doing that, they would [Insert | Cross Reference]. 

(By the way, if a user does [Insert | Field], the dialog clearly separates "Cross Reference" from where we get the page number. But then, within the "Document" tab, in the "Select" column, we have "Page Number", "Previous Page", "Next Page". This suggests that we do get cross-ref-type fields on this pane; but it also suggests that the way to refer to another page is through the "Select" box, not through the Offset field, and that "Page Number" itself will only be the current page's number, not the number of any other page)

> And we are back to the wording. It should be fixed.

If you want to fix the UI so that Page Numbers are not necessarily numbers, you have to rework:

1. Some items on the Insert menu
2. The [Insert | Field] dialog <- which makes that assumption in multiple ways, including by have a number sequence choice box
3. The Insert Page Numbers dialog

... and I wonder whether replacing Page Numbers with something else will be a positive development for our users. Although I still don't know what you intend to replace "Page Number" with, so maybe it won't be that bad? :-\

> Now we have a *different* field, namely, Insert Formula field,

We do? I can't find it on the Insert menu, nor in the Insert Field dialog. 

Anyway, this could certainly be a basis for getting the "ApplyOffset(GetNumberOf(CurrentPage()), N )" effect. If we take that direction, then I believe the UI for [Insert | Page Number] would have to be rebased on this formula mechanism to begin with.
Comment 77 Mike Kaganski 2024-03-26 04:23:17 UTC
(In reply to Eyal Rozenberg from comment #76)

Page number mechanism in Writer is connected to e.g. ToC, and its numbers. Any "A user who chooses to [Insert | Page Number] does not want to insert the number of another page", which implies use of offset to modify (even for display) the number of *current* page, tries to introduce inconsistency. And of course, this leads to greater confusion.

I strongly believe, that there must *not* be any mechanics that allow *that* outside of the normal page break mechanism. OTOH, any improvements in the page breaks properties in that regards are welcome.

The current page field may be changed e.g. like this: remove the offset from the field completely; and introduce another field kind, "page reference", which would have the offset.
Comment 78 Regina Henschel 2024-03-26 11:43:21 UTC
(In reply to Mike Kaganski from comment #77)
> The current page field may be changed e.g. like this: remove the offset from
> the field completely; and introduce another field kind, "page reference",
> which would have the offset.

That is a good idea. The confusion about the "Offset" had already exist for StarOffice.

This is 7.3.4 <text:page-number> in ODF 1.3. For the change in the current field in LO and the new field in LO we need to exactly define how we map them to the element <text:page-number> on file save and file open. This element has an attribute text:select-page with values 'current', 'next', 'previous' and an attribute text:page-adjust.
Comment 79 Armondo Lopez 2024-03-26 19:29:41 UTC
Thank you for reporting the bug. I can confirm that the bug is present in 

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: a2265e8faa099d9652efd12392c2877c2df1d1eb
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

as well as

Version: 24.2.1.2 (X86_64) / LibreOffice Community
Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded