When I use the clone formatting button to copy attributes (generally I just use it to copy the font size and font type), sometimes the attributes will not copy from the selected text.
This is not normal behavior, as most of the time the clone formatting works properly, in similar situations. Furthermore, I found a way to fix this issue, implying that this is a bug.
In cases where it does not work properly, here's what seems to fix it. First, (on the text you want to copy the formatting from), you manually hit enter on the attributes, in the formatting toolbar. You should do this for all of the attributes you want to transfer, that are not transferring properly right now, to that problem line of text.
For example, go to the formatting toolbar and hit enter on the text size and font type. (The attributes displayed in the toolbar will already be accurate, you just need to hit enter to "re-set" them.) After re-assigning the attributes the problem will be resolved. The font formatting will properly copy to the problem text in the future, with no further issues.
Note that when this problem originally occurs, sometimes some attributes will copy fine. For instance, before re-entering the attributes, the clone formatting button might copy the text font but not the font size, to the problem line of text.
Steps to Reproduce:
1.Click on text where the formatting needs to be copied from
2.Select the "Clone Formatting" button
3.Highlight the text to be formatted
Sometimes the attributes do not copy properly.
Font size and font type should have been copied to the text.
User Profile Reset: No
-Occurs in Linux Mint 18 and Windows 7 using 22.214.171.124 (64 bit)
-Occured in the previous versions of Libre Office Writer (version 5.?.?)
-This issue does not occur all of the time. It happens sporadically but regularly and for a long enough time, to know there is a issue here. A video or example file can be provided.
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Created attachment 129936 [details]
Example Document Where The Issue Occurs
Given that user has said he or she found a way to fix the issue (a workaround?) lowering to minor.
Minor: Can slow down but will not prevent high quality work.
Yep, confirmed with the document. I had to highlight the text and reassign the 12 pt font before cloning worked.
However, in 126.96.36.199 I did not have to do this. It worked right away.
Arch Linux 64-bit, KDE Plasma 5
Build ID: fc0d4e6bc43d5f982452df07930f5ecf5927ad22
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4;
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on December 31st 2016
Arch Linux 64-bit
Version 188.8.131.52 (Build ID: e183d5b)
My attempt to reproduce this led to tdf#105077 "assertion in SwRegHistory::InsertItems". Perhaps that is how a dbgutil build reports the problem reported here.
Created attachment 130248 [details]
Assertion failed dialog
Works in 184.108.40.206, doesn't work in 220.127.116.11 / Windows 7. Adjusting earliest affected version.
Also confirming assertion failed error in a dbgutil master build (87fce022c65c1d2aed1ca59967137d77d936043c). See attached screenshot.
I see that the assertion reported in bug 105077 is fixed, but I still
see this bug in daily Linux dbgutil bibisect repository version
2017-01-11. So, I am changing the bug summary to remove mention of
Perhaps the comment in commit db4badfc, fixing bug 105077, is a hint
for this bug:
// tdf#105077 even worse, node's set could cause
// nothing at all to be inserted
Where is the "Clone Formatting" menu option option that you mention in
comment 5? I do not see it in my old versions, like bibisect-42all
Look for a paintbrush on the toolbar. It's called Format Paintbrush in old version.
Thank you for that pointer, Aron.
I see that the repository bibisect-41max version oldest already has
Seems to be a duplicate of bug 82725.
*** This bug has been marked as a duplicate of bug 82725 ***
*** This bug has been marked as a duplicate of bug 71481 ***