Created attachment 65568 [details] Example of file used to reproduce bug SUMMARY After upgrading to the last release version of LibreOffice 3.6.0.4, I found that the function Format Paintbrush does not work correctly in Writer. What happens is that only the last paragraph of the selected targed is modified according to the source. HOW TO REPRODUCE 1. create a paragraph ("source") to be used as source and format it as you normaly would (type, size of letter, alignement, etc.) 2. create a second and a third paragraph with different format from the source (the second and the third may have the same format - I guess it doesn't matter) 3. position the cursor in the source paragraph (first one), or select it, and click on the Format Paintbrush icon. 4. Select the first and the second paragraph at once. WHAT HAPPENS Only the last selected paragraph is modified according to the source. The first selected paragraph will not be modified or it will be modified not correctly, i.e., not according to source. WHAT I EXPECT TO HAPPEN Both paragraphs should be modified according to the source, despite the quantity of paragraphs and the order they are selected. HARDWARE and SOFTWARE I'm using LibreOffice 3.6.0.4 (updated from 3.5.5) on a MacBook/MacOSX 10.6.8). ATTACHED is an example of the .odt I've used to reproduce this - after the reproduction. [text inside brackets doesn't count as paragraphs] AFTERWORDS Please let me know if I can provide any other info to help debug this. KEY WORDS Formatting, format paintbrush, libreoffice 3.6
It annoys me a lot also, this is a regression, 3.5.x works fine, 3.6.0 or 3.6.1 or 3.6.2rc1 not. I've tried a daily build of 3.7 and seems not affected. I add a video to show the bug and the steps
Created attachment 67433 [details] Video showing the problem with 3.6.1 Sorry if is h264 and not webm, but I've issues with video quality with FDesktopRecorder that I'm trying to solve
Just to add that I've verified it on Debian GNU/Linux (the one used on the attached video) and Windows as well
(In reply to comment #1) > It annoys me a lot also, this is a regression, 3.5.x works fine, 3.6.0 or 3.6.1 > or 3.6.2rc1 not. Therefore added keyword “regression”. (In reply to comment #3) > Just to add that I've verified it on Debian GNU/Linux (the one used on the > attached video) and Windows as well So this is not a Mac-specific problem, but Platform = “All”?!
REPRODUCIBLE with LibreOffice 3.6.2.1 (Build ID: ba822cc), German langpack installed, on Mac OS X 10.6.8 (Intel), following the steps to reproduce given by the original reporter (comment #0). Works fine (or at least much better) in LibreOffice 3.5.6.2, so indeed a regression.
PARTIALLY REPRODUCIBLE with current master build (LOdev 3.7.0.0.alpha0+, Build ID: 6a8694d, pull time: 2012-09-20 05.53.26); as far as I can see now the font family of all paragraphs is changed correctly according to the font face of tehe “source” paragraph, but font size and styles (bold, italic) are still not changed to the settings of the “source” paragraph, but stay as before. So some progress, but still buggy.
@ our Writer experts: Hello Cédric, hello Michael, this is a regression in LibreOffice 3.6 and, as far as I can see, still (partially) reproducible in LibreOffice master. This regression makes it more or less impossible to use the Format Paintbrush tool for changing multiple paragraphs at once. Can you please take a look at this issue? Thank you very much!
Thanks to some big and accurate help in irc, I've learned the fantastic bibisect tool and I've bisected the issue. last good in the log is: # good: [7360294b6a46a375941e6c58c18196593f7b4e41] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4 the output of git bisect was: c784752f223dc690ec4c9303d262405f86678457 is the first bad commit commit c784752f223dc690ec4c9303d262405f86678457 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Thu Apr 26 23:37:39 2012 +0200 source-hash-8757c9c462ba690de60602404ef2e9e99702f0b4 commit 8757c9c462ba690de60602404ef2e9e99702f0b4 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Wed Mar 28 12:07:30 2012 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Wed Mar 28 13:08:58 2012 +0100 remove static OUStrings from static_initialization_and_destruction chain :100644 100644 1216266d50ebd7fa6b1ec5525c8e288610f77c1a 7ec0b6114ae4bfde5e386c4e6aeb640b3ad16714 M ccache.log :100644 100644 635d2044711c289b9bf669952cb031603dc8207b ad0e86a364b3e8d83abcd68ed98613c3091a49d8 M commitmsg :100644 100644 3db54b95940b31f72c55f967ab26c2f993129007 760070c2782d600ad460883fa5195cef88518bb5 M dev-install.log :100644 100644 f0fb989bb3a7dc720a1e18618fbacd5482ed2e59 25b7ef43df89c2f104b75e2591fd2bdd74e9b83f M make.log :040000 040000 30797d6efae265675b8e6c4e959b5e6f12853f69 4e1a2666970aca84ec9a91b184e12a9fe3cfeff6 M opt
ehm, I don't master (yet) the bibisect tool... Last good is not what I posted previously, but should be this one: 45295f3cdceb4c289553791071b5d7f4962d2ec4...8757c9c462ba690de60602404ef2e9e99702f0b4 In any case the log is this, so more expert can check and get the correct data: $ git bisect log # bad: [aa062d7ec36c69c1aff1abf994a90c5f0987c5be] source-hash-d50f02bec4a70bd26a518e4e76f4a876454ab937 # good: [bba31ba417672c6f185a6875c813677e8ac44c86] source-hash-9a8d7e2a3f41f9e1c39c5634714a3a2b21776670 git bisect start 'latest' 'oldest' # good: [631e1335e3a9629152a2a4cb0f99304248299eb0] source-hash-bd6310886dc4351a8ac3ed3ee9a4f65d2a0e005c git bisect good 631e1335e3a9629152a2a4cb0f99304248299eb0 # bad: [904babc296329c93373e5b21b4652e836898a932] source-hash-eab7e131ecebe4cdefcdcb1ad176bbdce83cb467 git bisect bad 904babc296329c93373e5b21b4652e836898a932 # good: [57a546c546f767928deac71a8925d8f280097878] source-hash-0a8596dd8ebbbc80e87d4bdfafe3cf53355b7d43 git bisect good 57a546c546f767928deac71a8925d8f280097878 # good: [7360294b6a46a375941e6c58c18196593f7b4e41] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4 git bisect good 7360294b6a46a375941e6c58c18196593f7b4e41 # bad: [9faa6a5abd408c308763a64a4698f36b88a283c2] source-hash-552ba413bc95b1a14638558d9436141825100c52 git bisect bad 9faa6a5abd408c308763a64a4698f36b88a283c2 # bad: [c784752f223dc690ec4c9303d262405f86678457] source-hash-8757c9c462ba690de60602404ef2e9e99702f0b4 git bisect bad c784752f223dc690ec4c9303d262405f86678457
based on the excellent bibisect work by Marco... my guess is that the culprit is core - add GetCurParAttr and GetPaMParAttr in SwEditShell - http://cgit.freedesktop.org/libreoffice/core/commit/?id=16094573256e4c4ece92f86f63559658a25e8d61 or core - Rewrite of the format paintbrush - http://cgit.freedesktop.org/libreoffice/core/commit/?id=357fac9713875302d30185feabaf5c165e040ca4 Norbert
I checked right before reverting, but I can't reproduce the bug shown on the video with master. Could someone check that I'm not alone in that case?
@Cédric Bosdonnat, as I wrote in my comment #1, with 3.7 builds it works fine (I've tested yesterday build too), don't know if because the new feature has been fixed, or has never been applied (at least I got the builds from the link on the site, the name states 3.7.0.0alpha0, is the "master" you are referring to?). The problem is that this bug is present in 3.6.0, is still present in recent 3.6.3, and if not fixed will be present in 3.6.4 too, keeping the format paintbrush almost useless for the entire 3.6 series. Regressions should be fixed with high priority, because they upset a lot users and create a lot of problems reducing the trust in the project, OMHO.
(In reply to comment #12) > @Cédric Bosdonnat, as I wrote in my comment #1, with 3.7 builds it works > fine (I've tested yesterday build too) Just a hint: My result was (and is) a little bit different: as far as I can see, the Format Paintbrush works *better* in 3.7 than in 3.6, but still not correctly/as expected/as in 3.5. My impression is that in 3.7, the Format Paintbrush correctly resets character attributes, but not paragraph attributes, e.g. aligment and line spacing. (But this may be very well another bug, and I can file a different bug report for that issue, if recommended.)
I just posted a patch called "fix bug 53508" on the libreoffice-dev mailing list. It apply the paragraph automatic formatting attributes to all the paragraphs in the selection instead of just the last. Remember that in 3.7 you have to hold Ctrl when you past the format to past character and paragraph formating.
(In reply to comment #14) > Remember that in 3.7 you have to hold Ctrl when you past the format to past > character and paragraph formating. Wow -- thank you for the hint -- I must have missed this! So we can forget completely about my observation in comment #13: Very probably it was just caused by my ignorance of this change ...
fixed on master and libreoffice-3-6 should land on 3-6-5
in 3.6.4 this problem is present
(In reply to comment #17) > in 3.6.4 this problem is present Yes; and this is OK ;-), because comment #16 says: > fixed on master and libreoffice-3-6 > should land on 3-6-5 So please be patient until 3.6.5 is mature, and then test again. Sorry -- but this is the way free and open software development works :-( ... If the bug is still present in 3.6.5, *then* please open this bug again! Thank you very much!