Bug 35694 - "Page number" automatic field stops counting before last page if offset >0
Summary: "Page number" automatic field stops counting before last page if offset >0
Status: CLOSED WORKSFORME
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:
: 50061 51005 64958 67083 80625 86728 100536 100997 112058 (view as bug list)
Depends on:
Blocks: Fields-Page-Number
  Show dependency treegraph
 
Reported: 2011-03-26 07:44 UTC by Guillaume
Modified: 2018-08-29 11:32 UTC (History)
23 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample file for bug 53694, 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
Hi! I set version to the oldest versin where the error occured...

@Roman: could you please test it....
Comment 9 Roman Eisele 2012-08-30 16:23:55 UTC
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.
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
(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.
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
Lowerings severity. This devinitely is no blocker

BTW: have you tried it with a fresh user profile...?
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
Sorry, I forgot to mention I'm using Win 7 x64
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
Please don't change the importance/priority. Thanks
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
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.
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
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.
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.