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

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Fri Mar 29 20:06:47 UTC 2024


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

--- Comment #80 from Eyal Rozenberg <eyalroz1 at gmx.com> ---
(In reply to Mike Kaganski from comment #77)
> 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.

Ok, so I guess we're having this discussion here after all...

Users should not, and in fact I claim will not, insert page breaks as a
mechanism of setting page numbers or page number progression logic.

They should not, because they don't want page breaks, and we should not force
them to break pages. I realize that we have a problem of sorts, due to the fact
that pages aren't first-class citizens in ODT documents and are derived from
paginating non-page content. But that is a challenge for us (or rather, for you
the developers) to contend with, not a burden to shift onto users by forcing
them to break pages when they don't want a break.

They will not, because when a user wants to change the page number value,
that's not because they want empty pages (which they get today with breaks
anyways). And since they don't want empty pages, they will not consider trying
inserting page breaks as the way to get to page number control UI; and I also
doubt they will tolerate page breaks being inserted for them when they try to
control the page numbers.

> 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 would make the UI consistent with the implemented feature, but it's a bad
idea, because page references don't belong in the [Insert | Page Number]
dialog. And it would make things worse for our users: Right now, they have a
mostly-working implementation of:

ApplyOffset(GetNumberOf(CurrentPage()), N)

with a bug. If we did what you suggest, many/most users will now not realize
they can abuse the page reference offset to get a simple value offset most of
the time. And that practice - ugly and broken as it is - is important. 

Instead, let's do one of the following, by decreasing order of my preference:

1. 
(If we can actually insert a formula field)
Change the semantics of the [Insert | Page Number] so that it always inserts a
formula based on the number of the current page, and if an offset was specified
- the formula includes that offset.

2
(If we can actually insert a formula field)
Change the semantics of the [Insert | Page Number] so that if an offset was
specified, it inserts a formula based on the number of the current page with
that offset (and otherwise, inserts a 'plain' page number field).

3.
(If we cannot actually insert a formula field)
Do nothing for now, work towards enabling formula field insertion.

4.
(If we cannot actually insert a formula field)
Define a non-standardized/extension attribute for applying an offset to a
(page) number; let's call it, say, text:page-number-offset. When the user sets
a non-zero offset, apply that attribute instead of the text:page-adjust
attribute.

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


More information about the Libreoffice-ux-advise mailing list