https://bugs.documentfoundation.org/show_bug.cgi?id=153534
Eyal Rozenberg <eyalr...@gmx.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |41316
--- Comment #8 from Eyal Rozenberg <eyalr...@gmx.com> ---
(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.
Referenced Bugs:
https://bugs.documentfoundation.org/show_bug.cgi?id=41316
[Bug 41316] Page styles should support hierarchical parent-child relationships
(like paragraph or character styles)
--
You are receiving this mail because:
You are on the CC list for the bug.
