Description: Create a document with the following text: ``` Lorem ipsum dolor sit amet Lorem ipsum dolor Lorem ipsum dolor Lorem ipsum dolor sit amet ``` Select the word "ipsum" in the 1st line and press Ctrl+B to apply "Bold" direct formatting to it. Put the cursor in the very **beginning** of the 2nd line, press Shift+End, and then Ctrl+B to make the whole line bold. Put the cursor in the very **end** of the 3rd line, press Shift+Home, and then press Ctrl+B to make this one line bold as well. The 2nd and 3rd lines are now bold, and the word "ipsum" in the first line is also bold. Now select the whole text (for example, by pressing Ctrl+A) and apply some paragraph style to it (for example, Text Body Indent). You will see that the second line is now regular, not bold. (And I think this is wrong from the user's perspective.) The 3rd line and the word "ipsum" on the 1st line are still bold. (Correct, this is what the user would expect, since applying paragraph styles is expected to not clear direct formatting.) Steps to Reproduce: - Actual Results: - Expected Results: - Reproducible: Always User Profile Reset: No Additional Info: -
Repro Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 1bb0e177124d5d6661b72df6c7d848fb23639652 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL The difference: line 2 & 3 getting formatting as Paragraph Direct Formatting. Line 1 as Character Direct Formatting Applying a paragraph style apparently flushes the Paragraph Direct Formatting
Created attachment 177406 [details] Example file
Also in LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
@Mike I'm not sure what the expect. I'm not seeing the advantage of "Paragraph DF formatting", in my perception it should simply be "Character DF". But well what do I know about styles.. And obviously someone or some code is likely relying on the current behaviour. FWIW: the Paragraph DF formatting will be converted to Character DF on DOCX export (but also has a bug see bug 146663)
(In reply to John from comment #0) > The 3rd line ... are still bold. I do not reproduce this. The third line is not bold in Version: 7.3.0.1 (x64) / LibreOffice Community Build ID: 840fe2f57ae5ad80d62bfa6e25550cb10ddabd1d CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL as well as in Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL The cited line could *only* be true in case when the "Put the cursor in the very **end** of the 3rd line" piece of steps were performed incorrectly, e.g. the third line contained a trailing space, and the selection didn't include that space. Or maybe the third and the fourth lines were not separate paragraphs, but split by line break (Shift+Enter). In both cases, the selection then would not cover the whole paragraph. (In reply to Telesto from comment #4) > I'm not seeing the advantage of "Paragraph DF formatting", in my perception it > should simply be "Character DF". I do not understand what you mean: do you say you do not understand the concept of paragraph DF, or you do not understand why it includes pieces shared with character DF, or if you do not understand why it gest applied in *this specific case*. The last is just a UX choice of early days; and it *in theory* could be changed, although it could be unexpected to most; the idea behind that decision was to avoid dedicated workflow for paragraph DF vs character DF application. But the first two points are absolutely logical concepts, and part of the standard, meaning it is simply nothing to discuss here.
Created attachment 177407 [details] Screencast
(In reply to Mike Kaganski from comment #5) > I do not understand what you mean: do you say you do not understand the > concept of paragraph DF, or you do not understand why it includes pieces > shared with character DF, or if you do not understand why it gest applied in > *this specific case*. The last is just a UX choice of early days; and it *in > theory* could be changed, although it could be unexpected to most; the idea > behind that decision was to avoid dedicated workflow for paragraph DF vs > character DF application. But the first two points are absolutely logical > concepts, and part of the standard, meaning it is simply nothing to discuss > here. Maybe start with an example where you prefer Paragraph DF instead of a Paragraph Style or Character DF. That's surely helpful for grasping this.. * When using formatting like CTRL+B I (personally) expect "Character DF" all the time. Currently I control or Character DF or Paragraph DF depending on select area. Which requires lots of awareness of the selected area. And there is no-feedback if we go from Character DF to Paragraph DF or not (OK, Style Inspector) If I press CTRL+B at start of the first paragraph, doesn't mean I intend to write full paragraph in BOLD (which makes paragraph DF the obvious choice). Maybe I wanted to start with first word to be bold.. Result being; having Paragraph DF bold & override by Character DF non-bold. * There is now way to remove Paragraph DF (except for clear all DF, which is really rigorous) * In the case here the user wanted to apply Paragraph Style, and assumed the applied formatting being Character DF. Where Character DF would override Paragraph Style. However caused by auto-application of Paragraph DF this whole idea broke down.
(In reply to Telesto from comment #6) Are you confirming my comment 5? It would be nice if you described your screencast - what it shows, what to watch. But I suppose it shows exactly what I wrote.
(In reply to Telesto from comment #7) > Maybe start with an example where you prefer Paragraph DF instead of a > Paragraph Style or Character DF. That's surely helpful for grasping this.. Heh, so you suggest *me* to "start with" something that you did not explain?!
To both @Mike and @Telesto I just found a reliable way to reproduce the "3rd line stay bold" issue. There are no tralining spaces or Shift+Enter keypresses, but you need to be careful and patient. Actually, it happens quite often and there are probably many other ways to reproduce it. 0. restart Writer in safe mode 1. type the text ``` Lorem ipsum dolor sit amet Lorem ipsum Lorem ipsum Lorem ipsum dolor sit amet ``` 2. type a space character in the very end of the 3rd line, put the cursor before the space, then press Shift+Home and Ctrl+B, and then remove the space (by pressing End and then Backspace). 3. select the whole text and apply some paragraph style (e.g., Ctrl+0 to apply Text Body) you will see that the 3rd line is now regular, not bold. # But now the second part. Repeat steps 2 and 3. You will see that the 3rd line is now preserved bold. But this not REALLY true. At least for me on Windows. This is just wrong rendering. Scroll the page past the text and then back and you will see that the 3rd line is now regular. What is strange, though, is that if you place the cursor on the very end of the 3rd line, you will see like you have a space before it. (See the image.) But this space is not real. If you press the Backspace key, it will remove both the virtual space and the letter m. What the heck. OK, type the missing "m". # The third part. Repeat steps 2 and 3. You will see that the 3rd line is now preserved bold. And it stay bold no matter what you do. This is not just rendering. It is really bold.
Created attachment 177412 [details] cursor and virtual space
I'm able to reproduce comment 10 steps 1-3 Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 1bb0e177124d5d6661b72df6c7d848fb23639652 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL Versie: 5.1.6.2 Build ID: 07ac168c60a517dba0f0d7bc7540f5afa45f0909 CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: GL; Locale: nl-NL (nl_NL); Calc: CL Versie: 5.0.6.3 (x64) Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa Locale: nl-NL (nl_NL) but not with 4.4.7.2 However this looks like a different topic in comparison to the initial report in comment 0 (or I simply misread it)
(In reply to Telesto from comment #12) > I'm able to reproduce comment 10 steps 1-3 FWIW: the range matches bug 146663 and similar behaviour. So expect it to be the same thing
From my perspective, this is NOTABUG. This looks like yet another case of mixing styles with direct formatting. If the segments that are wanted to be marked as bold use the character style "Strong Emphasis" instead of direct formatting, then changing the paragraph style preserves the character formatting. Proper use of LO demands that styles and direct formatting are never mixed! IMO this is a feature, not a bug.
> Proper use of LO demands that styles and direct > formatting are never mixed! I don't think so. Styles-only approach, if we talk about character styles, has at least one big disadvantage: you cannot "nest" the formatting. For example, you have a sentence in the middle of a paragraph, and this sentence has five words that are "bold". To make them bold, you have used the "Strong" character style. Then, for some reason, you decide to make this sentence italic, but keep those five words bold (that is, they should be bold italic now). This means that first you need to apply the "Emphasis" character style to the sentence, then will need a character style for bold-italic, and then you will need to apply this style to each of five words. Definitely, this would be more robust, but this takes too many steps. > IMO this is a feature, not a bug. I don't see how it can be called a feature at all. The current way it works is very inconsistent and hardly understandable.
(In reply to John from comment #15) > I don't think so. Styles-only approach, if we talk about character styles, > has at least one big disadvantage: you cannot "nest" the formatting. Which is not a format limitation: ODF allows to nest character styles - i.e., you may rave a larger text span with style Foo, and in the middle, you have a nested text span with applied Bar atop of Foo. But there is bug 115311 - missing UI support for that.
(In reply to John from comment #15) > > IMO this is a feature, not a bug. > > I don't see how it can be called a feature at all. The current way it works > is very inconsistent and hardly understandable. It's hard to tell what specifically you are discussing at this point. IMO everything in comment 0 is not a bug. But second and third parts of comment 10 look like a bug (but I didn't try to repro).
(In reply to John from comment #15) > > Proper use of LO demands that styles and direct > > formatting are never mixed! > > I don't think so. Styles-only approach, if we talk about character styles, > has at least one big disadvantage: you cannot "nest" the formatting. > > For example, you have a sentence in the middle of a paragraph, and this > sentence has five words that are "bold". To make them bold, you have used > the "Strong" character style. > > Then, for some reason, you decide to make this sentence italic, but keep > those five words bold (that is, they should be bold italic now). This means > that first you need to apply the "Emphasis" character style to the sentence, > then will need a character style for bold-italic, and then you will need to > apply this style to each of five words. Definitely, this would be more > robust, but this takes too many steps. > > > IMO this is a feature, not a bug. > > I don't see how it can be called a feature at all. The current way it works > is very inconsistent and hardly understandable. For any document of significant complexity and size, I always create a character style for whatever I need. There is no nesting required, just create a new style. Use a document template if you need to. I find the current way very consistent as long as the user is consistent: use styles all the time or not at all. Never mix and match.
(In reply to Mike Kaganski from comment #17) > But second and third parts of comment 10 look like a bug (but I didn't try to repro). I'm able to reproduce that (after I misread the instruction couple of times): Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: b4a281af53efa0c36ee1770e6cf4d800be77a6d2 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL and with Versie: 5.0.6.3 (x64) Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa Locale: nl-NL (nl_NL) not with 4.4.7.2 Which makes the commit identified in bug 146663 a candidate
> Which makes the commit identified in bug 146663 a candidate.. I checked it, bisected to: commit 3c0805e1f4f4d14e92c7e655d59c87de5c207e48 Author: Miklos Vajna <vmiklos@collabora.co.uk> AuthorDate: Thu May 14 11:34:33 2015 +0200 Commit: Miklos Vajna <vmiklos@collabora.co.uk> CommitDate: Thu May 14 11:39:16 2015 +0200 tdf#86639 SwEditShell: when setting para style, reset char attrs if needed The old internal RTF filter used to call SwTxtNode::SetAttr() without setting SetAttrMode::NOFORMATATTR, so character attributes which cover the whole node got converted to paragraph attributes. The new UNO filter goes through SwXText::insertTextPortion(), which sets SetAttrMode::NOFORMATATTR, so this doesn't happen. The result of this is that when the UI sets a new paragraph style on the text node, then such character attributes are no longer removed. Given that in RTF you can't really have character properties on a paragraph, going back to the document model produced by the old internal filter doesn't sound like the good direction -- not to mention that changing SwXText::insertTextPortion() this way would be an implicit API change. Fix the problem by tweaking SwEditShell::SetTxtFmtColl() instead, so that it removes these full-text-node character attributes, too. The logic in SwTxtNode::RstTxtAttr() can be extended later if necessary to delete more attributes, but to be on the safe side, just handle the bare minimum necessary to fix the problem for now. Change-Id: I5faa3226fc0f9c18e005da185fe0830d8c393256 https://cgit.freedesktop.org/libreoffice/core/commit/?id=3c0805e1f4f4d14e92c7e655d59c87de5c207e4