bug 1 Paragraph A is in Times New Roman, paragraph B is in Liberation Mono. Clone formatting from A to B works correctly. Now, save document, close app, re-open - and see the formatting is no longer applied - again showing Liberation Mono instead of Times New Roman. bug 2 Word A is in bold with white (or no) highlighting. Word B is in either italics and/or underline and/or coloured highlighting. Clone formatting from A to B. B becomes bold (success) but remains in italics and/or underline and/or coloured highlighting (failure). (Although in this instance, when I save, close and re-open document, the bold formatting is still applied). Mint Cinnamon 21 Libreoffice 7.3.7.2 (both pre-installed on Linux Mint, and the downloaded .debs). All bugs appear with opencl on and off.
(In reply to supineblue from comment #0) > bug 1 > Paragraph A is in Times New Roman, paragraph B is in Liberation Mono. > Clone formatting from A to B works correctly. Now, save document, close app, > re-open - and see the formatting is no longer applied - again showing > Liberation Mono instead of Times New Roman. Can't confirm this > bug 2 > Word A is in bold with white (or no) highlighting. Word B is in either > italics and/or underline and/or coloured highlighting. > Clone formatting from A to B. B becomes bold (success) but remains in > italics and/or underline and/or coloured highlighting (failure). > (Although in this instance, when I save, close and re-open document, the > bold formatting is still applied). I confirm behaviour with Version: 7.4.3.2 (x64) / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL It works with paragraph direct formatting of target word, but not with character direct formatting.
(In reply to supineblue from comment #0) > bug 1 > Paragraph A is in Times New Roman, paragraph B is in Liberation Mono. > Clone formatting from A to B works correctly. Now, save document, close app, > re-open - and see the formatting is no longer applied - again showing > Liberation Mono instead of Times New Roman. Is this a TXT file?
(In reply to Mike Kaganski from comment #2) > Is this a TXT file? My test in comment 2 was with a normal odt file.
Created attachment 184076 [details] Example file in which bug 152285 is found Thanks for the replies. I have attached an example file. The .txt extension was added so it would upload, but that should be removed. It is a .docx file.
I confirm the first problem with the attached file. So it seems to be related to docx-files. Supineblue, since bug 1 seems to be only valid fo doc-files and bug 2 also for odt-files, we should seperate those two problems. So please decide on which problem this bug should focus and open a ne report for the other problem. If you add me in cc-list I will confirm it.
(In reply to supineblue from comment #0) > bug 2 > Word A is in bold with white (or no) highlighting. Word B is in either > italics and/or underline and/or coloured highlighting. > Clone formatting from A to B. B becomes bold (success) but remains in > italics and/or underline and/or coloured highlighting (failure). > (Although in this instance, when I save, close and re-open document, the > bold formatting is still applied). This is bug 71481. See bug 71481 comment 16 and bug 71481 comment 18. In the case when the words A and B are both direct-formatted, and the italics of word B comes from character run properties, not paragraph, this could (and likely should) be improved. But note how really complex Writer's formatting layers/rules are; so given that character formatting may come from: 1. Paragraph style (applied to the paragraph directly, or from a style that this style inherits from); 2. Paragraph direct formatting; 3. Character style; 4. Character direct formatting, with additional differences when it spans over the whole paragraph or not; and that no italics may be either "no explicit setting for italics", and "italics explicitly disabled", which are really different options, I can only quote myself: (In reply to Mike Kaganski from bug 71481 comment #18) > UX-advise is required, with thoughtful analysis and some design specs before > "fixing" it. This implies, by the way, that this issue should only focus on "bug 1".
(In reply to Mike Kaganski from comment #6) > This implies, by the way, that this issue should only focus on "bug 1". O.K. let's focus on first problem here (I've changed bug summary).
Created attachment 184254 [details] Minimal reproducer with a parahraph having a character style applied Reproduce from scratch: 1. Create a new text document; 2. Add a couple of paragraph; 3. Assign a *character style* with a distinct font name (e.g., "Source Text" that defines use of Liberation Mono) to the whole entirety of one of them; 4. Save as DOCX, and *reload*; 5. Using Clone Formatting tool (in normal mode, without any modifier keys), copy the formatting from the paragraph *without* character style, and select the whole entirety of the paragraph with the character style as the target; 6. Save and reload. After step 5, the paragraph having the character style will look identically to the look of the other paragraph: the character style formatting will get overwritten by character-level formatting applied atop. After step 6, the paragraph will have the font name defined by the character style (and the character-level direct formatting will not specify the font name, as seen in Style Inspector). The attachment has a file after steps 1-4.
I guess you are right that bug 2 is not a bug, so we can just focus on bug 1 here. I didn't even realise the formatting layers/rules were complex, - because I never once changed the character or paragraph formatting, either in the drop down menu or the styles menu. I guess it must have happened when copying text from the web and pasting. Been using MS Word all my life before this year and never once experienced this problem. Need to work out what libreoffice is doing different so can avoid it in future.
(In reply to Mike Kaganski from comment #8) > After step 5, the paragraph having the character style will look identically > to the look of the other paragraph: the character style formatting will get > overwritten by character-level formatting applied atop. This seems to be fixed (or at least changed) in 24.2. Now the target paragraph does not get the DF, and won't look like the source paragraph. (Which is not the same behavior as in Word, where the char style would be replaced by the Normal para style.) Since: https://git.libreoffice.org/core/+/36aa809fbd3c44da1ed266104f175e8c872d38b3 author Sarper Akdemir <sarper.akdemir.extern@allotropia.de> Thu Jul 27 21:38:34 2023 +0300 committer Sarper Akdemir <sarper.akdemir.extern@allotropia.de> Tue Aug 29 11:06:14 2023 +0200 tree 5176fa04a4f8c3e0b182d5b228c8e42f8efcbeb1 parent 7f1c2b6ccf318d3b6bbf46f6559b2a3017a72821 [diff] tdf#103706: sw: Revert "Format paintbrush default behaviour" I think we can close this one, but I'm not sure.