Description: The text formatting changes partly to cell formatting when pasting content from one cell to another Steps to Reproduce: 1. Open attached file 2. Drag content of the second cell ('DEF' 'DEF') to cell one ('ABC') For comparison: 1. Resetting to 'default' pressing CTRL+Z 2. Drag 'GHI GHI' to 'ABC' Actual Results: The second paragraph gets the same as the cell pasting it in Expected Results: The pasted formatting should be preserved Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 5.4.0.0.alpha0+ Build ID: 92a1ad1f36b6d3cc13135a8c0805508933011577 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-01-06_23:42:59 Locale: nl-NL (nl_NL); Calc: CL and in Versie: 4.4.6.3 Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d Locale: nl_NL and in Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89) and in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Created attachment 130230 [details] Example file
(In reply to Telesto from comment #0) Dragging to 2nd or 3rd paragraph in cell A1: > Steps to Reproduce: > 1. Open attached file > 2. Drag content of the second cell ('DEF' 'DEF') to cell one ('ABC') second 'DEF' changes to red. > For comparison: > 1. Resetting to 'default' pressing CTRL+Z > 2. Drag 'GHI GHI' to 'ABC' second 'GHI' remains blue Note: Start with selecting 2nd and 3rd paragraph in cell A1, and hit Ctrl+M.. then 'DEF' does not change to red. Version: 5.4.0.0.alpha0+ Build ID: ea860d52ade14b4a16289c81a0f8586799c6617f CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-12-31_01:52:05 Locale: nl-NL (nl_NL.UTF-8); Calc: group
Confirmed in comment 2
(In reply to Xisco Faulí from comment #3) > Confirmed in comment 2 Hmm, actually my comment is more a question to Telestro: is that how you tested and what you found, because I have the idea that my finding differs, and is related to the direct formatting in cell A1. Note: cursor in table, Table > Convert > Table 2 text .. Paragraphs, OK .. perform same test > same result.
(apologies for not being crisp and clear in my first comment here ;) )
Created attachment 130370 [details] Example file @Cor I have created a better example to illustrate the inconsistency: 1. Open attached file 2. Drag ABC in the empty space between ZZZ - ZZZ (second ABC will be red) 3. Reset (CTRL+Z) drag ABC into the empty space between YYY - YYY (second ABC will be red) 4. Reset (CTRL+Z) drag DEF between ZZZ - ZZZ (both will stay black) 5. Reset (CTRL+Z) drag DEF between YYY - YYY (both will stay black) The text should stay black (as I see it). Same behavior can be found in Word
(In reply to Telesto from comment #6) > Created attachment 130370 [details] > Example file Thanks. > @Cor > I have created a better example to illustrate the inconsistency: > 1. Open attached file > 2. Drag ABC in the empty space between ZZZ - ZZZ (second ABC will be red) > 3. Reset (CTRL+Z) drag ABC into the empty space between YYY - YYY (second > ABC will be red) I confirm that. > 4. Reset (CTRL+Z) drag DEF between ZZZ - ZZZ (both will stay black) > 5. Reset (CTRL+Z) drag DEF between YYY - YYY (both will stay black) That too. However... now reset. Ctrl+Z, select DEF, Ctrl+M (it has direct formatting, and ABC hasn't) and drag DEF again to ZZZ and YYY areas. Now it behaves the same as when you drag ABC.. (The other way round, applying Black color to ABC, makes it behave as your DEF. > The text should stay black (as I see it). Pasting text without direct formatting in an area with direct formatting, makes the pasted text get the direct formatting. Pasting text with direct formatting in an area with direct formatting, makes the pasted text retain its original direct formatting. That is what you found in your initial test too. And it has nothing to do with a table or not. I close this issue as NotABug > Same behavior can be found in Word And should this be seen as a sign of proper or improper behavior :) ? But indeed, Word ignores the direct formatting of the area you paste the text without direct formatting. This could be an issue for debate - how to go around with direct and style formatting in all kind of situations. Depending on probably philosophy, ODF specs, etc..
@CoR I'm agreeing with you that my bug report is improper and had to be closed. However the main issue (in my opinion) still persists: pasting text without direct formatting in an area with direct formatting, makes the pasted text get the direct formatting (even when its not intended) MS Word was only an example. If it was the only application, I could agree. But on the contrary. LibO is the only application I know off which behaves like this (probably I didn't look hard enough :-). I tested: - Wordpad - Mozilla Thunderbird - Zotero - Google Docs - Mac Texteditor - Pages - A few online Rich Text Editors If it should be the normal behavior. 1. Why is the last paragraph getting the direct formatting and not the first one? 2. Shouldn't the formatting automatically extend to every paragraph pasted? Also a more real life example (making a quite common mistake) Open a new text document. Add, without dashes: ---- ABC DEF DEF ---- 1. Select ABC (and click on the Font Color Icon (with default color) 2. Hit enter (to accidentally create a row set to red) (There is no way of knowing; Bold/Underline are visible in the toolbar, colors aren't) 3. Drag DEF-DEF under ABC. 4. Second DEF will have a red font color
cannot reproduce steps from c#8. Version: 5.4.0.0.alpha0+ Build ID: 9e7526044c8fa6b006b0cb791d15f2476c96ebf2 CPU Threads: 4; OS Version: Mac OS X 10.12.2; UI Render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2017-01-14_04:23:59 Locale: de-DE (de_DE.UTF-8); Calc: group When hitting default font color icon, for me the font color changes (slightly since default is some odd red fairly close to black) but when hitting enter I see no red line.
I'm creating really creating fuzz being imprecise and not to the point. Shame on me. It's not about a red line or something like that. I'm talking the reformatting which occurs when cut/pasting (or dragging) a two or more paragraphs without direct formatting into an empty paragraph ('row') where direct formatting (Bold/Italic/Underline/Highlight/Font color) is set. 1. Copy (text between the dashes) ---- ABC DEF GHI JKL MNO DEF GHI KLM NOP QRS TUV WXY ---- 2. Note that everything is pasted without direct formatting (Font Color: Automatic) 3. Select ABC (apply some direct formatting; bold/underline/Highlight) 3. Set the cursor after the 'C' and hit enter (creating a new paragraph; which has the same formatting as ABC. Note: can happen by accident). 3. Cut/paste or drag "DEF-WXY" into the paragraph created in step 3. 4. WXY will be formatted to the applied formatting of the paragraph below ABC. The rest will be black without direct formatting (Font Color: Automatic) In my opinion WXY should also be black (without direct formatting aka Font Color: Automatic). Like the text editor I know do. To format the last paragraph makes it especially odd. If DEF got a direct formatting would suspect a formatting issue, but with WXY.. There are lots workarounds: remove direct formatting from the paragraph below ABC (or setting it to black) or setting DEF-WXY to black (instead of automatic).
thx for clarifying. confirming what telesto describes in comment 10. Personally no strong opinion on this, but would expect to either have all text dragged into a certain formatted paragraph to either adapt the formatting completely or not at all. Only adapting the formatting for the last row seems unexpected and counter-intuitive. The question now is: what is the "correct" expected behavior. And is notabug still correct. Looking at the title, we've come a long way. Last test did not involve any cells at all. So maybe file a new bug or adjust title? With new bug, this one can remain as is, with changed title, this one here should probebly be reopened?