[Bug 161078] Allow direct formatting for page sequences instead of editing the style

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #4 from Mike Kaganski <mikekaganski at hotmail.com> ---
(In reply to Eyal Rozenberg from comment #3)
> But what is your opinion, Mike, on DF of page _sequences_?

IIUC, the suggestion is to create a way to allow a *paragraph* (the entity that
defines the page sequence) to use a *set of direct page properties* as an
alternative to a specific page style. Am I right?

Note that it is *orthogonally* desirable to introduce a new mechanism of page
sequence bounds - e.g., a page break object *inside* paragraphs (similar to
line breaks), which could also define page properties (page style as it is
currently, or a set of direct page properties, as I understand your request).

Now technically, it is not impossible. Internally, direct formatting is still
implemented as a special kind of *style* (autostyles); but what would be the
upside of this, and how could the *user management* be realistically
implemented for any kind of page-break-with-direct-page-properties, which would
be easy and different compared to the current situation? Including the
important "next page style" mechanism, which needs referring to the set of
properties of the next page, currently implemented by referring to the style
name?

I can see a dialog for "page break properties" (accessible from any page break,
like paragraph, table, or the imagined intra-paragraph dedicated breaks), which
would be ~identical to the current page style dialog. But it is completely
unclear how that would be an improvement, given that such a set of properties
would lack a big part of functionality allowed by styles, when it goes to the
next page style machinery (which is important for things like e.g.
odd-even/left-right/whatever sequences, or first chapter page - the rest of
chapter page sequences, which is also very important part of page management).

I do not see this whole suggestion as any kind of UX improvement; any "this is
internally inconsistent" is IMO not a problem per se, and if some *real* UX
problem can be solved by changing UI without introducing a direct formatting
for pages, I strongly oppose this bug 161078 suggestion. I do not see a
specific use scenario that gets better with this suggestion.

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