Bug 126546 - Deficiencies in Manage Styles (possibly related to import filters)
Summary: Deficiencies in Manage Styles (possibly related to import filters)
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Styles-Paragraph Writer-Styles-Character
  Show dependency treegraph
 
Reported: 2019-07-25 15:52 UTC by Adalbert Hanßen
Modified: 2020-12-13 08:05 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Test sample showing the bug. (134.58 KB, application/vnd.oasis.opendocument.text)
2019-07-25 15:53 UTC, Adalbert Hanßen
Details
Trying the same bug with the old example, added one other observation (176.86 KB, application/vnd.oasis.opendocument.text)
2020-05-29 10:01 UTC, Adalbert Hanßen
Details
example file (10.67 KB, application/vnd.oasis.opendocument.text)
2020-12-08 13:29 UTC, Dieter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adalbert Hanßen 2019-07-25 15:52:49 UTC
Description:
Attached is a sample file to show several formatting glitches. They all happen in LibreOfficeWriter
Version: 6.4.0.0.alpha0+
Build ID: 4248d759744f83a68d334a8b347124719a2886a8
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-07-09_15:00:58
Locale: de-DE (de_DE.UTF-8); UI-Language: en-US
Calc: threaded

Steps to Reproduce:
1.See attached sample file
2.
3.

Actual Results:
wrong formatting (Styles are not applied completely)

Expected Results:
All formatting features from the styles applied and not just some.


Reproducible: Always


User Profile Reset: No



Additional Info:
The bug shows up in connection with copying/pasting from imported *.doc or *.rtf files. It does not show up, if the text is moved through a pure ASCII editor, then pasted to a fresh file and if the styles are defined there accordingly.Very strange!
Comment 1 Adalbert Hanßen 2019-07-25 15:53:53 UTC
Created attachment 152989 [details]
Test sample showing the bug.
Comment 2 Adalbert Hanßen 2019-08-01 17:52:00 UTC
I just tested the given sample with the most recent development vesion:

Version: 6.4.0.0.alpha0+
Build-ID: 9ee5ad5a0b84bfa652da34694ba4f75668f06087
CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-07-30_13:21:44
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: threaded


It is still there.
Comment 3 Dieter 2019-08-21 16:07:48 UTC
I confirm the described behaviour with

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 3e64065612acec2eb29aa21e2b515953422256d7
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-08-15_22:57:26
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

