Created attachment 106075 [details] Document Demonstrating Issue I'm not exactly sure how to reproduce this from a blank document but the attached document demonstrates the issue really clearly. Steps to Reproduce: 1. Download document 2. Place cursor at the last line WITH text (ie. at the end of "derivative vs. original.") 3. Push enter a couple times 4. Set style to Heading 3 5. Start typing Observed: Font is not bolded Expected: That all properties set in Heading 3 overwrite whatever properties are previously set - ie. bold is applied by default when Heading 3 is selected. To verify that Heading 3 should have bold: 1. F11 2. Right click on "Heading 3" -> Modify 3. Font tab Observed: Bold is set for font style Setting to: Minor - can slow down professional work but won't prevent it. High - basically makes styles very inconsistent, styles used aggressively for anyone using Writer for larger documents. Tried bibisecting and it's preBibisect, someone on user list has said that AOO behaves as expected but I have no verified this.
I can see a bug under v4.2.6.3 Build ID: 3fd416d4c6db7d3204c17ce57a1d70f6e531ee21 but I am not sure it is the bug described in this report. (In reply to comment #0) > 2. Place cursor at the last line WITH text (ie. at the end of "derivative > vs. original.") > 3. Push enter a couple times Pressing ENTER once creates a new paragraph with neither bold nor italic. Pressing ENTER subsequent times causes the prior (empty) paragraph to suddenly become visibly (according to the pilcrow) set in bold and italic, while the paragraph under the cursor remains without bold or italic. This is likely due to the use of direct formatting (bold and italic on "Shiffer Pub. v. Chronicle Books:"), however why there is the indicated delay in revelation is unclear. It should also be noted that direct formatting overrides any paragraph style. This appears to be influencing the test of applying the Heading 3 paragraph style e.g., using Format > Clear direct formatting after pressing ENTER once will allow application of the Heading 3 paragraph style as expected. A clearer example may be required in this sense.
All very interesting stuff. I suppose I disagree with this then: "It should also be noted that direct formatting overrides any paragraph style." this behavior just seems wrong. If you apply a style AFTER direct formatting then it should override all properties. Going to the user list - at least 6 people agreed. What's the point of styles if not to be 100% consistent at least when they are first applied (then of course if you highlight the text and change things then direct formatting takes over)
(In reply to comment #2) > All very interesting stuff. I suppose I disagree with this then: > > "It should also be noted that direct formatting overrides any paragraph > style." > > this behavior just seems wrong. It is not though. Both ISO/IEC 26300 (ODF, Part 1, §16) and ISO/IEC 29500:2012 (OOXML §17.7.2) define a hierarchy of application.[1] In each case directly applied formatting will override an application by style and this is how it should be, otherwise a style cannot be overridden. The "Clear direct formatting" function is available for exactly this reason i.e., it is the only way to clear all direct formatting. [1] In OOXML there is a diagram that clearly indicates the situation, while under ODF a directly applied format is recorded as a style definition (in content.xml rather than styles.xml) and the wording has to be worked through. In the example attached to this report the problem is even less clear because direct formatting has been extensively used: <text:p text:style-name="P6"> <text:span text:style-name="T39">Shiffer Pub. v. Chronicle Books</text:span> <text:span text:style-name="T40">: </text:span> <text:span text:style-name="T9">no different standard for derivative vs. original.</text:span> </text:p> ... thus the paragraph is using a directly applied paragraph formatting style (P6, rather than "Body_20_Text"), which has in turn been overridden by three (T9, T39, and T40) directly applied pieces of character (text) formatting styles, each recorded as a separate style in content.xml.
It's not a bug. Bold and italics from the direct formatting should be XORed with the style, not override it.
While I disagree with the hierarchy, I'm convinced it's not a bug. Closing as NOTABUG. For an end user it's clearly confusing as I got immediate response on the user list of others who had "experienced similar things" and "been very annoyed" etc . . . etc . . . Generally for an end user when a style is applied they expect the text to be consistent, no matter what, and then if that text is modified after text is written, then the modifications obviously come in and override the styles formatting. To have no text at all (and thus not see any "direct formatting" and have this invisible mechanism overwriting style properties (or superseding I suppose) is quite confusing for the end user - including myself and I'm not a LibreOffice light user ;) That being said - thoughts on making this an enhancement request instead? I'll leave that decision in others hands as I'm clearly biased on this one :-D
My 2c : The problem also rears its head when no direct formatting has occurred, i.e. when using the default paragraph style provided in Writer. As that paragraph style is applied when the return key is pressed, it is particularly incomprehensible when one wants to apply Heading 3 or other Heading styles and finds that the Heading style is not applied. This has been my own experience when writing reports for work and attempting to use just the three predefined Heading styles 1, 2 and 3 in Writer.
I am setting this to NEW and asking for ux-advise. I find this behavior to be consistently annoying and if a user wants a style applied, they almost definitely want every property of that style applied. UX - any thoughts here? Feel free to close again but please think of users who don't know about this direct formatting stuff (and the shortcut of ctrl + m to remove it). On one side we tell users to start using styles consistently, but on the other, when you apply a style, you don't see consistent results.
(In reply to Joel Madero from comment #7) > I am setting this to NEW and asking for ux-advise. I find this behavior to > be consistently annoying and if a user wants a style applied, they almost > definitely want every property of that style applied. > > UX - any thoughts here? Feel free to close again but please think of users > who don't know about this direct formatting stuff (and the shortcut of ctrl > + m to remove it). On one side we tell users to start using styles > consistently, but on the other, when you apply a style, you don't see > consistent results. I agree with Joel. In Bug 50639 I also already commented that this local/direct formatting thing is not intuitive.
(In reply to Joel Madero from comment #7) > I find this behavior to be consistently annoying and > if a user wants a style applied, they almost > definitely want every property of that style applied. In any hierarchy of application either A overrides/XORs B or it is the other way around. If a paragraph style is moved higher up the hierarchy (to override/XOR directly applied formatting) then directly applied formatting can no longer override a paragraph style, which is a far more serious problem. If the idea of a hierarchy seems problematic/unwanted then some sort of alternative method needs to be proposed (and the ODF/OOXML specs rewritten with this in mind).
So my proposal is simply this. If there is text written already, and then a user takes the time to select a style, then the entire style (all properties) are applied, at which point these can be undone by manually changing things. For instance if you have a style that has size 20 font, bold and italic, but you want 20 font, bold, not italic, you apply the style, you get what the style promises (20, bold, italic) and then you can select the characters and remove the italics - vs the other way around where by default you get some strange unknown combination of the style applied, and then most users are left wondering why the entire style was not applied. I've been using LibreOffice for years and I had a hard time figuring it out - as did many people on the user list. Imagine a "normal user" (not a power user, not someone who joins mailing lists, chats, bugzilla, etc...) - we might as well stop pretending like styles is a solution for the average user if that's the approach we're going to take.
Hi, (In reply to Joel Madero from comment #10) > So my proposal is simply this. If there is text written already, and then a > user takes the time to select a style, then the entire style (all > ... "text written already": what/how? "select a style": what style type? how is he supposed to apply? Apart from that, breaking the defined hierarchy Styles .. Direct formatting looks pretty useless to me. But maybe that changes when there is one clear step by step explanation, not a lot of comments that I halve to filter and combine or not.
I think the description is quite clear - ping me in the channel and I'll walk you through it....
This is clearly not a bug as stated in previous comments. The paragraph has the 'regular weight' formatting attribute directly applied, and thus, everything else is working just as designed. It *is* consistent and users that know how this works will find quickly resort to using CTRL+M to make sure Direct Formatting is not affecting the application of styles. The user abused DF by removing DF by applying more DF. In fact, the user applied bold in the first place because he didn't know how to use Character Styles (or he was lazy). That's not a bug of the program. To override part of the paragraph, the user had three options. Please see the example that follows: 1. Delete all text after the period in "original.", including next paragraphs. Make sure the period is the very last character. 2. Select the last paragraph ("Shiffer [...] original.") and hit CTRL+M. With this the paragraph is DF-clean [*]. 3. While still selected, hit Ctrl+B for Bold. 4. Select "no different [...] original." and hit Ctrl+B again. This is how the user got into this situation. Continue with the reproduction of the behavior: 5. Hit Enter. 6. Apply Heading 3. 7. Type. -- Text is correctly of regular weight. The user had 3 chances of doing things right. First and proper one, use Character Styles: 3. Only mark "Shifer [...] Books" and apply the "Strong emphasis" character style. Select the paragraph and hit Ctrl+M; you'll notice the document keeps the bold because no DF is applied; no place for confusion. Second one, only override what is needed: 3. Only mark "Shifer [...] Books" and hit Ctrl+B. Third one, un-override the formatting instead of reoverriding it: 4. Select "no different [...] original." and hit Ctrl+M to remove his DF, instead of overriding it with more DF. Because this bug is about consistent application of character properties and Writer *is* consistently applying character properties, this is clearly not a bug and thus I'm closing it as such. The confusion arises from the visual semantics of the second click on the "Bold" button. Visually, the bold button is "unpressed", the mental mapping being that the DF is removed and leaving the last part paragraph DF-clean, and thus, having the application of Header 3 behave as expected. Reality is different: By re-clicking on the Bold button, another DF is applied to change Bold weight for Regular weight. This is where the confusion comes from. What if the style is Header 3 and we clicked on Bold to "unpress" it to override the bold for a regular weight? [*] I abbreviate Direct Formatting as DF.
This bug is referenced by #89960. I have made comments there to suggest a change that could potentially prevent users from falling into the "hidden Direct Formatting" trap, as described in this bug.
I've just spent the last two hours trying to figure out why my styles aren't being applied correctly (to a document written elsewhere) so I'd support Joel's proposal. This is just a terrible UI decision. Witness the fact that AFAIK LibreOffice is the only package I've seen to follow this approach. And it makes it excessively troublesome to use styles rather than direct formatting which at least gives you what you expect.