Bug 127725 - FIND & REPLACE DIALOG: Find by format is fundamentally broken by extraneous formatting details in Writer
Summary: FIND & REPLACE DIALOG: Find by format is fundamentally broken by extraneous f...
Status: RESOLVED DUPLICATE of bug 126527
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Find&Replace-Dialog
  Show dependency treegraph
Reported: 2019-09-23 18:09 UTC by Alexis
Modified: 2020-01-13 07:03 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:

Screenshot of the dialog illustrating the extraneous & unremoveable formatting features (88.74 KB, image/png)
2019-09-23 18:11 UTC, Alexis

Note You need to log in before you can comment on or make changes to this bug.
Description Alexis 2019-09-23 18:09:37 UTC
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.
Comment 1 Alexis 2019-09-23 18:11:07 UTC
Created attachment 154394 [details]
Screenshot of the dialog illustrating the extraneous & unremoveable formatting features
Comment 2 m.a.riosv 2019-09-23 20:42:21 UTC

*** This bug has been marked as a duplicate of bug 95927 ***
Comment 3 V Stuart Foote 2019-09-23 21:40:46 UTC
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.

[1] https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission
Comment 4 Alexis 2019-09-23 23:18:38 UTC
You are ignoring from my report that this *only* happens on .deb packages on Linux perhaps?
Comment 5 Alexis 2019-09-23 23:19:12 UTC Comment hidden (obsolete)
Comment 6 Alexis 2019-09-23 23:22:00 UTC
Also, in my report I provided instructions that work for producing this behavior from *blank* documents.
Comment 7 Alexis 2019-09-23 23:31:29 UTC
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).
Comment 8 Alexis 2019-09-24 20:00:14 UTC
Bug persists with update to on Ubuntu 19.04.
Comment 9 Alexis 2019-09-30 19:49:15 UTC
*** Bug 127784 has been marked as a duplicate of this bug. ***
Comment 10 Dieter 2020-01-06 21:53:10 UTC
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 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.
Comment 11 Alexis 2020-01-13 06:00:37 UTC
This bug has been fixed in the latest release.
Comment 12 Dieter 2020-01-13 07:03:45 UTC

*** This bug has been marked as a duplicate of bug 126527 ***