Description: In recent versions of LibreOffice Writer (since at least 6.0, if not 5-point-something) find/replace using formats is unusable, because unmodifiable extraneous formatting details are included in the find formatting which preclude a positive match. Steps to Reproduce: 1. Open blank document (or existing document with formatting as I describe below), and type a few lines of text. 2. Select a few words within the text, and set font to 'Adobe Garamond Pro' and style to 'Bold' (on my system there is no such font) 3. Open the Find & Replace dialog, leave the 'Find' and 'Replace' fields blank. 4. Click 'Format...' 5. Select the 'Font' tab, and set font to 'Adobe Garamond Pro Bold' (naturally you may, or may not have this font on your system, bug works with other font values), set style to blank (i.e. *not* to 'Regular', 'Italic', etc.), and click 'OK' 6. Pay close attention to the formatting descriptor below the 'Find' field: it contains kerning, indent left/right, and from top/bottom values that you did not explicitly set. Actual Results: Find or Find/Replace using Format... does not result in any positive matches. Example: I want to search for instances of the font 'Adobe Garamond Pro Italic' (of which there are many instances in a legacy document I have, although this font is not installed on my system), and replace with 'Adobe Garamond Pro' (which is installed on my system) and with the 'Italic' style. However, instead of searching only for text formatted as 'Adobe Garamond Pro Italic', LibreOffice—without any other input on my part telling LibreOffice to do so—will only search for 'Adobe Garamond Pro Italic, Kerning 0 pt, Indent left 0.0 inch, Indent right 0.0 inch, From top 0.0 inch, From bottom 0.0 inch'. It is seemingly not possible to edit these extraneous formatting directives. For example, while I can go to the Indents & Spacing tab in the Search for formatting dialog, and set, say, a value of 1.0 inch for Indent left (which is just as useless a search value as 0.0, since my indentation varies throughout my document), I cannot change Indent left to a blank value without it immediately reverting to '0.0 inch' when I tab to the next field or click OK. This extraneous formatting results in zero positive hits with Find and with Find/Replace. Expected Results: andI expect Find and Find/Replace using Format... to not unavoidably introduce extraneous and unremoveable search parameters which effectively break searching by format. Reproducible: Always User Profile Reset: No Additional Info: I have written out the above example on ask.libreoffice.org here: https://ask.libreoffice.org/en/question/208926 I have included a screenshot and in the comments an LO confirms the bug ***on .deb packages only.*** I am using LibreOffice Writer on Ubuntu 19.4, although I saw the same behavior on Ubuntu 18.10.
Created attachment 154394 [details] Screenshot of the dialog illustrating the extraneous & unremoveable formatting features
*** This bug has been marked as a duplicate of bug 95927 ***
Hmm, can not confirm on Windows builds. With your STR example on Windows, the font selection is Adobe Garamond Pro or Adobe Garamond Pro Bold, no other weights are installed. And if the Direct Formatting is applied against Adobe Garamond Pro the search would be "a Font and a Style"; a search for font Adobe Garamond Pro Bold would not find a string in Adobe Garamond Pro with Bold attribute applied. In order for us look at the mix of Direct Formatting and Style based content we'll need an anonymized [1] sample document in its ODF archive. Or better an anonymized document saved out to Flat ODF. Otherwise Windows builds the <Ctrl>+H Find & Replace dialog's use of Format/No Format is consistent, as is the alternative flow of using defined Paragraph Styles for the find and the replace. But then, Windows and macOS handle font naming differently than Linux distros. Please post up a sample document or two, so we can see if there is a valid issue or just a use issue when attempting to replace some mix of Direct Formatting and applied Styles. =-ref-= [1] https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission
You are ignoring from my report that this *only* happens on .deb packages on Linux perhaps?
Also, in my report I provided instructions that work for producing this behavior from *blank* documents.
Thank you for having a look at my first bug report here, Miguel. I am not sure this is a duplicate: I describe unexpected behavior in Writer (uneditable extraneous format search terms) that does not appear in the proposed duplicate (which simply describes difficulties with searching for instances of direct font formats).
Bug persists with update to 6.2.7.1 on Ubuntu 19.04.
*** Bug 127784 has been marked as a duplicate of this bug. ***
Alexis, sounds to me like a duplicate of bug 126527, that is fixed in LO 6.4. So could you please try to reproduce it with 6.4.0.1 or actual master? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in LO 6.4 or in the master build.
This bug has been fixed in the latest release.
*** This bug has been marked as a duplicate of bug 126527 ***