Bug 83726 - Applying Styles Does Not Consistently Set Character Properties
Summary: Applying Styles Does Not Consistently Set Character Properties
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version: PreBibisect
Hardware: All All
: high minor
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-10 17:37 UTC by Joel Madero
Modified: 2014-09-12 08:20 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Document Demonstrating Issue (45.39 KB, application/vnd.oasis.opendocument.text)
2014-09-10 17:37 UTC, Joel Madero
Details

Description Joel Madero 2014-09-10 17:37:41 UTC
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.
Comment 1 Owen Genat 2014-09-11 03:49:04 UTC
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.
Comment 2 Joel Madero 2014-09-11 04:13:15 UTC
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)
Comment 3 Owen Genat 2014-09-11 05:13:21 UTC
(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.
Comment 4 Urmas 2014-09-11 06:46:50 UTC
It's not a bug. Bold and italics from the direct formatting should be XORed with the style, not override it.
Comment 5 Joel Madero 2014-09-11 14:06:11 UTC
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
Comment 6 Alex Thurgood 2014-09-12 08:20:56 UTC
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.