In Writer, we have styles which apply to characters, paragraphs, lists (or list items), and page sequences. But while we can apply direct formatting to the first four entities - we cannot apply DF to page sequences; at least, not using the UI. This is: 1. Inconsistent. 2. May still be somewhat confusing. 3. Not a good idea unless we change the paradigm of use of styles in LO. The inconsistency needs no demonstration, the introduction above makes it clear. As for confusing users - naturally, inconsistencies in entities' behavior or in the way one interacts with them is confusing. The matter was discussed at length in bug 126608; or at least, some user confusion was discussed at length, and the conclusion was to clarify this somewhat by changing the "Format | Page..." menu item into "Format | Page Style..." . This helps somewhat, i.e. it makes some users realize that the dialog will not apply DF to the current page sequence. But - other users will fail to realize this - because they expect consistency, and they know that on the Format... menu, one applies DF, not edit styles; and obviously there must be a way to DF a page sequence, so - it must be that "Page Style..." is just weirdly named, and actually does DF. The third point is illustrated by some of the examples brought in the discussion in bug 126608. But let me put it this way: Suppose we have a paragraph style with double spacing and a box around the paragraph. Is it legitimate to have a paragraphs of this style, but in which the spacing is 1.5 for some reason? In LibreOffice, the answer is "yes" - we allow it. We do not force this to be a different (named) style. Well, then - why should the same not be true for page (sequence) styles? Why can a document not have sequences of that style with some modification of one of its aspects? If you were to say "such a modification is no longer, in fact, the original style; and should have its own style name" - that is a legitimate view, but only if you also apply it to character, paragraph, list styles etc. - and we don't. The fact that there are typically more variations of DF for characters or paragraphs does not mean these should not exist for pages. So, unless we change the paradigm to _only_ have named styles - we should support page (sequence) DF.
From the Writer Guide (24.2) [1][2]: "Page styles control page properties (margins, page size, header and footer, among others). However, unlike paragraphs, characters, and frames, pages can not have directly applied properties. If you change the properties of a page, you are actually changing the underlying page style, so those changes are applied to all pages that use that page style. To change the properties of individual pages, you need to create a new page style. Headers and footers can be specified in one style to be different on left or right pages or first pages." So we directly format when we apply a page style other than what the current Page 'Organizer' tab "Next style", or a Paragraph 'Text Flow' tab "Breaks" defines. It is just a question of the how applied attributes of a page are grouped together and manipulated during document editing/layout and on export to ODF. In the UI, we can fully modify a page style from the Page Style... dialog or partially from the Page deck's content panels of the Sidebar. So we can manually force insert a page break onto a page with a different style. And that may be an existing page style, or have made a modification of an existing page style into a new page style that reflows the page--orientation, margin, layout, etc. attributes as found fully on the tabs of the Page style dialog. Noting the Sidebar Page deck omits some of the attributes. Absent Page style inheritance, bug 41316, each Page style requires its own style and only a defined "own style" [3] has meaning to be able to reuse from list box or the F11 Stylist in current document or as saved to template document. =-ref-= [1] https://documentation.libreoffice.org/en/english-documentation/ Writer Guide 24.2 [2] Byfield's Designing With LibreOffice treats page styles well. [3] https://help.libreoffice.org/24.2/en-US/text/swriter/guide/pageorientation.html?DbPAR=WRITER
(In reply to Eyal Rozenberg from comment #0) > If you were to say "such a modification is no longer, in fact, the original > style; and should have its own style name" - that is a legitimate view, but > only if you also apply it to character, paragraph, list styles etc. No. It is legitimate as long as there is no "page as a primary object" in Writer (which is the case), unlike characters, paragraphs, and other primary objects, that need *some* place, and by that, initiate *automatic* creation of pages, which uses properties of respective paragraphs (primary objects). The *logic* (this is *not* an implementation detail, but the underlying idea, defining the implementation) makes it a feature, that there is no direct formatting of pages. And no need for that.
(In reply to Mike Kaganski from comment #2) > No. It is legitimate as long as there is no "page as a primary object" in > Writer (which is the case), unlike characters, paragraphs, and other primary > objects, that need *some* place, and by that, initiate *automatic* creation > of pages, which uses properties of respective paragraphs (primary objects). Yes, certainly. Note I kept saying "page (sequence)" to emphasize that it's not one page; and that I'm not suggesting making a single page a primary object. So does the bug title. But what is your opinion, Mike, on DF of page _sequences_?
(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.
Additionally, the page styles are *actually* not the problem that users struggle with. The largest user problem with page management in Writer is the concept that page sequences are *properties of text* (currently paragraphs and tables). This is not obvious; this creates confusion. There is missing UI for both easy *identification* of existing page sequences, and easy *application* of the wanted page properties (styles) to a user-defined range. My strong opinion is, that simply solving these UI problems without any DF in pages would solve most of the user confusion around page styles.
And let me also provide a "philosophical" view on this. The proposal argues that since we allow DF for other entities, we should do the same for pages. But this is like this: 1. There is a consensus that styles mechanism is generally superior to direct formatting. 2. But there are *reasons* why we can't avoid direct formatting in some areas - like steep learning curve, or compatibility, or legitimate use cases. 3. This justifies the *unfortunate* need of DF in many entities, giving raise to a huge set of problems, like unmanageable documents being overwhelmingly common, and not only when one writes a letter to a friend, and forgets that - but in most real-life documents offered as templates in official sites of organizations, governments, and so on. This is an inevitable evil, but not something to cheer. 4. And now, the unfortunate need to keep the DF in some entities provokes a suggestion to also support this same problematic "feature" in an entity which was lucky to survive without DF so far. And that lack of DF was not itself problematic for users - other problems (as mentioned in comment 5) could be solved to make the current no-DF a comfortable state. I disagree that a "consistency" argument is applicable / fair in this context.
While I fully agree with Mike's comments it might be worth to think about from another angle (actually as bugs should be reported). Something like: "I insert a graphic on page 5 and want to make this page landscape. Please add easy means to do so.". Theoretically we could do the same as for lists and create a page style on the fly, and add a page break with it after the last paragraph of the previous page, plus one with what was active before on the current page.
(In reply to Heiko Tietze from comment #7) > While I fully agree with Mike's comments it might be worth to think about > from another angle (actually as bugs should be reported). Something like: "I > insert a graphic on page 5 and want to make this page landscape. Please add > easy means to do so.". e.g. ask (somewhere) "[] apply to current page only" (and then later on fight the trouble of people not understanding why the text flow in their documents is broken - fatal path..) Maybe the least bad option is to show a warning when applying a page style via selecting (Manage Styles or Status Bar) "mind that <bla bla> see <bla bla> [] do not show this warning again"
(In reply to Mike Kaganski from comment #6) > I disagree that a "consistency" argument is applicable / fair in this > context. Apart from your arguments, "making use of styles easy/promoting the use of styles" is a good principle in our work.
(In reply to Mike Kaganski from comment #4) > ... it is not impossible... but what would be the upside of this[?] The opposite of the problems with which I described the current situation: * Consistency with styles of other entities. * Format | Page (Sequence)... becomes a less confusing action, with no spooky action at a distance on other page sequences which the user never intended to affect. * No need to go to the trouble of defining a new page style just to apply some formatting to the current page sequence. To be concrete: I want to have some of a couple of pages of mine to exhibit a blue background. Why should I need to define a style just for that? And of course, I can't have my Default Page Style go blue, since my pages are basically white. So, it's DF for me, tee hee. Also, while we don't have composable and inheritable page styles, defining multiple page styles for many kinds of sequences requires a lot of maintenance, in the sense that whenever you change something that's common to multiple styles, you're likely to have to change all of them. > and how could the *user management* be realistically implemented ... which > would be easy and different compared to the current situation? I don't propose any changes in how users manage this compared to the current situation: * Format | Page... (or Format | Page Sequence...) will apply DF * Double-clicking the current page style will clear the DF * Clicking another page style will apply it, but try to keep the DF where possible > 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? Ah, that's a good point. Here are two options for when a Next Page Style is defined: 1. Only the first page in the sequence gets the DF, and then it's just a clean application of the Next Page Style, and the next-next-page style etc. 2. For each transition to the next page, act as though the user had double-clicked that style while having DF in effect. That is, try to apply the DF to the extent possible. (actually (2.) is not perfectly well defined.) I like (2.) better, but I think this is kind of a non-issue, because the use of alternating styles like that only happens intentionally, when the user carefully styles his/her page sequences. Such a user can be assume to not be fazed or confused by our choice of DF application behavior, and realize they may need to clear the DF. There is also the possibility of warning about DF'ing a page sequence with Next Page Style defined, if we believe this should be avoided. It's not clear to > I do not see this whole suggestion as any kind of UX improvement; any "this > is internally inconsistent" It's _externally_ inconsistent. I find it inconsistent. I forget that this is the case, and mess up my documents. And if it happens to me, it happens to many users.
(In reply to Heiko Tietze from comment #7) > While I fully agree with Mike's comments Then please read my last comment and I'm sure you'll change your mind. > it might be worth to think about > from another angle (actually as bugs should be reported). Something like: "I > insert a graphic on page 5 and want to make this page landscape. Please add > easy means to do so.". > > Theoretically we could do the same as for lists and create a page style on > the fly, and add a page break with it after the last paragraph of the > previous page, plus one with what was active before on the current page. Let's not get ahead of ourselves. The ability to format a single page / create a single page sequence is relevant with or without the ask in this bug - when considering named styles. Maybe I have a "blue background" style that I've defined; a desire to apply it to a single page is also relevant. But - that's not the scope of this bug.
(In reply to Cor Nouws from comment #9) > Apart from your arguments, "making use of styles easy/promoting the use of > styles" is a good principle in our work. Unfortunately - it isn't; and this is a key point. That is, it is a good principle for users to adopt, but our policy is to enable the opposite user behavior, of "I'll just DF and I don't care and styles and consistency." We could decide we want to enforce the use of styles; but - if we're not enforcing this for most entities, it does not make sense to enforce the use of "styles only" just for page sequences.
(In reply to Eyal Rozenberg from comment #11) > (In reply to Heiko Tietze from comment #7) > > While I fully agree with Mike's comments > Then please read my last comment and I'm sure you'll change your mind. Indeed, it changed my mind and I vote to not introduce any page level DF. Your blue background example strikes me as somewhat random, and even my more realistic orientation topic is prolly going to end in a lot headaches. We rather should drop all DF than adding more. => NAB/WF
1. "I suffer this, means many must suffer this, too" is *not* a valid statement in LibreOffice case. We have a specific, that any really problematic areas *always* produce multiple duplicate tickets here, no matter how advanced the problem is (simply because of the really large number of users). It doesn't mean that there's no other people suffering this problem; just in the absence of duplicates, it is *reasonable* to suspect a niche problem. 2. "In the absence of a great missing feature of page style inheritance, let us implement a very problematic other feature of page DF, which incidentally wouldn't be any simpler in implementation" is not a valid proposal. The feature you suggest should *only* be considered after *both*: implementation of page style inheritance, *and* implementation of usability improvements mentioned in comment 5 (which are orthogonal to what you ask here, I know). Only then, we may have some clear idea how much *this* problem deserves its cost (and the largest cost is not its implementation, but dealing with consequences).
Reading the discussion, I think, it's not a bug, but an enhancement request. So I change severity. And I also don't see the need for DF of page styles
(In reply to Heiko Tietze from comment #13) > We rather should drop all DF than adding more. > > => NAB/WF Now, wait a minute, Heiko. If I opened a new bug today, asking to remove the ability to apply DF to, say, characters - would you support it? Set it to NEW? Even though it would mean dropping almost all commands on the Formatting toolbar? Less facetiously though: Are there official, binding policies regarding the extent of DF and the eventual "fate" of DF? If there are, let's talk about how they apply to this bug. If there aren't, then if we ever "drop all DF" - we can drop the page sequence DF as well, and I don't see why it should be left out of DF'ing. Let us also not forget DFing in other modules, like Calc or Impress, which have even more DFable entities.
(In reply to Dieter from comment #15) > I also don't see the need for DF of page styles (In reply to Heiko Tietze from comment #13) > => NAB/WF (In reply to Mike Kaganski from comment #2) > there is no direct formatting of pages. And no need for that. (In reply to Eyal Rozenberg from comment #16) > If I opened a new bug today, asking to remove the ability to apply DF... Off-topic, and answered by Cor (less provocative phrased): (In reply to Cor Nouws from comment #9) > Apart from your arguments, "making use of styles easy/promoting the use of > styles" is a good principle in our work.
(In reply to Heiko Tietze from comment #17) > (In reply to Dieter from comment #15) > > I also don't see the need for DF of page styles There's no "need" for DF; nor, in fact, is there "need" for Writer at all. We can just use plain text, or LaTeX, with some blood sweat and tears. ... but DF is useful and used. We encourage the use of styles, but since when are we preventing the use of DF, other than in this case? > (In reply to Heiko Tietze from comment #13) > > => NAB/WF Rebutted, but see below. > (In reply to Mike Kaganski from comment #2) > > there is no direct formatting of pages. And no need for that. That is not a comment relevant to the closure of this bug, which is about page sequences. > (In reply to Eyal Rozenberg from comment #16) > > If I opened a new bug today, asking to remove the ability to apply DF... > Off-topic, and answered by Cor (less provocative phrased): Not off topic, as I've explained; and as for what Cor said: > (In reply to Cor Nouws from comment #9) > > Apart from your arguments, "making use of styles easy/promoting the use of > > styles" is a good principle in our work. That's a disingenuous excuse. But we shall soon test whether you or Cor really stand by these words... so, please mark bug 161149 as NEW, or reopen this one.
(In reply to Eyal Rozenberg from comment #18) > ...reopen this one. Feel free to do so. However, opinions wont change: No need for (random) PgS-DF.
(In reply to Heiko Tietze from comment #19) > Feel free to do so. However, opinions wont change: No need for (random) > PgS-DF. I have argued for why it is useful and important for consistency (in comment 0 and comment 10). The counter-arguments have been against DF as such. As we've established that DF is legitimate and desirable enough in Writer, for us to want users to be able to apply it even despite of the encouragement to use styles - kindly explain why DFing page sequences should be an exception to DFing other entities. What special argument is there regarding the impropriety of DFing page sequences, that one cannot apply to other entities?
FWIW: I do relate with the issue described in comment 10 and bug 161075 and I grasp why DF is proposed. I have had quite frustration with rotating some pages from portrait to landscape. Why does it require a new page style. Seems a bit excessive. And the lack of inheritable page styles surely makes it worse. I need to have dedicated style, only for page rotation purposes? Applying a page style to the proper range is quite an exercise; IMHO. I surely got the feeling I was fighting the software. I have posted quite a list of bugs, like bug 136412; bug 136961 in the past (somewhat mediocre quality). I keep finding the current model skewed in various aspects. I still think: how can it be that simply rotating a page can be that hard (and frustrating and unintuitive). Apparently others can work with it...
(In reply to Telesto from comment #21) Given what you've said, why did you mark this WONTFIX? > Apparently others can work with it... Or give up on LibreOffice and go back to MSO ?
The usecase for turning specific pages that I can think of are usually specifically the cases where this basic assumption does not apply, i.e. specific inset regions with e.g. a large diagram or image. However, all solutions I see clash with other assumptions about how people are used to how a word processor behaves usually behaves, particularly, that content is mainly one long sequence that just flows on the next page. I do not find it helpful to approach it from the perspective of the model of direct formatting vs. style based formatting as applied to anything that can be formatted, since a) It is not based on specific usescases and b) Not all domain objects (like string sequences, pages, frames…) have the same uses and thus some might lend themselves more to direct formatting while others work better with styles (or other methods to influence their appearance and behavior, e.g. dependencies like "this content should always be on a landscape-format-page", which might work well for the special-content usecase described above)
(In reply to Eyal Rozenberg from comment #22) > (In reply to Telesto from comment #21) > > Given what you've said, why did you mark this WONTFIX? Unintentionally. The status was WONTFIX at the point writing the message. The status changed at the point of posting the message. I got there is a conflict, but opted for post anyway. > > > Apparently others can work with it... > > Or give up on LibreOffice and go back to MSO ? A) I'm not a heavy Office Suite user at this point in time. More a simple home user B) I'm still in the 'testing phase' for LibreOffice. An Office suite is primary a tool to make myself productive. I will use MSO if I can't get the desired result or only - in my perception - with disproportional effort (including workarounds)