Bug 138169 - EDITING: Copying an image with a name should also copy the name
Summary: EDITING: Copying an image with a name should also copy the name
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Images
  Show dependency treegraph
 
Reported: 2020-11-12 20:03 UTC by Thomas Lendo
Modified: 2023-01-10 02:30 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Lendo 2020-11-12 20:03:13 UTC
Inserted images shows in the image properties dialog > Options > Name field "Image1", "Image2" and so on.

If the user changes this name field text and then copies the image, the name will not be copied as well and the default name "Image1" is assigned to it.

When copying the image, it's sometimes useful to NOT lost this name field text. It's the same image--why not the same name?

My use case for example is: I write instructions with many safety signs that are reused in different places in the same document. The safety sign always is the same, only descriptive text is changing (e.g. "Warning: Electricity hazard during maintenance" and "Warning: Electricity hazard during installation"). After copying such an image, I've to go back to the image, copying the name and inserting and changing it in the new image.

As nothing can have the same name, the copied image name musts be enhanced with a suffix or prefix like " - Copy1".
Comment 1 Dieter 2020-11-27 07:52:12 UTC
I confirm the described behaviour with

Version: 7.1.0.0.alpha1+ (x64)
Build ID: 10b23330a9655658e6d7ef1d008a3302a15e9629
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: threaded
Comment 2 Dieter 2022-11-22 15:31:25 UTC
Still present in

Version: 7.4.3.1 (x64) / LibreOffice Community
Build ID: 3793858a34d8fef5b92f8fee233f97766f05e281
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL
Comment 3 Dieter 2022-11-22 15:35:11 UTC
Additional informations:
Cutting and pasting works.
Comment 4 Stéphane Guillou (stragu) 2023-01-05 16:16:44 UTC
Tested with:

Version: 7.5.0.1 (X86_64) / LibreOffice Community
Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Cut-and-paste keeps the name.

Copy-and-paste appends a " Copy 1" to the existing name. (And increments the number on subsequent copies.)

Can't find the fixing commit or corresponding bug just yet so marking as "works for me".

(issue was already present in OOo 3.3)
Comment 5 Dieter 2023-01-07 16:39:34 UTC
(In reply to Stéphane Guillou (stragu) from comment #4)
> Can't find the fixing commit or corresponding bug just yet so marking as
> "works for me".

What about the correspondig bug 151828?
Comment 6 Stéphane Guillou (stragu) 2023-01-09 06:03:13 UTC
(In reply to Dieter from comment #5)
> What about the correspondig bug 151828?

I think that fix only affected the cut-and-paste behaviour, not the copy-and-paste name increment, but Jim can confirm.
Comment 7 Jim Raykowski 2023-01-10 02:30:39 UTC
I didn't know about this bug report.

Here is the link to the fix patch:
https://gerrit.libreoffice.org/c/core/+/142983