Created attachment 131316 [details] Demo In some cases Find doesn't find formatted text, or Find/Replace of formatted text removes other formats inside the formatted text. Not easy to reproduce. See attached document, which describes this behavior and probably reproduces my observations.
Could it be that there are settings influencing the find/replace operation which are not visible/accessible in the dialogue? My impression is that macros which include find/replace operations can influence these “hidden” (?) settings.
Created attachment 131338 [details] A new, better (?) demo doc
I added now a new demo doc, DemoNEW.fodt, which maybe will show the problem in a reproducible way. The document contains two macros. Demo1 writes four lines into the document (it is simply a recorded macro), and Demo2 does the replacements (inserting start and end tags for text in 10 pt (<s>) and for underlined text (<u>).) On my side, as shown on screenshoots included in the document, -- the format bold is lost with this replacements (lines 2 and 3), and -- underlined text is not found and replaced (line 4).
Reproduced with the macro. Arch Linux 64-bit, KDE Plasma 5 Version: 5.4.0.0.alpha0+ Build ID: 7ec0500e20cf273d70c4fbddb4063b8f8295307c CPU Threads: 8; OS Version: Linux 4.9; UI Render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on February 18th 2016 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
I am now able to show the problem in a simple and reproducible way (I hope): Write these four lines (paragraphs) in a new document: 1 This is a simple one-line paragraph ending with x. x 2 This is a simple one-line paragraph ending with x. x 3 x 4 This is a simple one-line paragraph ending with x. x Each line ending with x and Enter. Select now with the mouse the word simple in all lines and make it bold. Select the whole first line including x and make it underlined. Select the second line without the ending x and make it underlined. Select the fourth line without the ending x but including 3 in the third line, and make it underlined. Do now Search&Replace: Search: .* with format Underlined single Replace: <u>$0</u> with activated Regular expression, Replace all. The result (at least on my side): The bold formatting in the first line is lost! My assumption: There is a inconsistency / intransparency / undesirable behavior in the case when selection includes a paragraph end (the endmark)! Another observation: When replacing is done for single characters (.), the bold formatting is not lost!
Butch: if you have time, you could go through the other bugs in the "Find-Search" category and see, if there is a report exactly like yours: https://bugs.documentfoundation.org/showdependencytree.cgi?id=102847&hide_resolved=1 Find on page "format" and you will locate all the relevant ones.
No, as far as I can see, there is no similar issue. Could you reproduce the bug(?) according to my last description? I think the main point is using selections which include a paragraph end (the endmark)!
(In reply to Butch from comment #7) > Could you reproduce the bug(?) according to my last description? Yes, with 3.6. With 5.4, it says "Search key not found". I think this might have something to do with how it is forcing text color into the equation.. With 5.3, it does not allow me to use regexes for some reason :(
(In reply to Buovjaga from comment #8) > Ithink this might have something > to do with how it is forcing text color into the equation.. Text color, equation?
(In reply to Butch from comment #9) > (In reply to Buovjaga from comment #8) > > Ithink this might have something > > to do with how it is forcing text color into the equation.. > > Text color, equation? I meant mixing text color into what is being found, I created a new report for the problem: bug 106099
(In reply to Buovjaga from comment #8) > With 5.4, it says "Search key not found". I think this might have something > to do with how it is forcing text color into the equation.. Just a note: I could now reproduce the problem in 5.4 by using "Attributes" instead of Format. There I can select Underline and no color will block the search.
** 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
Dear Butch, 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 https://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
Report must be simple. I just searched for Format-Underline and found 5 instead of 6 results. Lo 7.1+.
@Butch I believe your report is a duplicate of bug 62603. Tested with 7.2.0.0.alpha0+ The problem is not regex, but that the font attributes of the first matched character is applied to the enter replace string. (This is also consistent with your observation in comment 5 that formatting is not lost if you replace single characters.) See bug 62603, comment 24 If you think your case is not a duplicate of bug 62063, then please REOPEN, with an explanation of what is different. There can also an interaction problem with search with "format" and direct formatting see bug 133439 *** This bug has been marked as a duplicate of bug 62603 ***