But I'm not sure, if this is a bug: Character Style in the paragraphs is "FontStyle27" (Arial 9pt). If you change character style to default style, everything is correct. So I assume - but I'm not sure, because I copuldn't find anything about it in LO help - that default character style adopt font settings of paragraph style while other character styles are dominant against font settings of paragraph style.
Comment 4 Dieter 2019-11-26 07:53:24 UTC
(In reply to Dieter Praas from comment #3)
> But I'm not sure, if this is a bug: Character Style in the paragraphs is
> "FontStyle27" (Arial 9pt). If you change character style to default style,
> everything is correct. So I assume - but I'm not sure, because I copuldn't
> find anything about it in LO help - that default character style adopt font
> settings of paragraph style while other character styles are dominant
> against font settings of paragraph style.

Documentation chapter "working with styles", page 9: "Double-click the required character style, or double-click Default Style to remove the character style."

It's confusing, that "Default Style" seems to be the same as "no style" or "style defined in paragraph style" 

Input from Design-Team? (For me again an example, that relation between paragraph style and character style is not clear)
Comment 5 Dieter 2019-11-26 08:05:41 UTC
(In reply to Dieter Praas from comment #4)
> It's confusing, that "Default Style" seems to be the same as "no style" or
> "style defined in paragraph style" 
> 
> Input from Design-Team? (For me again an example, that relation between
> paragraph style and character style is not clear)

See also discussion in bug 108498 and bug 128960
Comment 6 Heiko Tietze 2019-11-26 12:51:44 UTC
(In reply to Dieter Praas from comment #4)
> Input from Design-Team? 

See bug 128960

> (For me again an example, that relation between
> paragraph style and character style is not clear)

Renaming the CS from Default to None (or whatever) wont solve the problem. Neither the proposed Styles Inspector makes it perfectly clear (only RTFM) but improved feedback is at least a step forward.

(In reply to Dieter Praas from comment #3)
> If you change character style to default style, everything is correct.

=> NEEDINFO
Comment 7 QA Administrators 2020-05-27 03:41:11 UTC Comment hidden (obsolete)
Comment 8 Adalbert Hanßen 2020-05-29 10:01:32 UTC
Created attachment 161391 [details]
Trying the same bug with the old example, added one other observation

The bug is still there, see my new example file. I loaded my old example file to Version: 7.0.0.0.alpha1+
Build ID: 0677d46bcc56c1f6c27b9331662990b38fd452d6
CPU-Threads: 4; BS: Linux 5.3; UI-Render: Standard; VCL: gtk3; 
Locale: de-DE (de_DE.UTF-8); UI: de-DE
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-05-21_12:54:11
Calc: threaded

and there I tried out what I did before. I added some screenshots and found out an interesting thing: The maze however goes away for this file when I delete the character style "Font Style 27" which is associated to whatever new paragraphs are added to the file, impeding the character fonts associated to the paragraph styles in the file's template.
Comment 9 Dieter 2020-05-29 10:24:23 UTC
Adalbert, it's not clear for me, if you've followed my tip in comment 3: "If you change character style to default style, everything is correct."
Comment 10 Adalbert Hanßen 2020-05-29 22:36:38 UTC
Of course, Dieter, if I mark the added paragraph in the development version with which I re-tested the issue and if I then go to <F11> under Character Style and reassign "Default Paragraph Font", then it the text appears as Liberation Sans 11 pt, the default for standard "Absatzvorlage Standard".

After marking everything (Ctl-A) I could not apply this procedure. Probably because there is a table of contents in the document. Although it was generated automatically it would not really change if reset to its default Character font. Its immutability probably prevents me from reassigning the  "Default Paragraph Font" to the whole document. 

Now looking closer into my issue and after adding a remark to https://bugs.documentfoundation.org/show_bug.cgi?id=128960#c23 earlier today I see that in my original bug example the very first line "This is a sample file to ..." has the paragraph style "Absatzvorlage Standard" but in addition the text in it has the character format "Font Style27", which is probably a leftover from the MS Word file which was among the ancestors of that file (although not a single line of that remained in it. But former formatting may have infectiously spread to what I wrote around the original text from the MS Word document).

If you place the insertion mark at the very end of that very first line and press ENTER, a new paragraph is created with paragraph style "Absatzvorlage Standard", because that's the successor style for it from the last paragraph. But in addition the characters in it inherit the damned "Font Style27"!

Probably much of the formatting quirk is due to this. Of course when pressing ENTER at directly in front of the paragraph mark, I expect that a new (empty) paragraph to be created without any direct formatting and without any other character style from the style sheet (aka template). 

So pressing ENTER just at the very end of a paragraph should

1. start a new paragraph with the default paragraph style as defined as the successor paragraph style from the last one (it may be different than that, e.g. for headlines in general it will be not the headline style),

2. reset any assignment of different character style that might have been in vigor before for the last characters in the old paragraph,

3. reset any assignment of direct formatting that might have been in vigor before for the last characters in the old paragraph.

This part of my bug report might be considered an UI issue, because it improves the usability of LO Writer by making the formatting "teachable to a novice". Currently, there are far too many methods to achieve the same formatting, but they have inconsistent and divergent consequences for further formatting.

To better explain why a character is formatted as it is (i.e. if  its appearance is from the paragraph, the character or from direct formatting (which takes precedence over the others and can be removed by Ctl-M), a small indicator on the bottom line (e.g. next to the Text Language) showing a P for Paragraph, a C for Character or a D for direct formatting would help to understand why a character left to the insertion point appears exactly the way it does. Currently to find out by which means a specific character in a document got its formatting is really cumbersome.

There may be (or not?) a bug in the import filter for doc and rtf files. I have seen that lots such "Font Style xy" can be imported into a LO Writer Document.

Do you know what is defined to happen if one removes such character fonts? Where is it described in the manual? Apparently the right thing seems to happen: Assign the default character formatting as defined in the paragraph style. But what is assigned if one deletes a used style should be described in the documentation and one should find it by searching for delete and style.

And of course something to get rid of the many unused styles which tend to accumulate in a stylesheet is also something on my wish list!
Comment 11 QA Administrators 2020-05-30 03:33:32 UTC Comment hidden (obsolete)
Comment 12 Dieter 2020-12-08 13:29:34 UTC
Created attachment 167941 [details]
example file

During the last six month nobody commented to this bug report. Perhaps it's also, because your comments are very long. so there is one wish from my side: Please keep it as short as possible.

So after reading all, I try to summarize with this steps:
1. Open attacehd file
2. Place cursor at the end of the first line. See, that paragraph style is "Default Paragraph Style" and character style is "Font Style27"
3. Press enter

Actual result:
The new paragraph has paragraph style "Default Paragraph Style" and character style "Font Style27"

Adalbert, you expect the following result:
The new paragraph has paragraph style "Default Paragraph Style" (because that's the next style rule of that style) and character style "Default Character Style (all different character styles should be removed as well as all direct formatting)

Adalbert, did I understand you correctly?
=> NEEDINFO
Comment 13 Adalbert Hanßen 2020-12-12 18:54:56 UTC
(In reply to Dieter from comment #12)
> Created attachment 167941 [details]
> example file
> 
> ...
> 
> Adalbert, you expect the following result:
> The new paragraph has paragraph style "Default Paragraph Style" (because
> that's the next style rule of that style) and character style "Default
> Character Style (all different character styles should be removed as well as
> all direct formatting)
> 
> Adalbert, did I understand you correctly?
> => NEEDINFO

Yes, Dieter! (See in #10 after the words "So pressing ENTER just at the very end of a paragraph should...")
Comment 14 Thomas Lendo 2020-12-13 03:07:34 UTC
I would love when such bug report is made because of a clean OpenDocument file without import problems and style/direct formatting mix.

Anyway, the supposed change has a huge impact on the way how Writer works. Before I say something as a reflex of my long work with Writer and styles and "dirty" DF documents ... What is the OpenDocument specification saying about that?
Comment 15 Adalbert Hanßen 2020-12-13 08:05:28 UTC
I am not a norm expert, so read this with some caveat in mind. Looking at page 99 of 846 in OpenDocument-v1.2-os-part1, which is part of chapter "3.17 Foreign Elements and Attributes", I see:

"Conforming extended producers should not use foreign elements and attributes for features defined in the OpenDocument specification.
A conforming consumer that encounters an OpenDocument defined attribute that has a value that
is not defined by OpenDocument, then it should:
1) If the attribute has a specified default value, use its default value, or
2) If the attribute does not have a specified default value, ignore the attribute."

To my understanding a not used character style might be considered to be a "foreign element". 1) and 2) then would be exactly what I proposed.