in LibO 3.6.0 master field "Linked with" is still grey (not possible select)

I think this feature request could be reformulated in a more general way:

We should allow page styles to be based on each other in an hierachical way, just like page styles and character styles, using the 'Linked with:' popup menu in the first tab of the Page style dialog.

I see at least four points which show the importance of this request:

1) Consistency with page styles and character styles would be improved, and therefore the user experience.

2) The first tab of the Page style already contains the 'Linked with:' popup menu, it is just not enabled (as already pointed out by Sasha in comment #2). This suggests, at least for the understanding of an ordinary user, that this feature is already planned and just not yet implemented/completed.

3) This feature would it make easier to apply the common formatting consistently to all/plenty of the page styles in a document. For example, I had to edit a 300pp. proceedings volume (a 'Sammelband' in German) with different essays by different authors. To get the different page headings right (incl. the name of the author and the title of his essay), I used one page style per essay. This works fine. But when I wanted to change the page margins, I had to apply this change to all the page styles one by one. If I could base these page styles on one base style, changing only the header contents, it would be possible to change the common attributes of all these page styles (like the page margins in my case) with one action. This would allow much (a) faster and (b) more consistent changes to the page layout. The consistency of page styles is very important for professional publishing, of course.

4) Implementing this feature would also help to prevent situations and misunderstandings like in bug 35900. In this report, a user reported that the "last page loses headers footers". His document had a single endnote; for this endnote LibreOffice used the 'Endnotes' page style (correct!); the user had already added headers and footers to the 'Default' page style and wondered why they did not appear on the last page (the one with the endnote). If the 'Endnote' page style was based on the 'Default' page style, adding header and footer to the 'Default' page style would add them to all other page styles, including the 'Endnote' page style; the misunderstanding would not have occured. (If one WANTS to disable footer and/or header again on a page style based on the 'Default' style, this would be still possible by editing this particular page style.)

I agree with the other notes.

Most of us users do not have the time to tinker with styles and in fact, most users find Styles incomprehensible (I wonder what percentage of MSOffice users actually use styles, in spite of their power to save time and improve document manageability). It is just too confusing to them - not to speak of setting up list styles, even I as a person who will take the time - a whole day sometimes - to set up a template for myself - find it is a trial and error / hit and miss task. I cannot figure out what the logic is behind it. There is some inheritance, clearly, but it seems to be ditched for whatever reason.

Also, once one has set a style, it is hard to revert to the default without deleting the style and starting over.

It would be better if there were a reset button that reset everything to the parent style, so that one can then modify with that as the consistent basis. (In fact, to be intuitive, the RESET should apply to the attributes that are in view on the TAB, not to the whole style.)

When "structured development" was first put forward by Yourdon, De Marco and others, they emphasised the principles of 
-- low binding
-- high cohesion

This laid the groundwork for object orientation. Every object is atomic, and receives changes by way of data passed to it in a controlled fashion. The sloppiness of MS until fairly recently and the adoption of a "good enough" paradigm was not useful and influenced far too many developers.

Fact is there is no free lunch. Quick and dirty IS always dirty and seldom quick.

IBM's findings of the TCO (Total Cost of Ownership) of software is still true today: that there is an exponential increase in the cost of fixing a defect depending on when it is discovered and repaired. Both in time and cost. And Open Source is as costly to create and use even if it has no price. In fact, given the improvements in development tools, the difference between in-development cost and in-use cost is probably far more pronounced. 

One of the most important attributes of the Quality Criteria: Stability and Useability is internal Integrity, which includes Consistency and Reliability (that the software works every time as you would expect it to.)

But that does not change the fact that we owe you developers a huge debt of gratitude for the work you do.

Thank you.

One very often situation with page styles: we need page numbers on some pages and no page numbers or Roman numbers on another pages. It is necessary in such situation to use two different page styles, but they differs only by presence of page number, all other parameters all identical, and user may expect that changing something, for example page margin, will change it in all pages. In such situation it is naturally to create new page style and set previous page style as parent, then only change header or footer.

