When I have a character or paragraph style which includes a font size setting, and I want to remove that setting, e.g. only have a boldness setting, or a font family choice - this is difficult / not obvious / not possible to do. It should be the case that if you erase the size in points in the combo box, it stays erased, to signify "no change". Instead, the minimum value of 2pt is is inserted when I try it. It should perhaps also be possible to remove changes due to the character style from the Organizer pane of the Style dialog (The "Contains" listing).
Don't get it. Let's say you inherit a style from Default and set font size to 18. What exactly is difficult to revert? Just edit the style and set size to 12. In the course of discussing bug 38194 we came up with the addition to selectively revert style properties. Guess this would solve your request. *** This bug has been marked as a duplicate of bug 38194 ***
(In reply to Heiko Tietze from comment #1) > Just edit the style and set size to 12. But it's not 12. The Default character style is whatever size the paragraph style sets the font to.
(In reply to Heiko Tietze from comment #1) > Don't get it. Also, if you didn't understand exactly what the reporter meant, please extend them the courtesy of waiting for an explanation before closing the bug. I know that impetus of closing bugs I'm supposed to address and are "on me", but still...
I have to admit that reverting a property remains in this exact value. And in some rare cases this may spoil the inheritance (eg. Default = 12, Default.Big = 12, after reverting it from 13, Default.Test.Bold... -> and .Bold would stay 12 even when Default changes). But I'm against means to revert style properties by deleting the value. This procedure is not clear to the average user nor it is common. We should rather provide an option with the styles inspector, see bug 38194. Alternatively, a dedicated button on the property could also work transparently. But my take is still to make this a duplicate.
@Eyal: To go back to the "inherit" mode use the "Standard" button in the dialog. To see, whether an attribute is set, use the "contains" section in the "Organizer" tab. I agree with Eyal, the current UI is bad. If you are on a tab with settings: you can not see, which of the attributes is inherited or not, you cannot put a single attribute back to "inherit" mode, you cannot set an attribute to the same value as the parent, but be not inherited, you don't know, which of the attributes on a tab page will loose the "inherit" mode, when clicking on OK. Currently the description of the "styles inspector" in bug 38194 does not contain, how to change an attribute value or to go back to "inherit" respectively. It is not clear, whether it will be a pure inspector or not.
(In reply to Regina Henschel from comment #5) > Currently the description of the "styles inspector" in bug 38194 does not > contain, how to change an attribute value or to go back to "inherit" > respectively. It is not clear, whether it will be a pure inspector or not. Talked with MikeK about this and planned to update the mockup with his ideas. My point is not the need to reset individual properties but where and how we place the interaction.
Adding a concrete suggestion: It would help (though not fully resolve this issue IMHO), if the different pieces of text in the "Contains" listing (under "Organize" in the style dialog) would be clickable (or right-clickable), with the click effecting a removal, i.e. a reversion to inheriting the setting.
(In reply to Regina Henschel from comment #5) > @Eyal: To go back to the "inherit" mode use the "Standard" button in the > dialog. To see, whether an attribute is set, use the "contains" section in > the "Organizer" tab. 1. "Standard" does not seem to put things back in "inherit" mode. 2. Pressing "Standard" does not make various boxes unset in the dialog pane you're pressing it on. 3. "Standard" - if/when it works - regards all settings on a pane, I want to unset individual settings.
Bug 89826 requests the same and has a suggestion how to solve the issue. *** This bug has been marked as a duplicate of bug 89826 ***