Description: It would be very helpful if an option were provided to replace all graphics with a graphic copied in the clipboard. I'm looking forward to this. Actual Results: - Expected Results: - Reproducible: Always User Profile Reset: No Additional Info: - User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Sorry, but this is more the job for a macro or an extension. You can try recording a macro of replacing an image, inspect the code and try to make it a loop that replaces all the images in the document. Closing as WONTFIX.
But this is possible in MS Word (see: https://wordribbon.tips.net/T013276_Searching_and_Replacing_Graphics). How does LibreOffice want to compete with MS Office if it doesn't provide such basic features?
Fine, let's ask UX about our competing ambitions.
For OP, for clarification you are asking for capability to use a single graphic (held on clipboard)--but I would assume by selection as well--to replace all graphics/frames on document canvas? And, you'd like interface via the "Find & Replace" dialog. Seems feasible. But the existing Find can not target an image directly at the moment. Something is already in works for LibreOffice with bug 100672 to add a Special category, that could be extended to include "graphic" objects--icons, bitmaps, vector images, etc.. Otherwise this has been fertile ground for Extension with the like of "Alt Search" and "Change Picture" both able to target an image for replacement. But the search logic for the graphics would have to be figured out for consistent use in the core Find & Replace dialog.
I have been working on batch replacing graphics with AltSearch, but the results were poor as not all graphics were replaced and the first one was misplaced and its frame and caption removed. I got in touch with the developer of Alt Search about this. As for "Change picture", this extension is able to change only one picture at a time, the one that you have selected.
I'm missing the use case here. Of course it's _possible_, but when you want to exchange one company logo by another, for instance, that's a job for the template/field etc. Different images in a document likely hold different content. So a clear WONTFIX from my side as Buovjaga said in comment 1.
(In reply to Heiko Tietze from comment #6) The use case that urged me to find a solution to this is the need to anonymize thousands of pages of content. It's relatively easy to anonymize words and numbers with the help of regular expressions, but I couldn't find a way to batch replace all images.
(In reply to Darius Daniel Grigoras from comment #7) > The use case that urged me to find a solution to this is the need to > anonymize thousands of pages of content. In that case the image should retain its dimensions. Definitely an extension task. Do you feel comfortable with Basic/Python/Java/Rust...?
(In reply to Heiko Tietze from comment #8) > (In reply to Darius Daniel Grigoras from comment #7) > > The use case that urged me to find a solution to this is the need to > > anonymize thousands of pages of content. > > In that case the image should retain its dimensions. Definitely an extension > task. Do you feel comfortable with Basic/Python/Java/Rust...? No, I would agree this is a reasonable capability to include for work needed implementing a _Special_ panel function for Find and Replace. The missing piece now is _exposing_ a graphic object to the Find and Replace actions. MS Office provides matching for a graphic object with the "^g" wildcard on both the Find and the Replace tabs. During implementation for LibreOffice, specifics of the capability might need to consider scaling/clipping to fit the replacement into the document (to retain formatting) or just replace.
(In reply to V Stuart Foote from comment #9) > No, I would agree this is a reasonable capability to include for work needed > implementing a _Special_ panel function for Find and Replace. > > The missing piece now is _exposing_ a graphic object.... I don't get how we work. Do we wait for a commenter who agrees with an idea and implement all requests in the end? Usability is not to make one particular workflow comfortable.
(In reply to Heiko Tietze from comment #10) > (In reply to V Stuart Foote from comment #9) > > No, I would agree this is a reasonable capability to include for work needed > > implementing a _Special_ panel function for Find and Replace. > > > > The missing piece now is _exposing_ a graphic object.... > > I don't get how we work. Do we wait for a commenter who agrees with an idea > and implement all requests in the end? Usability is not to make one > particular workflow comfortable. Not at all, it is an enhancement and for such the threshold is appropriately low. Describing what is a reasonable enhancement for implementation in core framework is simply stating an opportunity for developer effort--whether it is picked up or not will depend on its appeal to a developer, and some assessment of its value to the project. For issues we are able to develop ourselves we do so. For other more challenging capabilities or refactorings we flesh out a recommendation, and then answer questions developer(s) may have in implementation. For controversial changes to GUI or work flow that impact the UX we ask the ESC to adjudicate the requirements and development process. In this case existing extension(s) are not very complete, and it is not clear the SDK provides scripting hooks to support the needed capability. So I think implementation in the core Find & Replace would be of interest to a potential developer, and that it is certainly an enhancement of value to users needing tools to edit their documents.
(In reply to Daniel Grigoras from comment #7) > The use case that urged me to find a solution to this is the need to > anonymize thousands of pages of content. We introduced the redaction feature that might do the trick together with a macro. Or shall we add a feature, Muhammet?
(In reply to Heiko Tietze from comment #12) > (In reply to Daniel Grigoras from comment #7) > > The use case that urged me to find a solution to this is the need to > > anonymize thousands of pages of content. > > We introduced the redaction feature that might do the trick together with a > macro. Or shall we add a feature, Muhammet? Redaction feature doesn't handle graphics currently, but yes it can be exploited to also redact graphics by using a macro. If the content to be redacted has only graphics, a macro can do it with or without the redaction feature. If the content also has text elements, then a macro + redaction feature would be a nice combo. That way, you can keep the original content, and share the redacted/anonymized content only. (Technical tip for a macro writer: go through all shapes/images, and place a rectangle on top of them with the exact same size & position, and name each rectangle as "RectangleRedactionShape", and leave the rest to the redaction feature)
(In reply to Muhammet Kara from comment #13) > (In reply to Heiko Tietze from comment #12) > > (In reply to Daniel Grigoras from comment #7) > > > The use case that urged me to find a solution to this is the need to > > > anonymize thousands of pages of content. > > > > We introduced the redaction feature that might do the trick together with a > > macro. Or shall we add a feature, Muhammet? > > Redaction feature doesn't handle graphics currently, but yes it can be > exploited to also redact graphics by using a macro. > > If the content to be redacted has only graphics, a macro can do it with or > without the redaction feature. If the content also has text elements, then a > macro + redaction feature would be a nice combo. > > That way, you can keep the original content, and share the > redacted/anonymized content only. > > (Technical tip for a macro writer: go through all shapes/images, and place a > rectangle on top of them with the exact same size & position, and name each > rectangle as "RectangleRedactionShape", and leave the rest to the redaction > feature) OTOH, I wouldn't call it an invalid request to add an "Images" option to the Predefined targets of the Auto-Redact Dialog.
So WF for the internal solution but +1 for an extension.