# Is find format fundamentally broken by extraneous formatting details in Writer?

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.

For example, I want to search for instances of the font 'Adobe Garamond Pro Italic' (of which there are many instances in a 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 the 'Italic' style. However, when I attempt to create this formatting I get the below:

You can see that instead of searching only for text formatted as 'Adobe Garamond Pro Italic', I am—without any input of my own telling LibreOffice to do so—searching 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.

I am using LibreOffice version 6.2.6.2 on Ubuntu 19.4.

edit retag close merge delete

From my perspective this looks like a bug for *.deb packages. I've checked several PPA (6.2.6.2, 6.2.7.1, 6.3.1.2) versions and .deb version from libreoffice.org ((6.2.6.2,) website (native packages) and all show that behavior, while on my RPM based systems this doesn't happen and no additional format properties appear in the dialog.

( 2019-09-17 00:17:07 +0200 )edit

@Opaque I really appreciate that feedback. Do you know the appropriate venue to submit a bug report (I assume it is not this forum) for that degree of package specificity?

( 2019-09-17 00:34:29 +0200 )edit

Yes, definitely not the right place here - bug reports need to go https://bugs.documentfoundation.org/

( 2019-09-17 08:56:20 +0200 )edit

@Opaque Thank you! I have done my best at submitting a bug report there, and made mention of your replication limited to .deb packages.

( 2019-09-23 20:29:50 +0200 )edit
( 2019-09-23 22:44:48 +0200 )edit

Sort by » oldest newest most voted

I shan't answer directly your question but criticise your workflow. There are two ways to address your problem: either the replacement is temporary (because the document is shared/exchanged between partners with different configurations and you are not the primary author) or it is a permanent change.

## Temporary replacement

Go to Tools>Options, LibreOffice>Fonts and edit the replacement table.

The original formatting in the document is not changed but display, layout and printing on your computer will be done according to the replacement font(s).

Note that any edit you make are done with your configuration. Consequently, if you're working outide well defined styles (direct formatting), your changes will have to be edited by the originator to restore the font(s) in your edits.

## Permanent change

It is quite easy if you worked consistently with styles, having totally avoided direct formatting. You only need to change the Font tab in the styles. Moreover, if your styles are organised hierarchically, the change is made only in the common ancestor style (one change for the whole document!).

Unfortunately, if you format your document with toolbar buttons and keyboard shortcuts, you must track the occurrences manually and you aren't guaranteed against missing one.

To show the community your question has been answered, click the ✓ next to the correct answer, and "upvote" by clicking on the ^ arrow of any helpful answers. These are the mechanisms for communicating the quality of the Q&A on this site. Thanks!

more

-1 I would downvote this answer hard and VTC if I had the karma: my question is not about a preferred work flow, and is about a specific bug in LO functionality which affects my needs around a set of documents which already exist, and your "answer" addresses neither.

( 2019-09-21 01:06:05 +0200 )edit

What is VTC?

There may effectivetly exist a bug in the Writer functionality, but there is also a bug in your usage. Writer is style-base, much more than M\$ Word. What you'd like to do is an easy task on the styles. Your request is indicative of direct formatting which always plays nasty tricks on your back. An example is the difficulty to achieve your goal.

By the way, what is the reason for tag bubble?

( 2019-09-21 07:49:41 +0200 )edit

"but there is also a bug in your usage. " No. There is not a bug in my usage. I have legacy documents for which your not-actually-an-answer does not resolve my issue. You answer is in effect an unwelcome and unfriendly response to my quite valid question. 'VTC' = "vote to close" (I am assuming that the stackexchange infrastructure underlying ask.libreoffice includes VTC as it does on the primary SE network, though that assumption may not hold). Also: no idea about the bubble tag... probably a typo. Have removed it.

( 2019-09-23 19:55:27 +0200 )edit

Do you attach a saddle on top of your car and pull it behind horses? No, you sit behind the steering wheel and drive it from the controls there. The same goes for software. Every application has its peculiarities. You must get the gist of it to pull the best. Otherwise, you're in the situation of riding your car on the roof.

All formatting in Writer should be managed with styles. Then what you what to do is easy through simple style modification. Unfortunately, I fear your legacy document is full of direct formatting (which is the "obvious" way of formatting -- I did that before I understood the value of styles) which can't be managed other than find & replace, yes. But F&R comes rather short on its possibilities of addressing formatting

If your document is a long-term maintained one, i'd recommend styling it to overcome the ...(more)

( 2019-09-23 20:16:38 +0200 )edit

( 2019-09-23 20:21:41 +0200 )edit

OK, I give up.

( 2019-09-23 20:38:03 +0200 )edit