Follow-on to https://ask.libreoffice.org/t/page-number-paragraph-formatting-window-vs-style-inspector/90438/2 Frequently, users want to force a starting page number in a document (front material, chapters, index restarting from 1 with also a change in "style" as Roman, alphabetic, …). This is done with a "special" manual page break where user ticks _Change page number_. Note wording as "Change". Unfortunately, this is not enough advertised in the documentation (which is rarely read by beginners). Users stop at page number field insertion where they notice an _Offset_ box and they enter there an offset. They don't realise that this does not change the current page number but that it is a reference to another page. They are then surprised that the page number is blank when the page is too close to the "limits" of the document (the referenced page does not exist). It is then extremely important to be careful with wording in order not to add confusion to this already complicated matter. Unfortunately the style inspector reports a starting page number as _Page Number Offset_. Steps to reproduce: 1. In a blank document, add a direct formatting to the initial paragraph as forced starting page number in Flow Tab of paragraph. 2. Display the Style Inspector. 3. Paragraph Direct Formatting shows "Page Number Offset xx". Suggested: Change wording to read "Starting Page Number".
Note the two-fold problem. While the wording may be confusing, it is important to realize that it reflects the UNO property name "PageNumberOffset" [1] (currently, the names are auto-generated by splitting the property names by capitals). Indeed, nothing prevents us from cpecial-casing this, but the inspector should be useful for macro writers, among others; so even if we decide to change the name here, we should consider other means to communicate respective property name to user - e.g., showing it explicitly in a tooltip; and then we are back at this problem. And changing the API name is not an option ;) I have no specific proposals, so unfortunately this is not a constructive comment. [1] https://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1style_1_1ParagraphProperties.html#a90cbc0a25c6bbf1b98cfdeee2777557e
(In reply to ajlittoz from comment #0) > Unfortunately, this is not enough advertised in the documentation (which is > rarely read by beginners)... > ... > It is then extremely important to be careful with wording in order not to > add confusion to this already complicated matter. Do you think beginners use the SI to understand why the page numbering fails? Doubt this. Can we improve the workflow somewhere else?
(In reply to Heiko Tietze from comment #2) > Can we improve the workflow somewhere else? Maybe the proper place would be the offset in the Page Number field, expanding the label somehow to tell something in the line of "show the number of page N pages from this" (yes, yes, my wording is awful, I just hope others would get an idea, and create something usable from it :))?
(In reply to Heiko Tietze from comment #2) > Do you think beginners use the SI to understand why the page numbering > fails? Doubt this. Can we improve the workflow somewhere else? Since they already don't read the Writer Guide, I doubt they'd use the Style Inspector to debug their documents. Anyway, the current report stemmed from an "advanced beginner" (since he used the SI to try and understand) question on AskLO. (In reply to Mike Kaganski from comment #3) > (In reply to Heiko Tietze from comment #2) > > Can we improve the workflow somewhere else? > > Maybe the proper place would be the offset in the Page Number field, > expanding the label somehow to tell something in the line of "show the > number of page N pages from this" (yes, yes, my wording is awful, I just > hope others would get an idea, and create something usable from it :))? This is a good idea and a simple way to solve the API naming problem but the ambiguity in the Style Inspector remains. Instead of simply "Offset", "Reference page number at offset" ? However the topic is more complicated than I thought. I made a small experiment playing with offset, starting page number and format. It turns out that offsetting page number results in the number the offset page would have received in the current page sequence. To illustrate, my test document is made of: - one page "First Page" style with a, b, c => page a - one page "Default Page Style" style with 1, 2, 3 starting at 10 => page 10 - one page "Endnote" style with A, B, C => page A I then tweak the offsets: - +1 in First Page => page b, not page 10 (b is correct if second page would have been numbered in the current sequence) - -1 in "Default Page Style" => page 9, not page a (9 is correct if first page would have been numbered in the current sequence) Since I was surprised by the outcome, I tried more negative offsets: -2 to -9 decrease the page number down to 1 though the physical page does not exist. -10 gives page 0 which is quite odd typography-wise. Only when the offset is large enough to target negative number does the page number become blank. With positive offset, even very large ones won't give a blank page number though the page does not exist. - -1 in "Endnote" => page "blank" (because there is no valid number before A) Positive offsets always give a non-blank number though the page does not exist. It looks like the "non-null offset references another page" is valid only when there is no forcing page number in the page break. With a forced page number, the existence of the page is not taken into account and a page number is returned if it can be represented in the sequence. This makes it even more confusing. In the end, I question the usefulness of an offset parameter. Even in the case of "see page current+offset", we can't conditionally display this text because there is no way to reference page+offset in a variable for hidden text condition. The "see page at offset" can be replaced by a cross-reference with a more reliable result, except for returning a blank for non existing target.
Regina, could you please comment the observations above from @ajlittoz? IMO, a clear bug; having a page sequence like 1, 10, 1, a page number field on the very first page should give 10 for offset 1, give 1 for offset 2, and should be blank for offset <= -1 or >= 2 IMO. For page sequence like 1, 11, 1, the inserted blanks could (?) change this a bit (so offset 1 could give 2, offset 2 would give 10, offset 3 would give 11, offset 4 would give 1, and other non-zero offsets would be blank).
(In reply to Mike Kaganski from comment #5) > For page sequence like 1, 11, 1, the inserted blanks could (?) change this a > bit (so offset 1 could give 2, offset 2 would give 10, offset 3 would give > 11, offset 4 would give 1, and other non-zero offsets would be blank). Sorry for confusion; the above was meant to read: For page sequence like 1, 11, 1, the inserted blanks could (?) change this a bit (so offset 1 could give 2, offset 2 would give 11, offset 3 would give 12, offset 4 would give 1, and other non-zero offsets would be blank).
(In reply to Mike Kaganski from comment #5) > Regina, could you please comment the observations above from @ajlittoz? IMO, > a clear bug; having a page sequence like 1, 10, 1, a page number field on > the very first page should give 10 for offset 1, give 1 for offset 2, and > should be blank for offset <= -1 or >= 2 IMO. > (In reply to Mike Kaganski from comment #5) > For page sequence like 1, 11, 1, the inserted blanks could (?) change this a > bit (so offset 1 could give 2, offset 2 would give 11, offset 3 would give > 12, offset 4 would give 1, and other non-zero offsets would be blank). Regina?