Created attachment 89007 [details] Related pic. Step1. Select Format Paintbrush on default font "Test 1" Step2. Use Paintbrush to "Test 2 & Test 3" Step3. Nothing changed. Format Paintbrush no function. Step4. Select Format Paintbrush on default font "Test 2" Step5. Use Paintbrush to "Test 1 & Test 2 & Test 3" Step6. All text format will be changed.
Created attachment 89067 [details] Step1. Select Format Paintbrush on default font "Test 1"
Created attachment 89068 [details] Step2. Use Paintbrush to "Test 2 & Test 3"
Created attachment 89069 [details] Step3. Nothing changed. Format Paintbrush no function.
Created attachment 89070 [details] Step4. Select Format Paintbrush on bigger font "Test 2"
Created attachment 89071 [details] Step5. Use Paintbrush to "Test 1 & Test 2 & Test 3"
Created attachment 89072 [details] Step6. All text format will be changed.
*** Bug 89542 has been marked as a duplicate of this bug. ***
Hi, I can confirm this annoying bug on 4.4.3.2 Best regards, Zeki
*** Bug 86041 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20161108
If it's unclear for anyone, the issue is that if the formatting is the default, it's not copied with the clone formatting tool. This is actually a regression, it's working fine in 3.6.0.4, but not okay in 4.0.0.3
Created attachment 135007 [details] Sample document The attached sample contains items with different formatting. Examples: - cloning from 1. to any other doesn't change anything, - cloning from 2. to 3. adds bold to 3., but doesn't remove italic, - cloning from 5. to any other only updates font size, - cloning from 6. to any other only updates color. The expectation is that the target has the exact same formatting in the end as the source (as long as direct formatting is concerned).
*** Bug 82725 has been marked as a duplicate of this bug. ***
Bibsected to this range in bug 82725 comment 14: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=15af925c254f27046427de70a59011e2ac3d6bdb..836822522a2e9f009c0870cbbcd48d45bbd3c622 There is a commit in that range that says: "Format paintbrush default behaviour Don't copy paragraph formats by default" https://cgit.freedesktop.org/libreoffice/core/commit/?id=1574c76ec20d1da479ed7e9c85a6cefacc132dfe Needs verification, though.
So checked MS Word and Google Docs and it behaves in what i would expect would be the correct behaviour. Glad to see its a regression and lets see who changed it and if it was intentional and what the reasoning for it was. Sad that is has been broken for so long. We definitely need a test case for such a basic feature.
Just (In reply to Aron Budea from comment #11) > If it's unclear for anyone, the issue is that if the formatting is the > default, it's not copied with the clone formatting tool. This is not a regression. This is not even a bug. Our documentation https://help.libreoffice.org/Common/Copying_Attributes_With_the_Clone_Formatting_Tool is rather clear on it: > By default only the character formatting is copied ; to include paragraph > formatting, hold down Ctrl when you click. To copy only the paragraph > formatting, hold down Ctrl+Shift when you click. This was different before 3.6, which release notes (https://wiki.documentfoundation.org/ReleaseNotes/3.6) mention the change: > Format paintbrush now differentiates automatic character formating > attributes applied to a paragraph from those applied to a portion of the > text inside a paragraph. These automatic character formating attributes are > applied to the entire paragraph by default; if Ctrl is held while the format > is passed, these attributes are applied to only the selected text. > (Maxime de Roucy) ... which refers to the commit mentioned in comment 14. The problem is that manual formatting appends instead of overwrite, yes; but please concentrate on real bug, not on expected behavior.
(In reply to Mike Kaganski from comment #16) > This is not a regression. This is not even a bug. > Our documentation > https://help.libreoffice.org/Common/ > Copying_Attributes_With_the_Clone_Formatting_Tool > is rather clear on it: > > > By default only the character formatting is copied ; to include paragraph > > formatting, hold down Ctrl when you click. To copy only the paragraph > > formatting, hold down Ctrl+Shift when you click. How is it possible to see if something is paragraph or character formatting? For example I could set a 3-word paragraph to bold, and unbold the 2nd word, but instead I could set the 1st and 3rd words to bold, and not touch the 2nd. In one case bold is considered paragraph formatting, in other case it isn't.
(In reply to Aron Budea from comment #17) > How is it possible to see if something is paragraph or character formatting? > For example I could set a 3-word paragraph to bold, and unbold the 2nd word, > but instead I could set the 1st and 3rd words to bold, and not touch the > 2nd. In one case bold is considered paragraph formatting, in other case it > isn't. I agree that it could be improved, because all this is not user-visible. But my point was that currently-visible behavior is not a bug or regression, but a consciously made decision. To improve here, we must first decide how to continue with our combination of character styles, paragraph styles that contain character settings, direct formatting of paragraphs and characters. Because it's not easy to devise a good format copy tool that would work "intuitively" in any circumstances, and in the same time would not ruin style-based approach. Simply applying all character-related properties to characters as direct formatting, where some of them come from paragraph style, would tend to multiply direct formatting and lead to surprises where user will be "unable to apply another paragraph style (nothing changes)" where the reality will be that new paragraph style's settings are overridden by direct character formatting. Also consider, e.g., when a user copies character formatting (and makes many paragraph-defined formatting the manual one), then decides to copy also paragraph settings (including style), and has both paragraph style *and* same-looking manual formatting applied. Skipping paragraph-style-related character formatting leads to surprise when user sees that some of character properties are not copied. What is the best approach when manual character formatting (e.g., italics) does not conflict with paragraph-style-defined character properties (font and its size, e.g.)? Do we need to overwrite all the settings from source, and make destination text formatted exactly like source, despite some properties of origin and destination differ only because of para styles? I suppose that dealing with this like with a "regression" is wrong, and UX-advise is required, with thoughtful analysis and some design specs before "fixing" it.
Thanks Mike for the examples. I tend to warn for the use of Clone Formatting. It's easy to use, but there is a good chance that the result is a mess, from maintenance / style point of view. Limiting the chance to mess up with styles could be done by restricting the use to only clone direct formatting. Now that will make users wonder too what is happening. OTOH, do people that use it, know about styles? So why worry.. yes, if you have to work with a document from someone who uses that tool. I wouldn't know a consistent solution at the moment to make all happy here. Removing 'regression' keyword
*** Bug 104920 has been marked as a duplicate of this bug. ***
Dear kyles, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Maybe this is a documentation problem, as suggested in bug #112872 (comment 4) Meanwhile the discussion here in comment 16 through comment 19 has been valuable for understanding why clone format does not work (for me) sometimes. And why "Clear Direct Formatting" can be a solution.
*** Bug 144809 has been marked as a duplicate of this bug. ***
Good news: this is fixed by https://git.libreoffice.org/core/commit/259ed2e3a135a5650fd321f408382d6b1b86bcad sw: fix format brush to override old format Thanks, Szymon!
*** Bug 50639 has been marked as a duplicate of this bug. ***