Images will be moved to the next page, after clicking below it and press return
Steps to Reproduce:
- open an empty writer document
- insert a scanned din a4 img or a din a4 picture
- click below it and press return
Actual behaviour is, that the image is moved to the next page (together with the cursor), leaving the prior page empty
Former (and expected) behaviour was, that the image position did not change, instead the cursor moved to the next page
The old behaviour was fine, because you could insert one picture after the other into the document.
User Profile Reset: No
It's pretty nasty now, because after every inserting you have to care about, getting the image to the right page again ;-)
I can't say, which settings were responsible, that it worked all the time. I suppose, that inserting an image was done with anchor to paragraph than, while now it is anchor to character.
Of course it is just a point of view thing. If this behaviour IS wanted then *please* give me an instruction to change the default attribution of inserted images from anchor2char into anchor2para in some configuration file :-)
I asked in forum already, normal users (like me) can't find a solution to do it.
By the way, another forum user reported just the same problem.
Env: openSUSE 15.1
Could you please add an example file? I tried to import an a4.. but for me it shrinks to page dimensions.. hmm.. you probably removed the page dimensions..
Right click the image -> Anchor -> To paragraph (before pressing enter)
Created attachment 160707 [details]
Example file with an image thar puts the cursor below the picture, just hit return
I'm not in the office for correct dimensions of the image. So I created one, that shows exactly the behaviour. To describe it in other words: If image anchor was attached to paragraph, we would have the old behaviour, but since it is attached to character, it will move "with" the return to the next page
The default aching has changed..
Right click the image -> Anchor -> To paragraph (before pressing enter) will fix the issue.. however needs to be set for every image
Do you have any insight in technical difference between anchoring to character or to paragraph. Or more precise: how should an anchor to character without character present behave.. in this example. Is this the expected behaviour? It's not hard to work around, but if you have to change the anchoring for every image on by one
(In reply to Telesto from comment #4)
> Do you have any insight in technical difference between anchoring to
> character or to paragraph.
The mark-up of the image contains an attribute for the anchor type. In case of "to character" the markup-up of the image is directly after its anchor character, in case of no character there, at start of the paragraph. In case of "to paragraph" it is always at start of the paragraph. I don't know, how that is reflected in the code.
> Or more precise: how should an anchor to character without character present behave.. in this example.
I don't know. It is a decision of the user interface, not of the file format.
> Is this the expected behaviour?
It is how LibreOffice works, Enter at begin of paragraph shifts content down. And "to character" anchoring is interpreted that way.
Discussion about including anchor type in a style is in bug 36535.
Allow user to decide the default anchor type is in bug 99646.
And another related: bug 120469.
Gorgonz, what do you think after reading comments from Telesto and Regina. Can you narrow down the problem or the expected result?
@dieter: I'm not sure, which kind of answer you expect from "narrow down".
From my point of view the image is inserted in first place and the cursor and the paragraph sign are (and should be) below the image. And this happens even optically. So I would expect, that content AFTER the cursor is moved down, not content before the cursor.
And I also tried simple workarounds like CTRL-ENTER or SHIFT-ENTER, They did not help - for reasons.
On the other hand, I've seen those other bug reports, that caused the changed behaviour. And they have the same good reasons for there scenario as I have for mine. That's why I still think, best solution is to make it configurable for users and name it something like MS-compatible.
In fact, while importing a ms document, it makes sense to import images always as anchor2char, if this is the behaviour in the ms-world.
another aspect is the behaviour, if you insert more pictures without ENTER.
Now we have the situation, that they overlay each other instead of being below each other. This is irritating (my point of view)
[Automated Action] NeedInfo-To-Unconfirmed
Hello gorgonz, 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.
I gave it a try with my actual version (V18.104.22.168) and with flatpak (V22.214.171.124)
Maybe I'm not really aware of the different solutions, here my results:
In 7.1 there was already a fix, to solve the different needed behaviours with a new option (Writer=>Formatting help=>Image Anchoring). The behaviour worked fine for me setting it to "Anchor to paragraph". In addition, also "Anchoring as Character" worked in the same way, that pressing ENTER will not move the image one line down, but instead add a CR after the image.
In 7.3 this option still is there and works in the same way for "Anchor as character", but "Anchor to paragraph" has changed.
For my part I agree with both solutions, my important point was to get an option, that lets me decide, to have the CR after the image. In addition the new "Anchor as character" is very attractive, making it easy to change between the mode of adding many pictures next to each other or add a CR for a new line :-)
So, a big ThankYou to care about this problem in such a friendly way for both worlds of users :-)
Gorgonaz, could you please have a look at bug 146445? I think it discusses situation in LO 7.2 and newer.
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.
This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!