I'm looking at the list of available page styles in Writer's style sidebar. What I see is (numbering not originally there of course): 1. Default Page Style 2. Endnote 3. Envelope 4. First Page 5. Footnote 6. HTML 7. Index 8. Landscape 9. Left Page 10. Right Page Let's now review this in a decreasing order of sense. (1.) and (3.) : I'm ok with those. There's the app default, that's fine. And an envelope as a page, I can see the rationale there, no problem. (8.) : What do you mean, landscape? Landscape what? This suggests that it's a landscape version of the default page style. But - it isn't! It doesn't inherit the default style. If it had inherited the default style, then I could live wit it, although it's still a bit questionable to have a separate page style for a single aspect change relative to parent. Such a style would make more sense as a "mixin" or "delta" style, if styles were made composable as suggested in 149271. (i.e. it would be like the Character Styles "emphasis" and "quotation") (2.) and (7.) : It's not clear what "Index" or "Endnote" here mean. Is this supposed to be a special page style for pages dedicated to Indices/Footnotes? Why Index and not Table-of-Contents? Or even "Table" for pages dedicated to tables? Plus, why/how should the page style change for an Index? Vague name and unclear raison-d'etre. (6.) : I have no clue what this is supposed to mean. What does a markup language have to do with the style of a physical page? (9.) and (10.) : The source of most confusion on this list. This can mean any number of things! A page with an RTL default for paragraph styles? A page with Right-aligned text by default? A page to the right of spine? A page with larger margin on the right? Are these two - Left Page and Right Page - supposed to alternate? If not, should a page after a right page still be a right page? I consider myself somewhat of a power user and am I still quite confused. (5.) : Footnotes are never on their own page, so I don't see how this can make sense in any way! Bottom line: * Get rid of some and perhaps most of these. (1.), (3.), (8.) I guess you can keep, the rest should probably just go away. * If you keep any of the vaguely-named styles, make their rasion d'etre clearer (and please don't tell me to go read the help...)
My complaint about (8.) relates to bug 41316 - there are currently no hierarchical relations among Page Styles.
No idea about HTML, probably legacy stuff used for minimum margins. Special styles are kind of clear to me, and I guess for you too. Left/Right is also not a brainer, just check what happens at the properties. Whether any of these styles is really usable is another question. But similarly relevant: Does it hurt to have these styles?
(In reply to Heiko Tietze from comment #2) > No idea about HTML, HTML is the default page style for File > New > HTML document.
(In reply to Regina Henschel from comment #3) > HTML is the default page style for File > New > HTML document. Hmm... I didn't even remember we had such an entry in the new document menu. Those menu entries are weird. Be that as it may... there are several kinds of documents one can create using the File > New submenu: Text, HTML, Labels, Business Cards (and ignoring Master Document). Right now, the Default Page Style is the actual default page style in Text, Labels and Business Cards documents, but not in an HTML document. I don't understand why they don't all use the Default Page Style as the Default Page Style. They don't even each have their own page style. Also, even given the current situation - when creating an HTML document, we can't access the Page Styles via the sidebar, and can thus not see "HTML" on the list of Page Styles. We can edit it through the Format menu, but can't replace it. Why, then, should we be able to see this special style as another item on the list, when editing text documents? And
(In reply to Heiko Tietze from comment #2) > Special styles are kind of clear to me, and I guess for you too. Not sure which ones you're referring to here. > Left/Right is also not a brainer Oh really? :-) > just check what happens at the properties. First, before I do that - you realize that, given that it doesn't inherit the default page style, there is absolutely no way in which the properties here could make sense. This must define page dimensions, margins, orientation and all other properties. And whatever the values are - they're wrong. Only inheritance can be valid for most properties. But you insisted, so let's check. "Right page" contains: "29.7 cm + From top 2.0 cm, From bottom 2.0 cm + Text direction left-to-right (horizontal) + Page description: Arabic, Portrait, Left + Right Page + Not page line spacing" Still think this is a no-brainer? I'll let you guess what "Left Page" contains. > Whether any of these styles is really usable is another question. But > similarly relevant: Does it hurt to have these styles? Yes. When the page style dialog has a lot of confusing items, it makes the user have second thoughts about whether they should even consider making a selection from the list, since who knows what these things do anyway.
I protest the non-serious discussion of this bug in the recent design committee session.
(In reply to Eyal Rozenberg from comment #0) > (8.) : What do you mean, landscape? Landscape what? This suggests that it's > a landscape version of the default page style. But - it isn't! This is a quick and dirty way to switch from portrait to landscape, reminding the writer that the page is in landscape. For some types of writing, this is a useful thing. >It doesn't inherit the default style. If it had inherited the default style, In an ideal world, page styles would be inheritable. > (2.) and (7.) : It's not clear what "Index" or "Endnote" here mean. Is this > supposed to be a special page style for pages dedicated to Index pages have a very specific page layout and markup criteria.The blatantly obvious example being that lower case Roman numerals are used for page numbers. Less obvious is that they have either two or three columns. Endnote pages and Footnote have also have very specific page layout and markup criteria. No page numbers being the most obvious example. The first printed page that follow End note pages and Footnote pages is a Right Hand Side page, being a less obvious layout criteria. Point size of text is smaller than on regular pages, being an equally unobvious differentiator. > (5.) : Footnotes are never on their own page, so I don't see how this can > make sense in any way! I'll grant that Footnote pages are a specialist thing. They do exist, albeit not nearly as common in contemporary (2023 publications) as in days of yore --- C18 publications. I have seen a single footnote ramble on for almost 100 pages. A trend that began in the early/mid-sixties in British & US publishing, was to throw anything longer than a single line, from footnotes into end notes. Hence, today (2023) the majority of time one comes across footnote pages, is in reprints of material that was originally published more than fifty years ago. > Indices/Footnotes? Why Index and not Table-of-Contents? Or even "Table" for > pages dedicated to tables? Plus, why/how should the page style change for an > Index? Vague name and unclear raison-d'etre. The page layout for Table of Contents, and for Indices is different. The blatantly obvious difference being that Table of Contents is a single column, whilst Index Pages are two or three columns. Less obvious is that Table of Contents pages lack page numbers, whilst Index pages include them. > (9.) and (10.) : The source of most confusion on this list. This can mean > any number of things! A page with an RTL default for paragraph styles? A right hand page is, by definition, an odd numbered page. A left hand page is, by definition, an even numbered page. > Are these two - Left Page and Right Page - supposed to alternate? Going by the definition, yes. > * Get rid of some and perhaps most of these. (1.), (3.), (8.) I guess you > can keep, the rest should probably just go away. There is a tension between providing the fifty odd page styles that the in-house Style Manuals for the Seven Sisters requires, and catering for somebody who has no idea that page styles exist, much less how to correctly use them. In theory, an extension that contains the styles that the in-house specialist uses, could be created and distributed. In practice, that probably won't happen, but not due to a lack of need. > * If you keep any of the vaguely-named styles, make their rasion d'etre > clearer (and please don't tell me to go read the help...) That page styles are perceived as being vaguely-named does not mean that they are either vaguely-named or lack a rasion d'etre. ### Should the documentation explain how and why each style (Bullet, Page, List, Character, Table, Line) exists, and how to use the specific style? My working assumption is that people who want to know that, either studied, or will study the Style Manuals from the Seven Sisters and Chicago, or the British or European equivalents.
(In reply to jonathon from comment #7) > A right hand page is, by definition, an odd numbered page. 1. If what you said were true, a "Right Hand Page" would not be, and could not be, a page style - since continuing with a second (numbered) page of the same style would have it contradict the definition. 2. Who said the pages are numbered at all? Not LO Writer, in which a "Right Page" and a "Left Page" are not numbered by default. 3. Welcome to Earth, my friend. On our planet, many cultures / written language communities write from right to left and flip pages from left to right. The odd/even, left/right etc. conventions for such languages are typically flipped. > A left hand page is, by definition, an even numbered page. See above. > [Landscape] ... this is a quick and dirty way to switch from portrait to > landscape, reminding the writer that the page is in landscape. That would be true if the Landscape style inherited the Default Page Style. So once any change has been made to the default style (e.g. margins, text direction etc.) - selecting this style makes a bunch of changes which are not what the user expects. > In an ideal world, page styles would be inheritable. I hardly think fixing 41316 means achieving an ideal world... I just think the order of business is fixing 41316 first, adding this style later. Anyway, marking this bug dependent on 41316. > Index pages have ... Does Writer have "Index Pages"? When I insert an Index, it's inserted inline. Does LO ever create "Index Pages"? ... I don't think it does. > Index pages have a very specific page layout and markup criteria. On the contrary. Indices don't have to be placed on separate pages, and thus naturally have no "specific page layout and markup criteria". If that were the case, that should have been a feature of Indices, not some general page style you can apply anywhere. > The > blatantly obvious example being that lower case Roman numerals are used for > page numbers. See my "welcome to earth" comment above... in non-Latin alphabet languages, this is certainly not common, let alone necessary. That kind of convention belongs in a document template, I would say. > Less obvious is that they have either two or three columns. Not in LibreOffice they don't; at least, not by default. When you insert an index, it has one column. And, in fact, LO's "Index" page style only has one column. (Personally, I use 2 or 3 columns in my alphabetical indices.) > Endnote pages ... have also have very specific page layout and > markup criteria. Here I'm not sure; I was not aware there was a universal convention. But - ok, suppose that's true. In that case: 1. This style should be named "Endnotes" (or "Endnotes Page"), not "Endnote". 2. It should probably not be applicable to non-endnote pages. > The first printed page that follow End note pages... is a Right Hand Side page That can't be true, because if there is any such restriction, it must be reversed for RTL document layout. Moreover, some documents don't _have_ right-hand-side and left-hand-side pages. Example: A document to be printed on one side of each sheet of paper, and not bound on one side of the sheets. > Point size of text is smaller than on regular pages, being an equally unobvious differentiator. This is actually a rather interesting point... does the Default Paragraph Style inherit anything from the Page Style? Perhaps it should. > I have seen a single footnote ramble on for almost 100 pages. Those would be 100 regular pages of text. If a footnote doesn't fit on the same page as where the footnote reference is located, then it continues to take up some part of later pages of text. But they would still be regular pages of text. Even if the footnote extends past the last page of text - it is a degenerate case of a regular page of text, with no lines of no-footnote text. And that's how it works in LibreOffice. > A trend that began in the early/mid-sixties in British & US publishing, was > to throw anything longer than a single line, from footnotes into end notes. > Hence, today (2023) the majority of time one comes across footnote pages, is > in reprints of material that was originally published more than fifty years > ago. Historical point taken - but that's not how footnotes work in LibreOffice. LO has no footnote pages and I don't know of a plan for this to change... > The page layout for Table of Contents, and for Indices is different. The > blatantly obvious difference being that Table of Contents is a single > column, whilst Index Pages are two or three columns. It may or may not be blatantly obvious - but it is not true in LO right now. Indices are generated using a single column by default. > Less obvious is that Table of Contents pages There are no "ToC pages". And - there's no ToC Page Style! This, despite ToC's being more commonly used than indices. The fact that there is no page style for the first, and a page style for the second, is part of what's non-sensical. > > Are these two - Left Page and Right Page - supposed to alternate? > > Going by the definition, yes. This is ridiculous. To see why, suppose I use this scheme, and have 500 pairs of a Left Page followed by a Right Page. Now I notice that I need to add an extra page after, say, page 100. Well I go to page 101, a Left Page, insert a Page Break, and before the break add some contents. Guess what? Now I have 800 pages whose page style needs to be replaced. No, the mechanism of having separate features when a page is odd or even in the order of pages, or being to the right or left of the spine, is something which must be covered within a _single_ page style. > the in-house Style Manuals for the Seven Sisters requires I have a hunch that these are universities somewhere... am I right? > There is a tension between providing the fifty odd page styles that the > in-house Style Manuals for the Seven Sisters requires ... > In theory, an extension that contains the styles that the in-house > specialist uses, could be created and distributed. In practice, that > probably won't happen, but not due to a lack of need. This can be handled easily using a bundled document template that corresponds to said manual of style (or several templates, for "Thesis", "Article", "Book", "Memoir" or whatever kinds of documents those style manuals describe). > and catering for > somebody who has no idea that page styles exist, much less how to correctly > use them. That's exactly my motivation with this bug report. It must be very obvious to a newbie users which kinds of styles the user should be relevant for manual application, to choose between. Most styles in the list are ones the user should never apply themselves, or at least not apply themselves through making a choice from the list. ... but in fairness, some of this criticism may apply to some non-Page styles, e.g. Endnote and Endnote Text. > That page styles are perceived as being vaguely-named does not mean that > they are either vaguely-named It does. If one cannot clearly perceive the rationale/meaning of a name, then that name is vague, and the named entity is vaguely-named. > That page styles are perceived as ... lacking a rasion d'etre ... does not > mean that they ... lack a rasion d'etre That's true, but I've argued why some of these lack a raison d'etre _as styles available on the list of page styles for a user to select from_. > Should the documentation explain how and why each style (Bullet, Page, List, > Character, Table, Line) exists, and how to use the specific style? This bug is not about the documentation. The app itself should be sufficiently self-explanatory, with documentation as a "second line of support". IMNSHO.
The ticket started with "get rid of some and perhaps most of the page styles". We discussed this in the design meeting and come to the conclusion that every single page style has a use case. See also Jonathon's comment 7. => NAB Whether Left/Right is correct or should be Even/Odd is another question. It probably boils down whether RTL starts the first page on even numbers. (In reply to Eyal Rozenberg from comment #8) > No, the mechanism of having separate features when a page is odd or even in > the order of pages, or being to the right or left of the spine, is something > which must be covered within a _single_ page style. You invent new wheels; and even if your approach works we still want to support round-trips with other applications/document types.
(In reply to the design committee session minutes) > + every single page style has a use case (Cor) No, some of them don't: (5.) Footnote (9.) Left Page (10.) Right Page as I have explained even before the committee session and further clarified afterwards. Another has a use case which is suspect: (6.) HTML See comment #3 and comment #4. others may have a use case, but LibreOffice itself doesn't "respect" this use case: (7.) Index see comment #8. and there's the fact that such a "use case" has not resulted in a "Table of Contents" page style, so another inconsistency there. > + never had any problems with the list of page styles (John) 1. I never had any problems with most things I read bug reports about... this could be an argument for reducing the importance to minor, not for whether or not it's a bug. 2. I don't know John's QA experience, but his name suggests he's not an RTL language user. For us, the "Left Page", "Right Page" is a more serious problem than it would be for him (for which reason I would oppose making this bug minor). > + the (small) list can also be filtered (Heiko) Don't see how this is an argument against or in favor of the validity of this bug. This isn't a report about me having personal dislikes of certain styles - which would be solved by some kind of personalized filtering. And, of course, if we filter to only show the styles "in use", we'll not see any legitimate options in a new document except for the Default Page Style. If Heiko was suggesting some page styles be hidden from the user by default - e.g. the page styles which are intended for automatic application, like "Endnotes" - that would better legitimize their being part of the list of styles. Perhaps a separate issue should be opened about this.
(In reply to Heiko Tietze from comment #9) > The ticket started with "get rid of some and perhaps most of the page > styles". We discussed this in the design meeting and come to the conclusion > that every single page style has a use case. See also Jonathon's comment 7. > => NAB Considering how the minutes say very little, I had little to reply to, but tried to do so in comment #10. I wonder if the discussion was actually more serious than that. I replied to Jonathan's better-elaborated comment, in comment #8. Actually, by comment #8, I have come to realize that this should probably be a meta-bug, as there are actual several different issues: * Style naming * Styles without any use case * Potential page style use cases which aren't realized in LibreOffice right now * The question of use-cases which don't involve the user explicitly choosing a page style * Styles with use apparent use cases which require 41316 to be valid. * The case of Left/Right, which may have some kind of intended use case, but it's bad/invalid/undesirable as well as confusing. > Whether Left/Right is correct or should be Even/Odd is another question. It > probably boils down whether RTL starts the first page on even numbers. No, it doesn't boil down to that. It can't be fixed. Whichever way you try to give a raison d'etre for Left Page / Right Page - it doesn't add up. > (In reply to Eyal Rozenberg from comment #8) > > No, the mechanism of having separate features when a page is odd or even in > > the order of pages, or being to the right or left of the spine, is something > > which must be covered within a _single_ page style. > > You invent new wheels; and even if your approach works we still want to > support round-trips with other applications/document types. On the contrary, these are existing wheels: "Page layout: Mirrored" is a possible feature of a single page style, and is what you use to get the alternating pages laid out different, with the gutter located near the spine. "Left Page" / "Right Page" are new wheels. I've never seen a document which uses them. I would bet very few people use these (and perhaps even nobody? I wonder). Even if, somehow, "Left Page" and "Right Page" existed before a gutter and mirrored layout were supported - that would make them the old crutches, not the old wheels...
(In reply to Eyal Rozenberg from comment #11) > > * The case of Left/Right, which may have some kind of intended use case, but > it's bad/invalid/undesirable as well as confusing. > > > Whether Left/Right is correct or should be Even/Odd is another question. It > > probably boils down whether RTL starts the first page on even numbers. > > No, it doesn't boil down to that. It can't be fixed. Whichever way you try > to give a raison d'etre for Left Page / Right Page - it doesn't add up. Left Page / Right Page has a very real use case. I use it a lot. Left page might get one header/footer and right pages might get another header/footer. For instance, if I want page numbers only on the outside edge of the page, how would you propose doing it without defining left versus right page styles?
(In reply to David from comment #12) > (In reply to Eyal Rozenberg from comment #11) > > No, it doesn't boil down to that. It can't be fixed. Whichever way you try > > to give a raison d'etre for Left Page / Right Page - it doesn't add up. > > Left Page / Right Page has a very real use case. I use it a lot. Left page > might get one header/footer and right pages might get another header/footer. > For instance, if I want page numbers only on the outside edge of the page, > how would you propose doing it without defining left versus right page > styles? I should've checked my templates first, I forgot that you could specify a different header if the page is on the left or right. But I do specify a right page if I want a section to begin only on an odd number page.
(In reply to David from comment #12) > Left Page / Right Page has a very real use case. I use it a lot. Left page > might get one header/footer and right pages might get another header/footer. What happens when you need to insert an extra page before a large number of pages, each pair of which is style Left Page and Right Page respectively? > For instance, if I want page numbers only on the outside edge of the page, > how would you propose doing it without defining left versus right page > styles? There's a feature specifically for this purpose. In the Page Style dialog, on the Footer tab, under "Footer on", you have: "Same contents on left and right pages". If you uncheck it, you get what you asked for.
(In reply to David from comment #13) > But I do specify a right page if I want a section to begin only on an odd number page. Then you're assuming the style will do something it does not, because specifying "Right page" will not affect the page numbering; nor will it insert an extra page before your section begins (nor at section start). ... not to mention what were to happen if you need to add another page before your existing first page of the section; or what happens if you need to make your document RTL; etc. Bottom line: These two styles confuse users into thinking they do something which they do not.
(In reply to Eyal Rozenberg from comment #15) > Then you're assuming the style will do something it does not, because > specifying "Right page" will not affect the page numbering; nor will it > insert an extra page before your section begins (nor at section start). I can configure a heading paragraph style at the beginning of a chapter (and yes, that chapter may be within a document "section") to insert a page break with a particular page style before the heading. If I tell it to insert a page with the Right page style, then I can set that page style to not include a header. I can also set the Right page style to use my normal page style as the next page, which does have headings on it. Please provide a document template that demonstrates a better way to do this so that we all may learn.
And how do you make the margin appear left/right depending on odd/even pages?
(In reply to Heiko Tietze from comment #17) > And how do you make the margin appear left/right depending on odd/even pages? Assuming a symmetrical layout, by enabling the style's "Mirrored" layout option.
I just discovered this bug report which looks rather like a thread about page style philosophy. Eyal, you pretend to be a power user, but have you really seen the page style use context or used them. 1. Default Page Style: well, one needs a page style anyway; so this is the starting one 2. and 5. Endnote is the page style used when Writer lays out the end notes; Footnote has the same role when you chose to position all your footnotes at end of document. And if you don't like this automatic behaviour, you can change the page styles with Tools>Footnotes & Endnotes. These page styles are provided so that end-of-document notes have some default page style. 4. First Page may have an ambiguous name because you meet "first" pages nearly everywhere in a document: the very first page, chapter first pages, … Perhaps a better name would have been Front Cover or Title Page. It is automatically followed by Default Page Style (Next Style configuration) 7. Index is clearly intended for indexes but is not automatically applied because there is no obligation to isolate TOC, Alphabetical Index or other Table of … in a separate group of pages (think of chapter partial TOCs following a chapter heading). Segregating index in separate page is an author decision Writer cannot guess. Therefore this page style may look unused. Its name is simply a suggestion. 9. and 10. Left Page and Right Page are a consolidated pair because they are linked by their Next Style property. Unless modified they can't be used separately. But, once again, using them is an author's decision, usually motivated by the need to have different header/footer, notably positioning the page number on the outer side. Note there are however alternate ways to achieve this which can avoid the insertion of blank pages (if you untick the Same content on … box in the page style configuration). 3. Envelop: works with Insert>Envelope but needs probably to be customised to cope with your actual stationery; normally you don't invoke it "manually" as it is part of an "automatic" feature. 6. As already explained by Regina, this is the default style for HTML document, replacing Default Page Style for them; note that page styles in HTML documents are nonsense because there is no notion of "page"; to emphasise this, the page style list is disabled in the style side pane when you're in HTML mode. But you can still customise it (with visible effects) with a double-click on its name in the status bar. This leaves 8. Landscape which once again suggests a use. But as you pointed out, it may be confusing if you customised Default Page Style for landscape orientation instead of replacing the latter by Landscape when you created your document. All in all, I find the default page style list quite correctly balanced between functional utility and usage suggestion. It should encourage to discover what can be done with page styles. PS: I don't understand your point in comment #8 about the necessity to replace page style in 800 pages after some insertion. This happens frequently with DOC(X) documents because of the approximate conversion resulting in one page style per page, but should not be with adequately formatted documents. I am personally interested by the case. So, if you're willing, contact me through private mail on AskLO to discuss the mishap. We're now left with 6. and 8.
(In reply to ajlittoz from comment #19) > I just discovered this bug report which looks rather like a thread about > page style philosophy. Page style philosophy does have something to do with it, for sure... It should also be mentioned that they're not exactly page style, but really a combination of single-page style the page-sequence style of: S1 = S, S2 = NextStyle(S1), S3 = NextStyle(S2) etc. That in itself is rather confusing, and see also below. > Eyal, you pretend to be a power user, but have you really seen the page > style use context or used them. Well, I'm a power user in the sense that I've used LO for nearly 10 years and steadily for 8; I do a lot of QA work; I support other users both with LO and MSO (especially Writer); and I use LO to author both short and long, simple and complex documents, using styles and little direct formatting. But, indeed, I have so far not found use for page styles. Maybe it's just a fluke; maybe it's page styles are a bit limited (no inheritence - bug 41316, no composition - bug 149271); maybe the list of page styles available by default contains many confusing and/or redundant entries; and maybe a combination of all of the above. I'll comment only on your numbered point with which I don't agree. So, agree with (1.), > 2. ... Endnote is the page style used when Writer lays out the end notes; But: I. It's on the list of page styles for non-endnote pages. The user is somewhat baffled by being offered to make their page into an "Endnote page". Even if it's on the list - why is there no marking or designation of styles which get auto-applied? II. Why do endnotes get a special page style, while, say, bibliographies don't? Or Tables of Contents? This is not just arbitrary (a problem in itself), but makes the actual use of this page style even less obvious, since the user needs to create the mental image of the seemingly-arbitrary partial choice of what gets a special page style. III. Why is it "Endnote" rather than "Endnotes"? > 7. Index is clearly intended for indexes Points (I) and (II) about Endnote apply here. > 5. ... Footnote has the same role when you chose to position all your footnotes > at end of document. You can't. The notes you position at the end of your document are _endnotes_. Specifically, LibreOffice doesn't pretend footnotes are endnotes or vice-versa. > These page styles > are provided so that end-of-document notes have some default page style. That's not true, or not consistently true because: I. They would have a default page style anyway - Default Page Style. II. Point (II) about Endnote applies here: Other entities which also need their own page style don't have it. > 4. First Page may have an ambiguous name because you meet "first" pages > nearly everywhere in a document: the very first page, chapter first pages, … > Perhaps a better name would have been Front Cover or Title Page. It is > automatically followed by Default Page Style (Next Style configuration) I. "Ambiguous" and "nonsensical" are pretty close... II. Page (sequence) styles already have dispensation for different behavior on the first page of the sequence. Not for all features, but for headers and footers. That makes First Page at least partially redundant. Also, the fact that one can use a page break and have a completely unrelated page (sequence) style on the first page, renders this slightly more redundant. So, the page sequence style here is actually "Default Page Style + Different settings on the first page which go beyond what you can achieve by modifying the Default page style". ... except that these different settings are arbitrary, i.e. they will be whatever happened to change in the Default Page Style of the current template, but not be changed in the First Page style. That's rather nonsensical to me. I didn't mention (4.) on my initial comment. It is actually an illustration of a way to define a page sequence style, rather than a meaningful style on its own. Until 41316 is implemented - I really think it should be off the list. After that - maybe it's tolerable, but I still think another way should be found to educate the user about defining NextStyle-based "cascades" of individual page styles. > but is not automatically applied > because there is no obligation to isolate TOC, I. There is no obligation to isolate Endnotes either - they could start on the last page of text, with no page break. II. While there is no _obligation_, there is an _option_ to isolate ToCs. > Alphabetical Index or other > Table of … in a separate group of pages (think of chapter partial TOCs > following a chapter heading). What about partial indices or bibliographies following chapters? > 9. and 10. Left Page and Right Page are a consolidated pair because they are > linked by their Next Style property. They are nonsensical though. Giving an example of alternating styles may be cute, but the names are effectively inscrutable (and don't make sense even after you know what these styles contain); these styles have arbitrary properties due to not inheriting from the Default Page Style; and their supposed use-case is broken or non-existent. > Unless modified they can't be used > separately. But, once again, using them is an author's decision, usually > motivated by the need to have different header/footer, notably positioning > the page number on the outer side. Nope. As you yourself say: > Note there are however alternate ways to > achieve this which can avoid the insertion of blank pages (if you untick the > Same content on … box in the page style configuration). So alternating header/footer styles are not a use case. Neither is alternating margins due to a gutter - that's also supported in a single page style. So what _is_ the actual use case then? > 3. Envelop: works with Insert>Envelope but needs probably to be customised > to cope with your actual stationery; normally you don't invoke it "manually" > as it is part of an "automatic" feature. If it's not to be invoked manually, why is it on this list? Or, let me put it this way: If, dropping redundancies, the list consists of styles which _shouldn't_ be applied manually - why even have it? And at the same level of accessibility of Paragraph Styles and Character Styles? > 6. As already explained by Regina, this is the default style for HTML > document I replied to Regina's message. Must I repeat that reply here as well like I've repeated some other ones you've ignored? :-( > note that page styles in > HTML documents are nonsense because there is no notion of "page"; Really? https://developer.mozilla.org/en-US/docs/Web/CSS/@page > to > emphasise this, the page style list is disabled in the style side pane when > you're in HTML mode. But you can still customise it (with visible effects) > with a double-click on its name in the status bar. Why am I supposed to customize it when editing a non-HTML document? It would make sense for me to be able to customize it from outside any document. A user would absolutely not guess that editing the HTML page style in document 1 effects the default page style in (HTML) document 2. Like I said - nonsensical. > All in all, I find the default page style list quite correctly balanced > between functional utility and usage suggestion. It should encourage to > discover what can be done with page styles. I. That's because you're ignoring most arguments to the contrary. II. Even if you legitimately found it that way - I argue that the vast majority of users - don't, and it is only after carefully reading explanatory text that they will be able to understand what's what with that least. And in practice - they won't; they are very likely to just steer clear of the whole thing as some kind of bizarre voodoo.
(In reply to Eyal Rozenberg from comment #6) > I protest the non-serious discussion of this bug in the recent design > committee session. -X- I don't think certain things have to be hierarchical. they can be combined with composition. however, composition is not how style works. there is something to think about. a style can be selected from a list without overriding things that are not related to the style and the behavior of other styles at the same level. in fact, the page is a composition of its entities. the page style is a description of the properties of these entities. the page style hierarchy must depend on the hierarchy of these entities. based on falsifiability, I would prefer to consider cons, not pro. -XX- based on architectural principles, i would prefer to see from more specific things with flexible behavior to more general things with specific behavior (instability and abstraction relation). -XXX- It seems to me that it is necessary to separately and in detail describe the shortcomings associated with: - unexpected or counter-intuitive behavior, side effects, violation of the Least principles, violation of the DRY and KISS, violation of the open-closed principle. - destructive use cases, context violation, scope and lifetime violations. -XXXL- example of bad style design: https://shaunakelly.com/word/styles/custom-table-styles-2002-2003.html i.e. perhaps it would be a better solution to separate (9) and (10) into first page properties (added blanked page) and footer properties (for odd numbering). etc. Some of this has already been covered, but not in as much detail as i would like.
(In reply to Eyal Rozenberg from comment #20) > Well, I'm a power user in the sense that I've used LO for nearly 10 years > and steadily for 8; I do a lot of QA work; I support other users both with > LO and MSO (especially Writer); and I use LO to author both short and long, > simple and complex documents, using styles and little direct formatting. > > But, indeed, I have so far not found use for page styles. Maybe it's just a > fluke; If there is no use for page styles, please supply an alternative to the scenario given in comment 16. I use the Right Page style extensively to begin a chapter break, as defined by a heading style, to only begin on the right page. I do have the Right Page style set to use my normal page style for the rest of the chapter, which does have a asymmetrical, mirrored layout. Without resorting to direct formatting how do you propose this to be done? With your extensive experience, you should be well able to provide a template which would teach us how to more easily do this. > > II. Page (sequence) styles already have dispensation for different behavior > on the first page of the sequence. Not for all features, but for headers and > footers. That makes First Page at least partially redundant. Also, the fact > that one can use a page break and have a completely unrelated page > (sequence) style on the first page, renders this slightly more redundant. I use the First Page style as a title page. Works fine for me. The whole point is to have a unrelated style on the first page, since I want no headers or footers and maybe even different margins. Again, what would you propose as the proper way to do this without the use of direct formatting and manually inserted pages?
(In reply to David from comment #22) > (In reply to Eyal Rozenberg from comment #20) > for the rest of the chapter, which does have a asymmetrical, mirrored > layout. That should be: "which does have a symmetrical, mirrored layout."
(In reply to Klim from comment #21) > -X- I don't think certain things have to be hierarchical. they can be > combined with composition. Yes, you're right, in the sense that if we had composition but not inheritance, we could have a "landscape layout mixin", a "red background" mixin the user might create, etc. - and those would not need to inherit the default page style. > however, composition is not how style works. Well, it is how style (should) work, and how it works in CSS for example (and remember ODS is an XML-based document format); it's just that we haven't gotten around to implementing composition yet: bug 149271. In the mean time, style inheritance is implemented in general, so it makes sense to enable it for page (sequence) styles as well. OTOH, I wouldn't mind if the styles which need either composition or inheritance to be "legitimate" would be removed until either of the two bugs is fixed. > there is something to think about. a style can be selected from a list > without overriding things that are not related to the style and the behavior > of other styles at the same level. in fact, the page is a composition of its > entities. the page style is a description of the properties of these > entities. the page style hierarchy must depend on the hierarchy of these > entities. based on falsifiability, I would prefer to consider cons, not pro. > > -XX- based on architectural principles, i would prefer to see from more > specific things with flexible behavior to more general things with specific > behavior (instability and abstraction relation). > > -XXX- It seems to me that it is necessary to separately and in detail > describe the shortcomings associated with: > - unexpected or counter-intuitive behavior, side effects, violation of the > Least principles, violation of the DRY and KISS, violation of the > open-closed principle. > - destructive use cases, context violation, scope and lifetime violations. I... am not sure I follow what you wrote, I'm sorry. I _think_ I agree with a lot of it? Perhaps we could ask Heiko to hold a design meeting discussing this issue and you could present your view? > > -XXXL- example of bad style design: > https://shaunakelly.com/word/styles/custom-table-styles-2002-2003.html > Actually, we have rather similar problems with LO table "styles": See bug 152711 for Writer and bug 151264 for Impress. > i.e. perhaps it would be a better solution to separate (9) and (10) into > first page properties (added blanked page) and footer properties (for odd > numbering). etc. (9.) and (10.) are Left Page and Right Page. I'm not sure what you mean by making them into "first page properties".
(In reply to David from comment #16) > (In reply to Eyal Rozenberg from comment #15) > > Then you're assuming the style will do something it does not, because > > specifying "Right page" will not affect the page numbering; nor will it > > insert an extra page before your section begins (nor at section start). > > I can configure a heading paragraph style at the beginning of a chapter (and > yes, that chapter may be within a document "section") to insert a page break > with a particular page style before the heading. If I tell it to insert a > page with the Right page style, then I can set that page style to not > include a header. I can also set the Right page style to use my normal page > style as the next page, which does have headings on it. Please provide a > document template that demonstrates a better way to do this so that we all > may learn. That does not contradict what I said in the sentence you quoted. I was, and am, saying it is either difficult or impossible to guarantee that "Left Page" pages will be only-odd, or only-even, in the order of pages in a document, or will have only-odd, or only-even, page numbers. And same goes for "Right Page" of course. > If I tell it to insert a page with the Right page style, then I can set that page style to not include a header. I. Don't you mean "First Page"? II. I think that's kind of broken. The header itself is not part of the style, after all. What needs to happen is for us to be able to indicate that the sequence of pages, w.r.t. the page style, is restarting - and for that to mean we get the first page header (or lack of header) again. I'm pretty sure MS Word has this for section breaks which are also page breaks. (In reply to David from comment #22) > (In reply to Eyal Rozenberg from comment #20) > > > Well, I'm a power user in the sense that I've used LO for nearly 10 years > > and steadily for 8; I do a lot of QA work; I support other users both with > > LO and MSO (especially Writer); and I use LO to author both short and long, > > simple and complex documents, using styles and little direct formatting. > > > > But, indeed, I have so far not found use for page styles. Maybe it's just a > > fluke; > > If there is no use for page styles, please supply an alternative to the > scenario given in comment 16. I. Answered your comment 16. But I'll also say that you describe a clever use of page (sequence) styles that I haven't considered before, so I definitely learned something today. II. I misspoke. I meant use for page styles other than default one, with document-specific changes I make to that style. > I use the Right Page style extensively to > begin a chapter break, as defined by a heading style, to only begin on the > right page. But you can't be certain that it's a "Right Page"! > I use the First Page style as a title page. ... The whole > point is to have a unrelated style on the first page, That's not the whole point. The title page style is not unrelated to the main body page style (e.g. : same dimensions). Also, a title page is very often not the first page. Still, if we had Page Style inheritance or Composition, this would be acceptable, though still somewhat confusing. I wonder if it wouldn't help if a style would show it's "next", e.g. Default Page Style ↩ First Page → Default Page Style Left Page → Right Page Right Page → Left Page I mean, not that this would make all of these styles relevant, but perhaps it would, paradoxically, be less confusing w.r.t. to the page style cascading dynamics. > Works fine for me. No, it doesn't: If you change your document body's Page Style, you have to make changes to your First Page style. Again, we need inheritance or composition, and even then there's feature redundancy with the first-page-related features of individual page styles. Which is not a terrible thing, but it is at least confusing and seems like us not having properly decided how we want to do things, so that two approaches got implemented.
(In reply to Eyal Rozenberg from comment #25) > (In reply to David from comment #16) > > I can configure a heading paragraph style at the beginning of a chapter (and > > yes, that chapter may be within a document "section") to insert a page break > > with a particular page style before the heading. If I tell it to insert a > > page with the Right page style, then I can set that page style to not > > include a header. I can also set the Right page style to use my normal page > > style as the next page, which does have headings on it. Please provide a > > document template that demonstrates a better way to do this so that we all > > may learn. > > That does not contradict what I said in the sentence you quoted. I was, and > am, saying it is either difficult or impossible to guarantee that "Left > Page" pages will be only-odd, or only-even, in the order of pages in a > document, or will have only-odd, or only-even, page numbers. And same goes > for "Right Page" of course. If the Page Layout parameter in a page style is set to "Only right" (as the Right Page style is by default) and a heading style is used which is set to insert a page break before the heading, using that page style with the "Only right" setting (i.e., Right Page), under what circumstance will that page not be forced to be on an odd numbered page? I use this feature extensively. > > If I tell it to insert a page with the Right page style, then I can set that page style to not include a header. > > I. Don't you mean "First Page"? I use the "First Page" for my book title page. I don't use a header or footer there, and any or all of the margins may be set differently on that page. But for my chapter title page, I do want to keep most settings the same but remove the header. So no, I don't want to use the "First Page" style for the start of my chapter. > II. I think that's kind of broken. The header itself is not part of the > style, after all. What needs to happen is for us to be able to indicate that > the sequence of pages, w.r.t. the page style, is restarting - and for that > to mean we get the first page header (or lack of header) again. I'm pretty > sure MS Word has this for section breaks which are also page breaks. Headers, footers, footnotes, margins, columns, etc. are all definable in the page styles. Where do you propose that these options should be set? > (In reply to David from comment #22) > > (In reply to Eyal Rozenberg from comment #20) > > > I use the Right Page style extensively to > > begin a chapter break, as defined by a heading style, to only begin on the > > right page. > > But you can't be certain that it's a "Right Page"! Given the settings I described earlier in this comment, in what case will it not be on an odd number page? > > I use the First Page style as a title page. ... The whole > > point is to have a unrelated style on the first page, > > That's not the whole point. The title page style is not unrelated to the > main body page style (e.g. : same dimensions). Also, a title page is very > often not the first page. Still, if we had Page Style inheritance or > Composition, this would be acceptable, though still somewhat confusing. > > I wonder if it wouldn't help if a style would show it's "next", e.g. Under the page style settings, the style for the next page can be specified. > > Works fine for me. > > No, it doesn't: If you change your document body's Page Style, you have to > make changes to your First Page style. Why? The main body of my chapters use a totally different style, as specified by the Right Page style's "Next style" setting.
(In reply to Eyal Rozenberg from comment #24) > (In reply to Klim from comment #21) > you could present your view? I do not know the right way, but I can try to advise something simple. 1) hide or remove or move html style. 2) combine Left Page & Right Page into a book style group. 3) pass the ability to specify the order of the next style to the group. remove the next style from the style. 4) there is no more than one cycle in a group. 5) add a page break with the group leaving. 6) a group can be put into a group. 7) the group can insert a page break before the title by option. 8) the order in the group can be used to print brochures & n-up.
(In reply to Klim from comment #27) > (In reply to Eyal Rozenberg from comment #24) > > (In reply to Klim from comment #21) > > you could present your view? > > I do not know the right way, but I can try to advise something simple. > > 1) hide or remove or move html style. > 2) combine Left Page & Right Page into a book style group. I think what you're looking for would be done by setting the page layout in the Default Page Style or another style to be mirrored. > 3) pass the ability to specify the order of the next style to the group. > remove the next style from the style. I'm not sure what's meant by "specify the order of the next style." > 4) there is no more than one cycle in a group. Specifying a new page style is best done through the use of a heading. > 5) add a page break with the group leaving. This would be done by using a heading on the following page to insert a page break before the heading. > 6) a group can be put into a group. > 7) the group can insert a page break before the title by option. This would be done by setting the title paragraph to automatically insert a page break. The next page style to be used can also be specified. > 8) the order in the group can be used to print brochures & n-up.
(In reply to David from comment #28) > I think what you're looking for would be done by setting the page layout in > the Default Page Style or another style to be mirrored. > I'm not sure what's meant by "specify the order of the next style." > Specifying a new page style is best done through the use of a heading. > This would be done by using a heading on the following page to insert a page > break before the heading. > This would be done by setting the title paragraph to automatically insert a > page break. The next page style to be used can also be specified. Yes you are right. I made a bad advise. however, I consider the 'next style' field to be a dirty hack. it does a side effect and looks like a code smell. in such a case, I don't think we should display the next style in the styles list, but we could put an appropriate icon in front of the style name in list to indicate that the next style field has changed. maybe.
(In reply to ajlittoz from comment #19) > I just discovered this bug report which looks rather like a thread about > page style philosophy. I totally agree. After reading main parts of this "book" propose to close it, because at least for me it is no longer a bug report you can easiliy follow. Main problem ist, that discussion is about page styles as a whole as well as different page styles. So for me best way would be - if necessary - to diiscuss just one page style per bug. Any objections?
(In reply to Dieter from comment #30) > ... Main problem ist, that discussion is about page styles as a whole as > well as different page styles. Main problem is that a 'bug'-report is written without understanding of the topic ;) > well as different page styles. So for me best way would be - if necessary - > to diiscuss just one page style per bug. Any objections? There is the risk of trying to look at one page style isolated from the context, that may include other page styles. But... I agree to close this one. Thanks,
> (In reply to Dieter from comment #30) > So for me best way would be - if necessary - > to discuss just one page style per bug. Any objections? Yes, because if we did that, the general fault with the misuse of page styles, for things which are not page styles, would be used to argued that any suggestion of removal of an individual style. Plus, it would preclude more fundamental solutions of the problem. However - if people who have commented on this bug so far are willing to commit to not making that argument, and protecting individual bug pages from such objections, I am willing to adopt that approach. > > I just discovered this bug report which looks rather like a thread about > > page style philosophy. Some arguments were made in some of the comments, which you could call "philosophical". Still, the bug is not about materialism vs idealism or whether a god exists or not, it's about supposed Page Styles which are not really Styles of Pages, or are confusing, or otherwise don't make sense. A large fraction of UI/UX bugs are about UI elements or behaviors which don't make sense, or confuse, or are inconsistent with what they're supposed to be. We don't close them as philosophical. (In reply to Cor Nouws from comment #31) > Main problem is that a 'bug'-report is written without understanding of the > topic ;) The main problem (or one of the main problems) is that there is a _mis_understanding of the topic by people who are simply used to a faulty status quo. > There is the risk of trying to look at one page style isolated from the > context, that may include other page styles. But... > I agree to close this one. It is impolite to close people's bugs when they have not indicated they approve of the closure, without discussing it with them; and that goes doubly for people who are frequently on this Bugzilla and are likely to respond and not just disappear.
Hi Eyal, (In reply to Eyal Rozenberg from comment #32) > The main problem (or one of the main problems) is that there is a > _mis_understanding of the topic by people who are simply used to a faulty > status quo. Possibly this is a situation where the understanding (at least part) of the functionality and assumed errors in the situation, are entangled somehow? One thing that might be relevant, is that the functionality origins from a mostly TRL thinking, so that parts are indeed ask for improving. The discussion here is however way too wide for working on concrete improvements. Please allow me to challenge you to come up with one (or more) clear separate cases that are wrong (or so mal-designed that it leads to errors). Happy to look 1-1 with you to get things very clear before filing a report :)
(In reply to Cor Nouws from comment #33) > Possibly this is a situation where the understanding (at least part) of the > functionality and assumed errors in the situation, are entangled somehow? Of course, and the same goes for the assumed validity/acceptability of the situation > One thing that might be relevant, is that the functionality origins from a > mostly TRL thinking, so that parts are indeed ask for improving. I'm not familiar with the term TRL. Technology Readiness Level? That doesn't sound right. > The > discussion here is however way too wide for working on concrete improvements. Hence my suggestion about "amicably" splitting it into separate bugs. But, you know what? I'll just assume it's an acceptable suggestion, open the separate bugs, and be optimistic about people not closing them for the wrong reasons. (And if they do, I'll reopen this one.) Marking as INVALID in light of this, and will link the new bugs as related. > Please allow me to challenge you to come up with one (or more) clear > separate cases that are wrong (or so mal-designed that it leads to errors). I have come up with 8 concrete cases, most of which should be IMHO just be removed, and the rest merit some rethinking. > Happy to look 1-1 with you to get things very clear before filing a report :) How about an extraordinary design meeting, but with a commitment not to take any binding decisions, so that we don't burden those who are unable to attend to feel obligated.