[Bug 35694] "Page number" automatic field stops counting before last page if offset >0 (see comment 22)

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=35694

--- Comment #63 from Eyal Rozenberg <eyalroz1 at gmx.com> ---
(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
the feature users need and want much more, 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 do what users expect, 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. S



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

-- 
You are receiving this mail because:
You are on the CC list for the bug.