Description: Don't retain image position when cut/pasting exclusively the image Steps to Reproduce: 1. Open the attached file 2. Drag the image to at the height of ipsum lorem (so image being at the left of the text) 3. Undo everything 4. Cut the image 5. Place cursor before ipsum lorem 6. Paste Actual Results: Image retains positional settings after cut paste within LibreOffice Expected Results: Would argue that cut & paste of image only.. (so without text) doesn't 'retrain' the original position.. but being pasted blank.. Another aspect is of course where things should be pasted.. The current arrangement is centered at the position of the cursor.. Still inclined to mimic 'as character paste'.. which will be possible 'change the default' is working as expected (bug 139521) I personally expect the image at cursor position.. with Right Click paste or CTRL+V.. and not somewhere else. Where drag & drop and CUT+PASTE can be exchanged.. Dragging an dropping an image to a different page isn't possible.. yes it is in multipage view.. and surely not across documents. There is likely a group very attached to pasting middle of the page.. being around for a long time. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) Build ID: f2171af6ce3516598d9f8bac8294025a21a5b1a2 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Don't see a clear use case in your description. Here a common workflow: Document A with some structured text and images, and you want to copy the image and paste in another document. The expectation is that the image is placed as in the source including position, size, anchor, style etc. Cleaning the image format attributes on paste makes not much sense to me.
Created attachment 168903 [details] Example file Lets start with an example file
(In reply to Heiko Tietze from comment #1) > Don't see a clear use case in your description. Here a common workflow: > Document A with some structured text and images, and you want to copy the > image and paste in another document. The expectation is that the image is > placed as in the source including position, size, anchor, style etc. > Cleaning the image format attributes on paste makes not much sense to me. Hmm.. disagree. In advance.. There is no totally satisfying solution. I can't deny there likely cases where you're right. However the current behavior doesn't make much sense to me on global scale 1. It creates a difference in behavior between external image source from internal copy/paste (of image only) 2. Say I select the image.. and create a new document and paste it.. do I want/need it at the 'old' spot.. No. 3. It does also not make sense in documents.. when moving an image.. see example file.. But will I argument also extends to 'pasting' behavior to character' being similar 'as character'. So mimicking it.. Would align with MSO (but that's non-argument as such). But makes also sense you want to do that.. I also copy/paste & drag drop as 'same thing' except the one input being mouse.. the other keyboard.
Paste an image without its formatting attributes can already be archived by either Edit->Cut\Copy->Edit->Paste Special->Paste Special... or Right Click->Cut\Copy->Right Click->Paste Special->More Options Unfortunately, there isn't any option to keep the file type yet.
Seems Sascha agrees with my NAB.
(In reply to Heiko Tietze from comment #5) > Seems Sascha agrees with my NAB. Hmm.. kind of reluctant to 'accept'. The Sascha argument (comment 4?) is interest approach.. But obviously not present yet.. which would make that a different bug (or some pointer to existing bug) And maybe this is not about 'keeping position', but more how it's done... Word apparently retains the position 'absolute'. Independent of anchor position. Whereas LibreOffice images moves relative to anchor position. So cut pasting the image/anchor.. moves the image to so 'arbitrary' place on the document.
Created attachment 169249 [details] Example file
(In reply to Telesto from comment #6) > > And maybe this is not about 'keeping position', but more how it's done... > Word apparently retains the position 'absolute'. Independent of anchor > position. Whereas LibreOffice images moves relative to anchor position. So > cut pasting the image/anchor.. moves the image to so 'arbitrary' place on > the document. This depends on the anchor type: It will be relative when the anchor is set to paragraph, to character or as character. But absolute with an anchor set to the page. I understand your report not as a bug report but as a feature request of a new past special option for objects similar to past special>unformatted text?
(In reply to S.Zosgornik from comment #8) > (In reply to Telesto from comment #6) > > > > And maybe this is not about 'keeping position', but more how it's done... > > Word apparently retains the position 'absolute'. Independent of anchor > > position. Whereas LibreOffice images moves relative to anchor position. So > > cut pasting the image/anchor.. moves the image to so 'arbitrary' place on > > the document. > > This depends on the anchor type: It will be relative when the anchor is set > to paragraph, to character or as character. But absolute with an anchor set > to the page. > > I understand your report not as a bug report but as a feature request of a > new past special option for objects similar to past special>unformatted text? Not directly what I had in mind.. but would be the alternative, yes. Sometimes you simply want to paste the image from document to document.. and the original position simply irrelevant. I'm on talking about the case where the image selected.. Not the case where you select the anchor (to paragraph/to character) with the text.. in that case nothing wrong with retaining the original position
Hello Telesto, a new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
In a cut/paste operation of an image within LibreOffice you don't really/cut paste the image (shape or whatever), but you cut/paste the anchor somewhere else (and the image following the anchor). Whereas I assume the image getting positioned at the area of the paste (which happens if you copy/paste an image from external to LibO) Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ca657b98e49eb2282775f7919827062a7a0b4bfe CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Behaviour, that anchor also moves, if you drag image might be wrong, seehttps://help.libreoffice.org/7.3/en-GB/text/swriter/guide/anchor_object.html?&DbPAR=WRITER&System=WIN and bug 135570 comment 16. So this behaviour shoud not be part of the discussion here. Regarding cutting the image i wouldn't treat it as a bug, because there might be users, who expect the opposit. So I would treat this as enhancement request. Hope you can agree about it, telesto. Heiko, can Design-Team decide about this or how is it possible to come to a decision?
(In reply to Dieter from comment #12) > Behaviour, that anchor also moves, if you drag image might be wrong, > seehttps://help.libreoffice.org/7.3/en-GB/text/swriter/guide/anchor_object. > html?&DbPAR=WRITER&System=WIN and bug 135570 comment 16. > > So this behaviour shoud not be part of the discussion here. Well the description at 'To Character' reads as actually being about 'To Paragraph'. I don't think the documentation/help being really good frame of reference. One of the major problems is the lack of clear specifications what it being desired, from user perspective and technical perspective. Where the technical aspect very important, as images (and anchors) have lots of influence on layout bugs. > Regarding cutting the image i wouldn't treat it as a bug, because there > might be users, who expect the opposit. A core problem is the way I presented the issue. And this is not 'bug' with clear cut current bad, old good. But questioning about the design specifications. (A) It still not clear what the conceptual design considerations (specifications) where at the time of introducing 'To character' anchoring (but that's likely something from the StarOffice day's; My impression is that 'To Character' anchoring being developed as proof of concept design spun out of 'To Paragraph' anchoring (back the day). It stuck at that point ever since. So instead of pre-descripted specifications it started with trying what being possible. A valid approach, but try-out never got to defining how it should be within parameters of possibility's. The position of the image on paste was less of an topic when everything anchored 'To paragraph' (result might be bit 'off', but acceptable), for 'To Character' it becomes kind of arbitrary Author losing interest, other priority's.. whatever.. the development has taken some twist and turns of the years. (B) To Character got promoted to prime time usage in 6.4 (?) because of compatibility reasons, but not across the board, certain object still inserted "To Paragraph". Creating again odd blend of insertion to character/to paragraph. Without a clear goal/vision or any time frame where something gets harmonized. It was pretty much a solo action of developer, trying to solve a problem ad hoc. The free for all approach isn't always that ideal, IMHO. Central coordination does have certain advantages once in a while