Some styles (character/paragraph) are such that, when you set them, you almost-certainly want not to apply any direct formatting. But - if you select some text and set a style for it, the direct formatting remains, over the styled text. While the above is reasonable default behavior, it should be possible to indicate whether the user is expecting a reversion to no-direct-formatting.
Examples: When you change the paragraph style from Body Text or Default Style to, say, Heading 1, Heading 2 etc. - you probably want to drop the direct formatting.
And what if you apply "MyFancyHeadingStyle"? Thing is, we have a) to comply with the format, b) take care about round trips with alien formats, and c) consider user customizations. So this clearly wont fix. Currently in discussion is bug 38194 (and related): proper feedback when the user has done direct formatting.
(In reply to Heiko Tietze from comment #2) > And what if you apply "MyFancyHeadingStyle"? This bug is strictly about when you've formatted directly, not applied a style. Applying a style express stronger intent. > b) take care about round trips with alien formats > and c) consider user customizations. I'm not sure what you mean. Can you elaborate? Also, if you ask a question, please extend me the courtesy of letting me try to respond before closing a bug.
The hierarchy that defines the actual appearance is paragraph style, character style 1..n, direct formatting. Your proposal is about overriding a direct formatting when the user applies a certain style, and you want to do it for just some styles like headings. My objection was that heading is not defined by a clear attribute and you may have user defined styles that behave like this. So the realization of your proposal would be a manual flag aka checkbox whether this paragraph style turns the usual logic upside down (but only when applied, otherwise it has to be stored with the document and respected by all programs that use ODF). Sounds very complicated.
(In reply to Heiko Tietze from comment #4) > The hierarchy that defines the actual appearance is paragraph style, > character style 1..n, direct formatting. Your proposal is about overriding a > direct formatting when the user applies a certain style, and you want to do > it for just some styles like headings. I'm not proposing overriding the logic, just clearing direct formatting, once - As though you've applied "Clear direct formatting" when changing styles. After you've changed styles, you can still format directly just like before. This is why this bug is not really related to 38194, which increases the visibility of "persistent style state", so to speak. The checkbox would say something like: "Clear direct formatting when applying this style".
(In reply to Eyal Rozenberg from comment #5) > "Clear direct formatting when applying this style". Yes, that's the right implementation from the UI POV. But I still disagree with it as you have many ways to apply a style and it would be not clear what style has the flag and kills your direct formatting. It solves one minor problem (ctrl+m is just a keypress away) and introduces a much bigger (no feedback when ctrl+m is executed automatically). That's why I still vote for NAB.
(In reply to Heiko Tietze from comment #6) > I still disagree > with it as you have many ways to apply a style and it would be not clear > what style has the flag and kills your direct formatting. If no style provided by Libreoffice has this as a default - then you only get this behavior if you specifically asked for it. > It solves one minor problem (ctrl+m is just a keypress away) Ah, but it's just pressing Ctrl+m - it's selecting the entire paragraph and pressing Ctrl+m. And the change may be subtle, e.g. change in vertical space above/before the paragraph.
To make things more complicated, simply clearing all direct formatting isn't what you want. You certainly do not want to clear all direct formatting like Ctrl+M when applying cascaded hierarchical styles styles, but only the formattings that will be set by the to be applied style hierarchy.
(In reply to Eike Rathke from comment #8) > To make things more complicated, simply clearing all direct formatting isn't > what you want. You certainly do not want to clear all direct formatting like > Ctrl+M when applying cascaded hierarchical styles styles, What do you mean by "cascaded hierarchical styles" ? I'm just a applying a paragraph style to a paragraph, that's all. Ok, styles are hierarchical and cascaded in a sense, i.e. each style is based on some other style except for the Default Style, but I don't think that matters here. > but only the > formattings that will be set by the to be applied style hierarchy. Why? No. I want all direct formatting of that paragraph to vanish. Wipe the slate clear. At most I'm willing to accept applications of Character Style.
Dear Eyal Rozenberg, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This is still an issue.
Dear Eyal Rozenberg, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still an issue with: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f8e591ab9182e0a61c4ae5b8f77b166fcaeaa877 CPU threads: 4; OS: Linux 6.4; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US