(In reply to comment #4)
> Also, once one has set a style, it is hard to revert to the default without
> deleting the style and starting over.
> 
> It would be better if there were a reset button that reset everything to the
> parent style, so that one can then modify with that as the consistent basis.
> (In fact, to be intuitive, the RESET should apply to the attributes that are
> in view on the TAB, not to the whole style.)

IMHO this is a very good idea. Even now, while we don't have base styles for page styles, such a button would be very useful for paragraph styles and characters styles. Therefore, please file a separate enhancement request for this issue (and add me to the CC list, I want to second that request ;-). Thank you very much!

Hierarchical page styles would be a great help in many situations. But I modified the summary line a bit: Hierarchical linkage is only optional with paragraph or character styles, you can select "[none]" as parent. So not all styles are children of "Default", not everyone has a parent...

Hierarchical relationships are supported for paragraphs, characters and frames. Page and number styles don't support parent-linkage, for no apparent reason.

Hi together,
FYI (& FYA) I've added this bug to the list of enhancemts in LibreOffice: https://wiki.documentfoundation.org/Vote_for_Enhancement
If you like I would suggest to vote for this enhancement.
Thx & Regards

*** Bug 94647 has been marked as a duplicate of this bug. ***

Currently inheritance is not supported by the file format. The needed attribute style:parent-style-name is missing, because the <style:page-layout> element is not child of a <style:style> element. Such new feature will only be possible in extended mode anytime soon.

Elmar: Please go to forum or mailing list for such discussions.

*** Bug 119291 has been marked as a duplicate of this bug. ***

Comment: I would welcome the enhancement tremendously.  In fact, I strongly need an opportunity to copy a page style (in my case, creating a copy of an already changed "Default" page style).

Changing bug priority back to high since the number of people in CC is higher than 20

(In reply to Regina Henschel from comment #14)
> Currently inheritance is not supported by the file format. The needed
> attribute style:parent-style-name is missing, because the
> <style:page-layout> element is not child of a <style:style> element.

Regina, is it now possible with ODF 1.3?

(In reply to Dieter from comment #20) 
> Regina, is it now possible with ODF 1.3?

No, it is not possible in ODF 1.3.

ODF 1.3 gives the possibility to use <style:drawing-page-properties> in Writer and Calc too. That allows e.g. gradient fill (not implemented for Calc yet). But an attribute for reference to a parent does still not exist.

@Michael,
I think this qualifies to be on the radar (old, huge CC list, useful) and currently "simply" bureaucratic question of getting they (odt) specification process done

I'd love to see this. For example, I publish many books in different sizes. I have 5 basic page styles in each book. Changing the trim size of the book requires changing each page style, one by one. It would save me time, effort, and - most important - chance of error if I could simply change the page size one time, and have that flow to all subsidiary page styles.

Please, PLEASE!
This request has been in for 11 years now, and it has been urgent for me all this time.
Please make it possible to make a page style that is just slightly different from an existing page style. Copying (on paper!) the parameters of a style and re-entering them into the new style is time consuming. Moreover it is error prone, because if I make a change to the original style, the change will not be inherited, so I have to modify both separately.

Please do something about this promptly!

(In reply to R. Becke from comment #9)
> Hi together,
> FYI (& FYA) I've added this bug to the list of enhancemts in LibreOffice:
> https://wiki.documentfoundation.org/Vote_for_Enhancement
> If you like I would suggest to vote for this enhancement.
> Thx & Regards

I wanted to vote for this but I can see this on the screen:

> This page has been deleted. 
> ...
> The LibreOffice Bugzilla bug tracking system does not support ''Votes'' for requests as it is available for OpenOffice.org

I don't understand this. AFAIK, OOo and LO are independent and OOo is more-or-less abandoned. How could I vote for this bug in order to put it into the focus of the LO developers?

(In reply to csongor from comment #26)
> > The LibreOffice Bugzilla bug tracking system does not support ''Votes'' for requests as it is available for OpenOffice.org
> 
> I don't understand this. AFAIK, OOo and LO are independent and OOo is
> more-or-less abandoned. How could I vote for this bug in order to put it
> into the focus of the LO developers?

It means that "unlike OOo bugzilla, where such a feature is enabled, LibreOffice bugzilla does not support voting; and for that reason, the wiki page was deleted", not some "we delete this, because there is such a thing in OOo".

Bear in mind that most contributors are not native English speakers.

(In reply to Mike Kaganski from comment #27)
> It means that "unlike OOo bugzilla, where such a feature is enabled,
> LibreOffice bugzilla does not support voting; and for that reason, the wiki
> page was deleted", not some "we delete this, because there is such a thing
> in OOo".

I understand the meaning of the sentence, I just don't understand the logic behind it. :)

How can I vote for a bug to put it into the focus?

The documentfoundation isn't OASIS.

Suppose comment #21 by Regina Henschel is still relevant.

Will there be an ODF 1.4 or 2.0 in the "near" future?

(In reply to csongor from comment #28)
> How can I vote for a bug to put it into the focus?

You can't. Voting means basically nothing, because the project doesn't mandate any developer what to work on. E.g., TDF can't tell me: "Mike, there is this bug 41316, it has N votes, so go and implement it". So any such enhancement only gets developer attention when the developer is interested themselves (e.g., they are among the voters; or the developer is hired to implement this; or the developer is curious / knows some free time and feels it entertaining, etc.). Thus, voting is mostly useless.

Having yourself in CC list affects bug "importance" a bit - so there is some potential that most watched bugs would at some point be picked by TDF for a tender (but there is a separate wiki page for those, IIRC).

https://wiki.documentfoundation.org/Development/Budget2022

(In reply to Wolfgang Jäger from comment #29)

Note that having this feature implemented does not require formal ODF support *first*. To the contrary, I suppose that having this implemented as a LO-specific extension to the standard would help the standardization, as "working implementation exists" (this helps at least in some standardization bodies like C++ committee, so possibly also in OASIS - Regina could tell if I'm mistaken).

However, a good *proposal* to OASIS (if not yet filed) would be good, and possibly would serve as initial implementation guide.

(In reply to Mike Kaganski from comment #30)
> (In reply to csongor from comment #28)
> > How can I vote for a bug to put it into the focus?
> 
> You can't. Voting means basically nothing, because the project doesn't
> mandate any developer what to work on. E.g., TDF can't tell me: "Mike, there
> is this bug 41316, it has N votes, so go and implement it". So any such
> enhancement only gets developer attention when the developer is interested
> themselves (e.g., they are among the voters; or the developer is hired to
> implement this; or the developer is curious / knows some free time and feels
> it entertaining, etc.). Thus, voting is mostly useless.
> 
> Having yourself in CC list affects bug "importance" a bit - so there is some
> potential that most watched bugs would at some point be picked by TDF for a
> tender (but there is a separate wiki page for those, IIRC).

Sad news, thanks. 

It is especially sad to see that the list of bugs cannot show the number of Ccs, and I cannot even search for the ones that have many of them. Based on this, I believe nobody cares which bugs are needed by more people.

(Strange that I filter by the number of votes and I can even turn on the column of the number of votes but obviously all values are 0. Letting displaying votes when they are turned off seems to be only a bugzilla bug.)

(In reply to Mike Kaganski from comment #32)
> (In reply to Wolfgang Jäger from comment #29)
> 
> Note that having this feature implemented does not require formal ODF
> support *first*. To the contrary, I suppose that having this implemented as
> a LO-specific extension to the standard would help the standardization, as
> "working implementation exists" ...
> 
> However, a good *proposal* to OASIS (if not yet filed) would be good, and
> possibly would serve as initial implementation guide.
Due to age, slowness, and the missing mound I can't pitch that ball. Sorry.

(In reply to csongor from comment #33)
> It is especially sad to see that the list of bugs cannot show the number of
> Ccs, and I cannot even search for the ones that have many of them. Based on
> this, I believe nobody cares which bugs are needed by more people.

At least you can the comments as a column to the bug list. And the advanced search has also some nice features. 
We have 362 bugs with high/highest importance and picking the one to vote for is likely not so easy. Ultimately, QA tags bugs/enhancements by some attributes and sets the importance respectively. 

critical = 1
major = 189 
normal = 85
minor = 15
trivial = 
enhancement = 63

https://bugs.documentfoundation.org/report.cgi?x_axis_field=bug_severity&y_axis_field=component&z_axis_field=&no_redirect=1&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&resolution=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&priority=highest&priority=high&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&emaillongdesc3=1&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1=&format=table&action=wrap

(In reply to Mike Kaganski from comment #32)
> (In reply to Wolfgang Jäger from comment #29)
> 
> Note that having this feature implemented does not require formal ODF
> support *first*. To the contrary, I suppose that having this implemented as
> a LO-specific extension to the standard would help the standardization, as
> "working implementation exists" (this helps at least in some standardization
> bodies like C++ committee, so possibly also in OASIS - Regina could tell if
> I'm mistaken).
> 
> However, a good *proposal* to OASIS (if not yet filed) would be good, and
> possibly would serve as initial implementation guide.

Mike, you are right in principle. Only that the ODF TC recommends that the developer contacts the ODF TC very early and is willing to work together with the TC. For details see https://wiki.oasis-open.org/office/ProposalTemplate%20ODF%201.4

(In reply to Regina Henschel from comment #14)

> Currently inheritance is not supported by the file format. The needed attribute > style:parent-style-name is missing, because the <style:page-layout> element is > not child of a <style:style> element. Such new feature will only be possible in > extended mode anytime soon.

(In reply to Regina Henschel from comment #21)
> (In reply to Dieter from comment #20) 
> > Regina, is it now possible with ODF 1.3?
> 
> No, it is not possible in ODF 1.3.
> 
> ODF 1.3 gives the possibility to use <style:drawing-page-properties> in
> Writer and Calc too. That allows e.g. gradient fill (not implemented for
> Calc yet). But an attribute for reference to a parent does still not exist.

From a file format perspective, are these two items the only stumbling blocks.
( Hand-waving aside implementation related issues.)

*** Bug 156203 has been marked as a duplicate of this bug. ***