Created attachment 128143 [details]
Obfuscated .odt files produced from the MS files, that reproduce what I have described above
I have a novel; I decided to make sure every mention of the thing called "it" in italics, should be called "It" in italics (upper-case "I"). I have 3 versions of the MS: one for the 4"x7" print edition, one for the 5"x8" edition, and one for the Kindle edition.
I opened all three files.
I performed the Fine & Replace on the 4x7 file with no problem: I selected Whole Words only, typed in "it" (no quotes) in the search field, "It" in the replacement field, clicked on Format and left the font unselected but chose style Italic. I carefully made about 15 replacements (about 4 possible replacements would have been wrong in the context). F&R worked as expected, finding only "it" in italic as a whole word.
I then moved to the 5x8 edition MS. In the dialogue, most F&R fields were already set from editing the 4x7 file; but I had to type "It" into the replacement field. I then started searching. But now, F&R did not work correctly: it would only find regular-format "it" words. I watched on one page, where "it" was in italic, and another "it" appeared a little below. It would only find the 2nd, not the first. but after that, it would only find regular-format "it", and refused to find italic-format "it". I notice that under the Search field, the words "Italic, normal," appear, for the file where F&R is finding the wrong-format text. In the file where it is working, the text is displayed without a trailing comma: "Italic, normal".
In the Kindle edition (see file WT-CS-KDP.odt), it found a few italic "it"s, then started finding only regular "it"s. F&R seems completely unreliable: I just tried it, and it found in succession about a dozen italic "it"s, bypassing regular-"it"s as it should, then started finding regular-"it"s and ignoring italic "it"s. Basically at random. The function simply isn't working reliably.
I cannot supply you with the original source documents, however, as Amazon's T&C would not permit me to do that. So I have obfuscated the files, but leaving the letters "i" and "t" and untouched, and saved those files and attached them; they do evidence the bug, for me.
This bug may relate to 95633, 99038, 31491, or 95927, but none of them really sound the same as this, to me.
LO is becoming increasingly frustrating to me, as an author. This is the 3rd bug which is preventing me from making a specific edit to my LO MS to correct an edition. In this case, at least I have a workaround: I can Undo each change in the file for which F&R worked, carefully note where that was, find the same place in the other editions, and manually make the correction. For the others (103078 and 62603), they're show stoppers. It's very disheartening.
Having just done the manual fix-ups, I'll also note that Undoing to find them all worked well (there were actually 13 occurrences). But that there is also a bug in Redo, as after each redo, the text was converted from italic to regular. Fortunately, I saved a copy of the file before I started Undoing, so this is not a major calamity.
Same as the other bug report. Closing.
Okay, these steps reliably reproduce the problem for me:
1. Open the file I provided in the .zip file, called WT-CS-KDP.odt
2. Select While words only
3. Open the Find & replace panel
4. Click on the Other options link
5. Type these letters in the Search For field: it
6. Click on the Format option.
7. Select the Font tab from the format panel
8. Under the Style drop-down, select Italic
9. Click on Find Next, noting that it is finding italicised occurrences of "it", correctly.
10. Keep clicking Find Next. Note that from p469, it begins finding regular-format occurrences of "it", incorrectly.
Hopefully this shorter and more concise description will allow you to uncover and fix the bug.
Repro already with 3.6, but not with 3.3.
Arch Linux 64-bit, KDE Plasma 5
Build ID: 6dc8f25ecf676a2e4d1a1018b729fef4096df8e7
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4;
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on October 28th 2016
Arch Linux 64-bit
Version 18.104.22.168 (Build ID: e183d5b)
Arch Linux 64-bit
Adding more from another report:
attachment 131071 [details]
Find: Italic/Regular incorrectly
"But in some my capacious documents, it finds Italic and Regular (Normal) as I wrote, but now I discovered not all Regular.
I modified one capacious document to the small one.
In incorrect-find-italic.odt try to find d (Italic, Regular, No Format), description is also in document."
*** Bug 105725 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 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!
Bibisected on Linux with 43all repo to range https://gerrit.libreoffice.org/plugins/gitiles/core/+log/43c7830b03d141ae11d8617c0fdabefa32dd243c..ce97851773a06103504972eb2771eecd7dd81e36
The range is massive, with nearly 2 months of commits.
Let's use keyword notBibisectable in such case.