Styles can inherit each other, e.g. for paragraphs "List 1" inherits "List", which inherits "Body Text", which finally inherits "Default Paragraph Font". It is possible to not-set attributes of a style, having the child style have the same attribute as the parent style. This is useful in allowing styles which are "modifiers" of the parent style. (It's not perfect though, e.g. we can't apply multiple styles at once, see 149271.) The "modifier" aspect of a style would be further enhanced if the space of possible relations of its attributes to their parent style counterparts would be richer than just "override" and "inherit". It should be possible to set style attributes _relatively_ to their parents: 1. Multiplicative relation of numeric attributes. Example: "Font weight at 125% of the parent style" 2. Additive relation of numeric attributes: Example: "1 pt less inter-character spacing than in the parent style" 3. Inverse for boolean attributes, e.g. "Merge border with next paragraph IFF parent style did not merge border with the next paragraph" One could think up more complex relations, but having these would already be quite powerful. Note that this regards almost all kinds of styles, not just Character and Paragraph.
(In reply to Eyal Rozenberg from comment #0) > we can't apply multiple styles at once, see 149271.) This is not correct. The bug 149271 has bug 115311 in its "See Also" since its creation - you added it yourself. The character styles *allow* applying several of them at once; and there is even a rudimentary UI for that. So the feature for that style category exists - but indeed, the UI has much to improve (basically, to create from scratch). > The "modifier" aspect of a style would be further enhanced if the space of > possible relations of its attributes to their parent style counterparts > would be richer than just "override" and "inherit". It should be possible to > set style attributes _relatively_ to their parents: > > 1. Multiplicative relation of numeric attributes. Example: "Font weight at > 125% of the parent style" This is already possible. See [1]: > If you are creating a style that is based on another style, you can enter a > percentage value or a point value (for example, -2pt or +5pt). See also tdf#142423. > 2. Additive relation of numeric attributes: Example: "1 pt less > inter-character spacing than in the parent style" While it is shown above that this is already possible for font sizes, it is unclear what exact use case would it serve for inter-character spacing. Any feature should only be created to implement some specific need, not just because we can. The overall complexity makes every new feature a source of problems for quite large number of users, so unless this solves a real problem for many users, I disagree that we should do this. > 3. Inverse for boolean attributes, e.g. "Merge border with next paragraph > IFF parent style did not merge border with the next paragraph" Same as above. See also Conditional styles [2], which addresses e.g. "Footer" and "Blockquote" case mentioned in bug 149271. [1] https://help.libreoffice.org/7.5/en-US/text/shared/01/05020100.html?DbPAR=WRITER#hd_id3151054 [2] https://help.libreoffice.org/7.5/en-US/text/swriter/01/05130100.html?DbPAR=WRITER#bm_id3154656
(In reply to Mike Kaganski from comment #1) > So the feature for that style category exists - but indeed, the UI has much to > improve (basically, to create from scratch). And for other style categories, the idea is challenged in bug 149271 comment 2.
(In reply to Mike Kaganski from comment #1) > (In reply to Eyal Rozenberg from comment #0) > > we can't apply multiple styles at once, see 149271.) > > This is not correct ... So the > feature for that style category exists - but indeed, the UI has much to > improve (basically, to create from scratch). Yes, you're right, I should have said "we can't effectively apply". > > 1. Multiplicative relation of numeric attributes. Example: "Font weight at > > 125% of the parent style" > > This is already possible. See [1]: That's only one single feature, in one (or two) kinds of style. I'm talking about all of them. Like: Vertical space after paragraph. > Any > feature should only be created to implement some specific need, not just > because we can. The specific need is being able to define styles progressively as one moves down the hierarchy. With my example above: I want to be able to increase or decrease the spacing after all Heading N lines, with each of them increasing by the same factor. I can't do that right now. > The overall complexity makes every new feature a source of > problems for quite large number of users, so unless this solves a real > problem for many users, I disagree that we should do this. I am actually betting that this is not complex as an ODF feature. But - I realize this could potentially be quite complex in terms of the UI. There are different avenues for dealing with the expression of such complexity, which merit discussion IMO; at worst, there could be an ability for advanced users to edit a textual or semi-textual representation of the everything the style changes relative to its parent (similar to what we currently have in read-only form in the organizer), and in this representation, the relative-ease of the ODF level could be more readily expressed.
(In reply to Eyal Rozenberg from comment #3) > The specific need is being able to define styles progressively as one moves > down the hierarchy. With my example above: I want to be able to increase or > decrease the spacing after all Heading N lines, with each of them increasing > by the same factor. I can't do that right now. Programmatically creating styles is not a common use case to me but could be done per macro anyway.
(In reply to Eyal Rozenberg from comment #3) > > Any feature should only be created to implement some specific need, not > > just because we can. > > The specific need is being able to define styles progressively as one moves > down the hierarchy. With my example above: I want to be able to increase or > decrease the spacing after all Heading N lines, with each of them increasing > by the same factor. I can't do that right now. This is not fair. This is not a real use case - unless you claim that it is: is there a real typographic case where such a requirement is used? I would assume *your* case to be the case for the sake of argument. And the opposite can be said about the font size: it is common for people to change their decision about the font sizes on text; and it is reasonable to expect that e.g. headings are enlarged in parallel, keeping higher levels bigger than lower levels.
(In reply to Heiko Tietze from comment #4) > Programmatically creating styles is not a common use case to me but could be > done per macro anyway. I didn't talk about doing anything programmatically. When considering - and experimenting with - a document's styles, which happens in any new document that's not in an exact same style you used before - you want to make some changes that affect multiple (or all) styles. Right now, you can only do that for very few attributes, like the direction for example. But it is quite common to want to play with/change the spacing before and after heading paragraphs. With this feature, you would not have to change N heading styles to see the effect of a 20% relative increase for all headings (or perhaps even - for all paragraphs). This spacing tweaking is also frequent when a document's content is ready: You want to control how many pages it will occupy, and so tweak various spacing settings (inter-line, after, before paragraph, as well as maybe margins etc.)
(In reply to Mike Kaganski from comment #5) > This is not fair. This is not a real use case I personally do this with every... say, third multi-page document I write. Except I have to manually tweak the spacing of styles. I also do this for font sizes, and there we do the ability to specify sizes relatively, so it's better.
Do you know the "Document Theme" (available in the sidebar if experimental features is on)? Not what you are looking for but improvements there make more sense.
(In reply to Heiko Tietze from comment #8) > Do you know the "Document Theme" (available in the sidebar if experimental > features is on)? Not what you are looking for but improvements there make > more sense. No, and - I didn't realize there was a toggle for experimental features.
Please try the Document Theme feature. Improvement suggestions here very much welcome but we shouldn't invent another wheel on the already six-axle car.
I might have concerns about a specific proposal; I might consider it WONTFIX if it has a potential of bad usability or other important issues; but I can't agree with *valid* proposals marked INVALID. In this case, I still think that it should be WONTFIXed; and at the same time, I suppose that the *specific* example (paragraph spacing) can get a *targeted* improvement. It could be the relative to parent (percentage) value; or maybe it could be chosen to be represented in *count of lines* (which would depend on font size, which already allows relative sizing) ... and if other properties of some styles need similar changes, they should be considered one by one, until it really becomes reasonable to have some *universal* mechanism.
(In reply to Heiko Tietze from comment #10) > we shouldn't invent another wheel on the already six-axle car. The basic "car" is ODF. At that level, no wheel invention is necessary, just allowing a little more flexibility in specifying values. Thus, instead of just allowing an absolute setting, e.g.: <style:style style:name="my_style" style:family="paragraph" style:parent-style-name="Standard"> <style:paragraph-properties fo:margin-bottom="0.15in"/> </style:style> We would also allow: <style:paragraph-properties fo:margin-bottom="150%"/> and <style:paragraph-properties fo:margin-bottom="+0.05in"/> and maybe <style:paragraph-properties fo:margin-bottom="+50%"/> > Please try the Document Theme feature. How can I do that? Anyway, that feature would probably be strengthened by this capability: If some styles are part of the document theme, or take features from the document theme - inheriting styles could be influenced by the document theme without only using _identical_ features.
(In reply to Mike Kaganski from comment #11) > and at the same time, I suppose that the *specific* example (paragraph spacing) can get a *targeted* improvement. ... until it really becomes reasonable to have some *universal* mechanism. But Mike, the mechanism will almost certainly be the one above, which is actually quite general. This bug is not strictly, or even not basically, about the UI, but the capability. If that's in place, there would be the discussion of how to expose it in a way which doesn't clutter the UI. Perhaps some features will have more exposure, and others less. At any rate, initially nothing will be exposed, and exposure may require "targeted" issues. ------------ (not part of the reply) but I should mention a few points of difficulty: * When inheriting from multiple styles, it may not be clear which is the parent to which to relate additions, multiplications, flips etc. Solution: If all of the parents which have the relevant feature set (directly or by inheritance) agree, then the agreed value is used; otherwise, setting a relative value is an error. * There is setting relative to the parent style, and setting relative to a style in another family. Specifically, CS settings relative to PS settings, or to the default CS of a PS. How should that be treated? As a "weak parent" in addition the "proper parent" of the CS? * Categorical settings (i.e. several discrete options which aren't necessarily ordered) don't typically admit some universal relative settings. And yet - for some of these, relative settings may be interesting. Example: A flipped direction
(In reply to Eyal Rozenberg from comment #12) > The basic "car" is ODF. (In reply to Eyal Rozenberg from comment #13) > This bug is not strictly, or even not basically, about the UI, but the > capability. If that's in place, there would be the discussion of how to > expose it in a way which doesn't clutter the UI. Perhaps some features will > have more exposure, and others less. At any rate, initially nothing will be > exposed, and exposure may require "targeted" issues. This shifts this problem to the OASIS. The rationale is: it is OK to ask for some *program functionality* here, that could require ODF change; the functional change can be implemented in LibreOffice together with a proposal to OASIS, and then serve as some "reference implementation" in the OASIS discussion, helping understand the issue and proposed solution visibly. However, in this case, you yourself limit it to the format issue. Then there's nothing to do in LibreOffice, until it exists in the standard. Send a mail there: https://lists.oasis-open.org/archives/office-comment/
(In reply to Mike Kaganski from comment #14) > However, in this case, you yourself limit it to the format issue. Then > there's nothing to do in LibreOffice, until it exists in the standard. But how is this case different than other request functionality that would required some changes to the ODF specification? e.g. my bug 148479?
(In reply to Mike Kaganski from comment #14) Also... > Send a mail there: https://lists.oasis-open.org/archives/office-comment/ That mailing list is almost dead: It has had about 5 messages since May 2022, and only one message during that time was a reply. So isn't sending a message there just sounding a "voice in the wilderness"?
(In reply to Eyal Rozenberg from comment #15) In that (WF IMO) case, you are telling about *program functionality*, and that could require a format change; as I mentioned, in this case I'd start with document model extension (unrelated to the file format); then created a UI; and only then extend ODF (using an app-specific extension) to store/load the data. And at the same time, I'd submit the proposal to OASIS. In your case, you suggest something that should not include first and second pieces. You suggest to implement those separately, and when the file format piece is in place.
(In reply to Eyal Rozenberg from comment #16) No. The mails get attention; my proposals (e.g. https://lists.oasis-open.org/archives/office-comment/202109/msg00000.html) resulted in https://issues.oasis-open.org/browse/OFFICE-4112 (still WIP). It's low-volume, yes.