Description: In traditional typography, a way to highlight a portion of text is to typeset it with the "complement" of an attribute. E.g. if main text is roman, this portion will be italic and vice versa. What is targeted here are the settings in the Font tab of style dialog and to a lesser extent those in Font Effects. It is presently impossible to follow this rule in Writer in an automatic way and the attribute must be forced (either set or unset) in the linked style according to what is set in the parent style. When the attribute is changed in the parent style, the linked style(s) must be reviewed to negate the setting wrt the parent. That is a new possible value "toggle" must be added to the present ones "unset" (as per the Standard button), "forced on" and "forced off". The situation is even worse, considering the attribute is frequently non-binary (e.g. font family Univers counts tens of values for bold, other families may offer several slant angles for italics), which means "toggling" the attribute is in fact a choice of another member of the family and not simply ticking a checkbox. When using direct formatting, toggling is easy but manual: just (un)press the "B", "I', "U" or "S" (though many choices are possible in these two latter cases) buttons in the toolbar. How could this be accomplished in a style definition? Things become complicated when you consider not independent paragraphs (involving only paragraph styles) but highlighted words inside a paragraph. Here you must prepare two character styles and apply one or the other, knowing what is in the paragraph style. When the paragraph style is modified, you are confronted to a huge task because you must drive the cursor across the paragraph to discover which character styles were applied and see if they must be swapped. There we would need to specify that toggling does not apply to the parent character style but to the "dynamic" paragraph style into which it occurs. To avoid conflict with inheritance (which is also useful among character styles), yet another value must be defined: "toggle para" in addition to "unset", "forced on", "forced off" and "toggle [parent]". I have a particular use case where I modified Source Text built-in character style to use a specific fixed-pitch font. However, its x-height was too large for my font in Body Text paragraphs. To restore nice merging of highlighted words in text, I had to force font size to 80%. But when I used Source Text in footnotes, this was of course too large because the 80% applied to the default font size, not that of Footnote. Defining as many derived Source Text as possible contexts is not reasonable. So having a way to "toggle para" (in fact "force para") for the font size would have done the job. I see a general usefulness to this feature beyond ease of global styles design. Document tuning would be greatly enhanced and maintenance made lighter. Nevertheless there are many details to be discussed to see how it can be integrated within the present Writer frame. Steps to Reproduce: None Actual Results: This is new. Expected Results: New inheritance rules between para/para, char/char and char vs. para styles. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Seems you are talking about two topics. The first is the "complementary" highlighting. Highlighting parts of the paragraph is done by character styles with, for example, strong emphasis to make the selection bold. If you change the paragraph style itself to bold your emphasis wouldn't work anymore. But I disagree with a toggle feature, that's not how word processors work. Furthermore it's a good idea to not modify the mother of styles if you use different children. That brings me to the second topic, which is the hierarchy/dependency. This topic is being discussed in another ticket; don't find it right now. I vote to resolve this issue as WONTFIX.
@Heiko Tietze: I think there is a misunderstanding on my proposal. What I'd like to have is a way to set style attributes depending on the current value in the parent style. Presently, you can only force values (either set or cleared) or keep the parent ones (button "Standard"). When you want to "contrast" against the parent, you must know the parent value to set it differently, leading to duplication of styles to be sure one is available for the desired effect (e.g. italic in a roman paragraph or roman in an italic paragraph). This goes against ergonomics and induces manual editing when something is changed in parent style. It's like applying direct formatting in a higher layer of styling. This is what you qualify as my "first" claim. My second claim is related to my new "relative" attribute value and the mixture between paragraph/character styles. In the present Writer (ODF?) state, these style families are completely separated: inheritance rules are internal to the family and define what will be applied. That is, character styles attributes are set according to character style ancestors, full stop, and are "stamped" over the basic paragraph attributes. I mentioned in the initial post that traditional typographic rules are rather "relative" than "absolute" and that can't be translated in the paragraph/character styles use because families are segregated. So this is my second claim: if the first claim is implemented, there is a need to indicate that the final attribute values in a character style (after applying inheritance rules) are "relative" to those of the paragraph style. I understand this implies a lot of work inside Writer and I'd be glad to read the other ticket to see how it relates to mine. >I vote to resolve this issue as WONTFIX. It is not clear if this statement is against the whole proposal or against the second part of it only. Do you know of any workaround for the first part?
(In reply to ajlittoz from comment #2) > Do you know of any workaround for the first part? You can always write an extension that toggles a property. Wouldn't be too hard, I guess. My WONTFIX opinion is for both claims, sorry :-)
@ajlittoz I have also been thinking about and fighting with these sorts of problems. I don't know off hand, but I suspect that what you want to do (both toggling attributes and making attributes of character styles relative to the paragraph style) probably isn't possible within the ODF standard. If you look at bug 108498, for example, we determined that percentage font sizes in a character style are based on the parent character style. There is no way to have a percentage font size relative to the surrounding paragraph style in ODF. If this is true in the current case, then I doubt these features would be considered by the developers regardless of UX concerns. @Heiko Tietze Correct me if I'm wrong, but I don't think an extension will help. The (1st) issue is not really about the simple act of toggling a particular property in the interface (say, with an extra toolbar button), but changing how styles work to support toggling of arbitrary properties. This sounds like a very ambitious undertaking, and files created with such an extension wouldn't open properly for anyone without the extension.
@Kenneth Hanson I went through bug 108498 and it confirms that paragraph and character styles are in their own hierarchies without links between each other. >I suspect that what you want to do … probably isn't possible within the ODF standard. I haven't read ODF, so correct me if i'm wrong. IMO, ODF describes how the stored file looks like so that conforming implementation can read it and retrieve information from it to display as the writer semantically intended. A document processor adds an "ergonomics layer" over the standard so that an average user can insert the XML elements with a few clicks or keyins without knowing all what's happening in the backstage. The UI decouples file ODF internals from user action to get document layout. As long as you find a way to convert typographical concepts into a sequence of XML primitives, even if contorted a bit, you don't need to change the standard. For instance, when importing .doc or .docx documents, the import engine creates many "anonymous" character styles to translate intra-paragraph formatting because the concept does not exist in MS Office. I'm wondering, for my case, if such a workaround could be possible, eventually using mangled styles names to signal to LO Writer that the style has special dynamic properties, e.g. adding some _<hexadecimal-encoding>_ just like we have _20_ to encode a space. The idea is to make the special properties "transparent" or "neutral" if document is opened with something different from LO Writer and fully processed in an extended LO Writer. In this strategy, the burden of handling the extra style properties is pushed from ODF layer to LO Writer processing layer. Tell me if that makes sense. I am fully aware that there is a considerable distance from idea to implementation, though. Also, I'm confident that ODF will evolve sooner or later (certainly rather later) in the direction sketched, i.e. the possibility for character styles to be context (paragraph) aware. "Toggling" is another issue because "toggle" is difficult to define (what is "bold" for instance? You have many weights in a single family. What is "italic"? You may have several slant angles.)
Adding Regina to CC list. The only OASIS note that I could found for such or similar behavior is https://wiki.oasis-open.org/office/User-defined_character_and_paragraph_styles but that's from 2008 and probably outdated.
(In reply to Thomas Lendo from comment #6) > Adding Regina to CC list. The only OASIS note that I could found for such or > similar behavior is > https://wiki.oasis-open.org/office/User- > defined_character_and_paragraph_styles but that's from 2008 and probably > outdated. I don't think the note addresses the same topic. There, the proposer would like to specify a named character style in paragraph style. I think it is already implemented, but the other way round. The character properties in the paragraph style are names "Default Style" among the character styles. Reusing character properties in other paragraph styles is achieved with inheritance (parent style hierarchy). The only case where the proposal would bring a bonus is when you have a complex style hierarchy which cannot be represented as a tree (multiple inheritance), but I didn't ponder seriously on it to see if it makes sense in document style organisation. I could not build at once of a practical use case. Perhaps copy the character properties from two levels up, but this likely betrays a badly designed hierarchy.
Technically, you can nest character styles. Bug 115311 is on the agenda in respect to a UI solution. But you lost me on the way from "toggle font attributes" to "multiple inheritance" (of paragraph and character style). (In reply to Kenneth Hanson from comment #4) > Correct me if I'm wrong, but I don't think an extension will help. I'm stuck at _toggle_ and you could introduce a function that checks whether the selection is bold/italic/etc. and apply regular/etc. or vice versa.
ODF and OOXML have a style hierarchy. HTML and XSL-FO use CSS and have an element tree hierarchy. [I don't know about EPUB, which uses CSS too.] Therefore ODF has e.g. to explicitly change the inheritance for the fo:font-size attribute, which refers to CSS in XSL-FO. I think, that there exists no general solution because of this different designs. But there might be additions for individual properties. The percentage value of the font-size is a candidate for an addition for me. But I can not tell right away which construction would make sense.
(In reply to Heiko Tietze from comment #8) > … But you lost me on the way from "toggle font > attributes" to "multiple inheritance" (of paragraph and character style). > Sorry for that. Comment #7 was a reply to Thomas Lendo's comment #6 as a discussion on his note link to explain why the note seemed to me unrelated to my proposal. I apologise if it oriented the discussion on multiple inheritance (CSS-like) rather than the dynamic relationship between paragraph and character styles at time of application (rather than presently at time of definition within their own hierachy)
The discussion has become silent here. The idea was to have a style "Emphasis" that makes font _italic_ for text body (with regular font weight) and _regular_ when applied at a citation, for example, where the weight is italic. This typesetting is common and required but a rare use case. And I doubt we can implement it in a generic way. It would be three states: ignore - meaning keep what is defined, set/on or unset/off, and toggle - meaning invert what is defined on the parent. But how to toggle non-binary attributes or considering bug 35538? We have conditional PS, see https://help.libreoffice.org/latest/en-US/text/swriter/01/05130100.html. I bet the number of users are countable. Ultimately it's not a big deal to define two styles and toggle manually the right one. Resolving WF, feel free to reopen.