Summary: | Find/Replace applies the font attributes of the first character in the 'find' match to the entire replaced string - often with undesired effects, such as losing italic or bold direct formatting | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Christian Gagné <coldchrisg> |
Component: | LibreOffice | Assignee: | Matt K <mattkse> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | courrier.oou.fr.mjk, grassode, ilmari.lauhakangas, jluth, lobug, luke.kendall, nissimkaufmann, pje335-lo, sdc.blanco, thomas.lendo, xiscofauli, zen |
Priority: | high | ||
Version: | Inherited From OOo | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://issues.apache.org/ooo/show_bug.cgi?id=121482 https://issues.apache.org/ooo/show_bug.cgi?id=2997 https://bugs.freedesktop.org/show_bug.cgi?id=65765 https://bugs.documentfoundation.org/show_bug.cgi?id=46028 https://bugs.documentfoundation.org/show_bug.cgi?id=112961 https://bugs.documentfoundation.org/show_bug.cgi?id=38982 https://bugs.documentfoundation.org/show_bug.cgi?id=107857 https://bugs.documentfoundation.org/show_bug.cgi?id=79717 |
||
Whiteboard: | target:24.2.0 | ||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 102847 | ||
Attachments: |
findReplace_formatTest.doc: simplify testing with a copy/paste/highlight doc.
Example file to reproduce the bug |
Description
Christian Gagné
2013-03-21 18:19:37 UTC
Note: In the previous comment, the reference to the AOO issue number 2997 inadvertently links to an unrelated issue that pertains to another software module; please disregard the link. Added AOO bug URLs to "See Also". Hello Christian, *, thank you for reporting this bug :) As I am only one of the QA guys and not able to understand enough from your description, but can reproduce the bug as follows: 1. Open a new Writer document 2. Enter <quote>"test "test</quote>, where the second "test" is set to italic 3. <Ctrl>+<H> 4. Enter <quote>"([:alnum:])</quote> in "Search for" 5. Enter <quote>“$1</quote> in "Replace with" 6. Click on "Other Options" and mark "Regular expressions" 7. Now click on "Replace All" Result: Quotation marks are replaced, the "t" from the second test is not italic any more ... Expected result: LO should replace the quotation marks, but not touch the formation I have to say, that I have to copy the quotation mark to Writer, as Writer replaced my inserted ones with curly quotation marks ... :( LO: Version: 4.1.0.1 Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155 with Germanophone lang- as well as helppack OS: Debian Testing AMD64 HTH Thomas. Thank you for your bug report, I can reproduce this bug running LibreOffice Version: 4.1.0.1 Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155 on Mac osx 10.8.4. I just did the steps that Thomas gave me and the T wasn't italic anymore. ** 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 (4.4.1 or later) 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-03-16 (In reply to thackert from comment #3) > Hello Christian, *, > thank you for reporting this bug :) As I am only one of the QA guys and not > able to understand enough from your description, but can reproduce the bug > as follows: > > 1. Open a new Writer document > 2. Enter <quote>"test "test</quote>, where the second "test" is set to italic > 3. <Ctrl>+<H> > 4. Enter <quote>"([:alnum:])</quote> in "Search for" > 5. Enter <quote>“$1</quote> in "Replace with" > 6. Click on "Other Options" and mark "Regular expressions" > 7. Now click on "Replace All" > > Result: Quotation marks are replaced, the "t" from the second test is not > italic any more ... > Expected result: LO should replace the quotation marks, but not touch the > formation > > I have to say, that I have to copy the quotation mark to Writer, as Writer > replaced my inserted ones with curly quotation marks ... :( Reproduced. Win 7 Pro 64-bit Version: 4.5.0.0.alpha0+ Build ID: 8c3cf9dd48e40604867d3a28bddaccd65142df17 TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-03-27_15:15:18 Locale: fi_FI Yes, I found that somehow, all my non-breaking spaces in my <nbsp><sp> pairs of spaces between sentences had been lost: changed into just plain <sp><sp>. I did a regexp search and replace to fix them all. Some days later, I noticed that wherever the replacement was made and the end of the sentence was in italics, it copied the italic style across to the first character of the next sentence. Likewise, where the end of the 1st sentence was Regular, and the 2nd sentence was italic, the 1st character of the italic sentence was changed to Regular. Caused me a lot of work to manually find and fix them. This is a truly horrible bug. Because you can't search for text and include atribute style changes, you can't easily find them, and you certainly can't fix them with a big search and replace. Given that my novel is over 130,000 words long, his bug is really punishing me. That's twice, now, this bug has affected my novel, and I've had to manually fix it. At least this time I found this bug report, and found what caused it, so I can at least use a search for likely sentence-starts with italic format, to narrow the search, even if each fix must be done manually. An odd thing I noticed while fixing this, too: when the Find&Replace dialog has focus, all the comments in the document are not displayed. But when I click back into the document and select the text to correct the italicisation of, the comments are still not displayed: they instantly reappear however when I either clear the formatting or set the text to italic: not before. That seems odd, so I thought I'd mention it. I should add, I'm using LO 5.0.3, on Linux (Ubuntu 14.04). I would like to suggest that this bug level is probably critical, as the correct encoding of text attribute is lost. This is data loss. F&R damages the document content, and the more replacements that are made, the bigger the damage caused. In some ways the damage is made worse by the fact that the damage it causes is a little subtle, so you may not even notice the errors introduced until (like me), you have made so many other changes that you can't simply revert to an earlier copy of your document (assuming you have one). It also means that Find&Replace with regular expressions cannot be used - or at least, cannot be used to do the actual replacement. So it is also a major loss of function: but the data loss is worse. I do not have permission to increase the bug severity: I hope that I have argued the case for such a change, however. Ok, adjusting per https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg Luke: would you like to join the QA? team https://wiki.documentfoundation.org/QA Then we could discuss prioritizing and give you the rights to do it. Sorry, I've been absolutely flat-out getting my novel published, and Christmas and New Year (and I still am, as I'm now finalising the print edition(s) and starting to plan the book launch), but I'd be happy enough to do so. I had a look at the link provided, and had a look at the flowchart, which is clear and makes good sense to me. So, yes, I'm happy to get involved as you suggest. My apologies for the long delay in replying. I have now added myself to the Cc list, so I'll notice further emails much more quickly (rather than noticing it because I happened to come back to see if anything had changed). Cheers, luke Ok, Luke, I added you to contributors. Drop by on IRC whenever you feel like discussing things: https://wiki.documentfoundation.org/QA/IRC Setting priority to high. Could this be assigned to someone? There are some global edits I need to do, but do not dare to, because of this bug: the work it would cause me to fix the text afterwards would be about the same as doing the global edits manually. I'm thinking I may need to switch to some other .docx or .odt editor (liem Office) just to do the global edit. But I'm not optimistic, because round-tripping tends to break some header/footer/paragraph styles in strange ways. And because of https://bugs.documentfoundation.org/show_bug.cgi?id=99015 I can't edit the XML directly, either, as an ugly/desperation workaround. Created attachment 127228 [details]
findReplace_formatTest.doc: simplify testing with a copy/paste/highlight doc.
confirmed still a bug in LO 5.3dev, and has existed since at least bibisect-43all LO3.6 (oldest I can test in Ubuntu 16.04).
Regex is irrelevant - it happens without regex as well. Basically, Find/Replace applies the format of the first character across the entire replaced string.
Thanks, Justin - it's especially valuable to know it happens for non-regex uses too! That means I'd just been lucky so far in those few cases I used it for a simple text replacement - because such strings tend to have far fewer matches, and usually of whole words with a space or punctuation character alongside I suppose. I still dare not use Replace All, as it does too much damage to my novel(s). I will be *so* glad when this bug is finally fixed! Only regressions should use the keyword 'preBibisect'. Removing it... (In reply to Justin L from comment #15) > Created attachment 127228 [details] > findReplace_formatTest.doc: simplify testing with a copy/paste/highlight doc. > > confirmed still a bug in LO 5.3dev, and has existed since at least > bibisect-43all LO3.6 (oldest I can test in Ubuntu 16.04). > > Regex is irrelevant - it happens without regex as well. Basically, > Find/Replace applies the format of the first character across the entire > replaced string. Could I just add that the effect goes one character beyond the end of the replaced string? I.e. the font attribute of the last character of the match I think is applied to the character past the replaced string. And since searching for text attributes (e.g., italic) makes Find & Replace unreliable (https://bugs.documentfoundation.org/show_bug.cgi?id=103400), there's also no way to find them with a search, you have to scan every character of your document by eye to find them. Created attachment 136821 [details] Example file to reproduce the bug I am just reporting that this bug is still present in 5.4.1.2. Attached is a very short file with a simple example of the broken behaviour. I hope this helps. Here are the reproduction steps: 1. Open the provided file (RegExp-format-ruin.odt) 2. Open Find and Replace. 3. Copy and paste the Find string provided in the doc into the Find field 4. Copy and paste the Replace string provided in the doc into the Replace field 5. Click Find. 6. Click Replace Result: note that the Italic style capital "O" changes to Regular. From the user perspective, only the space was changed (of course, the whole matched text was replaced). All the same, the format or attributes of matched sub-patterns ($1, $2 etc.) should be preserved when they are replaced. PS: === I feel this is related to similar problems when manually replacing selected text: the new text typed in is given the format (italic/regular/bold) of the text immediately to its left, instead of the format of the text that is being replaced. Maybe you would prefer a second bug report for that. I have done so as Bug 112961. ** 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 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 I can confirm the bug is still there, exactly as described in the example file supplied to reproduce the bug, RegExp-format-ruin.odt Tested with: Version: 6.1.2.1 Build ID: 65905a128db06ba48db947242809d14d3f9a93fe CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: en-GB (en_AU.UTF-8); Calc: group threaded Just a note that I'm hopeful that Phil Krylov may have fixed and some larger issues as noted in the (related, I think) https://bugs.documentfoundation.org/show_bug.cgi?id=79717 *** Bug 138489 has been marked as a duplicate of this bug. *** repro by following procedure in comment 19 and using attachment 136821 [details] Version: 7.2.0.0.alpha0+ (x64) Build ID: 4041c68ea59181f1c4774c356809066d2051db41 CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win Additional information. 1. Continue using "find and replace" in attachment to see that 'W' in 'Whichever' is converted from regular to italic, as well as the spaces. 2. Start with new copy of attachment 136821 [details], search with find: ? W replace: ? W Result: get same "effect" (i.e., entire replacement becomes italic) 3. Change font size of question mark to 28pt, repeat test, 'W' becomes 28pt. on replacement. 4. In short: as noted already in comment 15, it appears that the font attributes of the first matched character is applied to the entire replacement, nothing to do with regex. Have changed bug summary to be more accurate/informative.... *** Bug 106076 has been marked as a duplicate of this bug. *** *** Bug 75885 has been marked as a duplicate of this bug. *** Add Calc bugs 92447 and 38983 to see also. Maybe they are duplicates with each other and maybe both are duplicates with this one. Will leave that decision to more knowing persons. Bug 107857 is probably a duplicate of this one. Have not marked as a duplicate because bug 107857 comment 11 gives an explanation in xml about what is happening. In relation to Importance, note that bug 107857 has two duplicates itself, which would make at least 6 duplicates, if they were applied here. Fix is tracked in https://gerrit.libreoffice.org/c/core/+/155274 Matt K committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0c3b89da7cde9866bf3174a6276736c76efb8356 tdf#62603 Fix find/replace to not extend font attributes It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. Can this be closed as fixed? (In reply to Buovjaga from comment #31) > Can this be closed as fixed? Yes, closing it. |