With OOo (and, in fact StarWriter before that) I have always been wondering why, contrary to paragraph styles, page styles are not implemented in an object-oriented fashion, i.e. all inherit from one basic page style. After my opinion this would make handling and modifying page styles much nicer, just as it does with paragraph styles, character styles, and frame styles.
It should at least be possible to link newly created derivative styles with their sources (should become parents).
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
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.
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.
Is there a plan by when this enhancement will be realized in LibreOffice (or OpenOffice). If possible I would as well like to vote for this enhancement.
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. ***
Count my vote!
I'd appreciate this enhancement to be awaken and considered again.
I fully support this enhancement request and hope for it implemented soon.
Is there a definitive simple user guide to the creation and use of style in LO?
I have been sold on the concept of styles since I first used Wordstar and have always been frustrated by poor implementation in Word.
Every now and then (at least once a year) I take down my templates and try to fix them up, but get stymied by the priority and the complexities. Especially when it comes to headings and number lists.
I am prepared to attempt such a help document if it does not exist (and I ahve nto found one in my googling), but could you point me to any material (other than the standard help) - especially which can be used to create a precedence map, and rules?
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).
+1 for implementing page style inheritance if not there are hidden technical reasons making it (next to) impossible.
Changing priority back to 'medium' since the number of duplicates is lower than 5
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.
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