Description: 1. I open a new document. 2. I paste a picture into this document. 3. I try to make a new line to get an distance to the picture - I just wated an empty line under it and wanted to go on writing there. 4. every time I hit the <return> button, the picture goes a line down and instead of creating empty lines UNDER the picture this creates empty lines ABOVE the picture. I knwo, how to get what I really want: I type first an empty line into the new document, then go up and paste the picture - but anyway this seems to me an error, since what I did first is natural thinking - no one assumes, that if putting a picture first into a new document, that this picture will stay there as the last line of the document. Steps to Reproduce: 1.open new document 2.paste a picture 3.try to put a new line under this picture. Actual Results: see above Expected Results: see the text Reproducible: Always User Profile Reset: No Additional Info: I just installed the Version 7.0.2.2 x64 8349ace3c3162073abd90d81fd06dcfb6b36b994 but this version is not listed in the selection list above.
Can you confirm which program are you refering to? On Writer, when I paste an image, I enter in the placing mode (as indicated by the anchor icon) where I can move the image around. Only after clicking inside the writing area I can write. Version: 7.1.0.0.alpha0+ Build ID: 7aaa9ef2e5edaf468f116449776433e98fb1a2f3 CPU threads: 8; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-10-09_22:58:32 Calc: threaded
Created attachment 166273 [details] anchor icon when pasting image
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Hi I agree 100% with Schwarz-And@t-online.de. This behavior is absolutely annoying and it is in LO 7++ but not in older versions. I'm not sure when Libreoffice's default behavior was changed. The reaseon is: When you import a picture via "ctrl + v" it will have the standard anchor type "To character" (Am Zeichen). but in earlier versions ist was "To paragraph" (Am Absatz). At least in LO 5.2, it was "To paragraph". When "To paragraph" is selected, you can type characters after the picture and it stays as expected. please fix this annoying misbehavior so that I can use libreoffice with pleasure again! Thanks Ralf
Hi again It may be related to the following changes: LO 6.4: Selection of drawing objects anchored at-paragraph works more consistently and user-friendly now core commit 91b2325808a75174f284c48c8b8afc118fad74e4(Michael Stahl, CIB) OR LO 6.3: Selection of drawing objects anchored at-character works more consistently and user-friendly now, and doesn't crash in Undo (Michael Stahl, CIB) core commit 28b77c89dfcafae82cf2a6d85731b643ff9290e5
There a two topic here. They default anchor has changed with 6.4 I think. From to paragraph to to character. Changing default anchor back and it works as expect They behaviour of to paragraph and to character are be different which should be they case, I think. From technical perspective the behaviour of to character being proper. There is no paragraph above, which to paragraph currently suggests. But I do see they annoyance. Adding M. Stahl because it's his area of expertise
probably this? commit a7528cd6f17ea5c5b29e7d607e54c62de0d9e7db Author: Miklos Vajna <vmiklos@collabora.com> AuthorDate: Mon Nov 18 13:50:32 2019 +0100 Commit: Miklos Vajna <vmiklos@collabora.com> CommitDate: Mon Nov 18 17:37:13 2019 +0100 sw: insert image: set anchor to at-char by default This changes the default set in commit 4f40bf6a79de6d60da0a5090cdfeda6242e889f0 (sw: insert image: set anchor to as-char by default, 2019-07-04), to have a better compromise, taking both Word defaults compatibility and usability into account. The problem is that users are used to just inserting an image and being able to drag it to its final location, which is broken with as-char anchoring. So default to at-char anchoring, this is still something that is fully interoperable to Word (unlike the old to-para anchoring), but allows the easier image move again. Change-Id: Ibc61ae167fc9e5cc31b04c83e854556309e27fd4 Reviewed-on: https://gerrit.libreoffice.org/83089 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
Yes, that's the commit changing they default anchor.. To other part is about if 'to paragraph' and 'to character' should behave the same way. With 'to character' and the image reaching page borders, a paragraph is added below the image and image is being anchored to it. With "to paragraph" the anchor stays on top (not really anchored to any paragraph). Which delivers the most intuitive workflow. OTOH, seems technically off. Difference is there already a long long time, also in Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL
Hi For me the default should be set back to "To paragraph". But the requirements may be different. A solution could be, that i can set the default behavior in the Settings/Options?
(In reply to ralf.krapf from comment #9) > Hi > > For me the default should be set back to "To paragraph". But the > requirements may be different. > A solution could be, that i can set the default behavior in the > Settings/Options? About default anchoring, see also: bug 32484 and bug 99646 There is a problem here anyhow :-). So changing default wouldn't solve the case here.. Only mask it. Even though I think 'to paragraph' maybe better choice.. But that's hindsight. They matter has been decided for now.. and waiting for the 'final' solution
Created attachment 167113 [details] Example file Another example. Press Enter below the image.. and they image goes down
Hi As far as i see, in LO 7.1.0.3 (Win10 64bit) the behavior is ok. The only thing i had to do was change the standart input behavior for pictures from "Optimal" to "Kein". Sorry, i have only the german version. It was under: F11- Formatvorlagen - Rahmenvorlage - Bilder - Umlauf - Einstellungen - Kein. See the attaced picture. Cheers and Thanks Ralf
Created attachment 170019 [details] Insert picture
As far as i see the bug is still present in LO 7.3.3.2: If you insert a picture with default settings in LO 7.3.3.2, the picture goes down when you write text at the bottom of the picture. The behavior as i described above is only a work-around. Is there anything movement in this case? Thanks.
(In reply to ralf.krapf from comment #14) > The behavior as i described above is only a work-around. > Is there anything movement in this case? I believe this entire ticket is NAB, but now I will ask for UXEval, in order to get some movement. The main issue here is for the special case of pasting an image into an empty document, where the enhancement requests seem to be aimed at "natural" behavior after pasting the image. The UXEval issue is to decide what "natural" behavior should be considered "default" (given that some users may prefer the current behavior as "natural"). Taking the OP first (copy an image into a new document, not able to add text after image), where CR moves the image down. The OP is prior to bug 120469, but the reported behavior looks consistent with the change introduced in bug 120469). OP reports one "workaround" (which is viewed as "unnatural"). Comment 12 and comment 14 report another "workaround" (change Wrap from "Optimal" to "None") (which is implied to be an unacceptable extra step). I can add another response, not mentioned here, change anchoring of image to "as character". The attachment in Comment 11 also gives a different interesting case to consider. imo changing wrap or changing anchoring can be understood as "knowing how to use the software", and I would expect that if changes were made to satisfy this ticket, then a new ticket would appear about not being able to put an empty paragraph before an image. => need to take a bold decision about what should be "dominant" or "default" or "natural" behavior in this case => needsUXEval (no opinion from me, in that "natural" here is a matter of taste, and regardless of defaults, one should learn how to use the software in relation to images.)
This inconvenience was resolved for bug 99646 by introducing an option, which should be available from version 7.1 on.