You can re-add this back to the context menu thru Tools/customize (tho apparently not easily as a submenu item):
In Tools/customize, Change “Category” to Format and change “Target” to Image.
You can then add the “Anchor to Page” to your context menu (tho not submenu for some odd reason).
Drag and Drop it into position.
You can then select right mouse Context menu to see it, tho it won’t be in the exact location it used to be in… it will be where you placed it using the tools/customize.
There is “nothing” so advanced about this feature that anyone with typical usage skills cannot easily rectify using undo, or simply re-applying anchors that behave differently.
Yes, it is a problem because you moved something that used to be present to a location where it is not known or obvious.
Instead of making it easier, you made it more difficult.
If you want to use the logic that it is an advanced feature, then add a submenu under “Anchor as”
called “Advanced Anchors”, that has it there. The whole point of the context menu is ease of access.
Lol. You obviously didn’t even try to understand the problem. There is no chance to fix it using undo (how could you even imagine that nonsense). They even don’t realize that the problem is anchoring - so for a user without deep understanding, there is no obvious way to rectify that.
If undo didn’t work to fix when Anchor to Page is misapplied then that would be a bug that needs to be fixed.
However, it works fine in my testing.
There are hundreds if not thousands of “features” that Libreoffice has that would be considered advanced which would render many features hidden or multiple steps further away in ease of use. Most devs solve this by simply having a menu item that says “Show Advanced Features”… and let the user decide. That way, you can get the best of both worlds.
Sigh. Undo would indeed change the anchoring applied by your actions. But the problem will never appear immediately after changing the anchor type.
I don’t think you understand the issue at all. I don’t even think that you understand the feature, so I very much assume that you may very well be someone who misuses the feature (well, maybe not… but since you do not understand the problem that was fixed by the removal, you may be). I would suggest you to re-consider why you need that anchoring in the first place.
And no, we do not expose most of those thousands of features in context menus. This is now one of them.
My use case is very simple: I am making a document of images of an Unreal Engine content plugin for Groom (hair). I don’t need for the images to “move” with the text, since I am just applying a basic heading for each of the Assets (each of which has multiple images to document).
The problem with Anchor to Paragraph is that the behavior is not consistent when the images are of different sizes and they are laid out horizontally, as they keep “moving” out of position relative to where you expect them to stay.
I came here looking for a simple solution because “Anchor to Page” was one solution.
The context menu option is the easiest, but it was missing.
I solved the problem by adding it back to the context menu. (This converted the amount of time it took to anchor the images to 1/3 the time, because now the number of clicks needed to get there is much lower)
My hope is to convince you that just because your users don’t understand how to use something, doesn’t necessarily mean you should move or deprecate a feature.
As I said before, if you really want to protect users from themselves, you can have an “Turn on Advanced Features” option (preferably located in “options” heheh…
We don’t deprecate it. But we definitely moved it out of the too prominent place.
You have resolved your problem. So it is solvable in the intended way, which is “a user who needs it can put it to the menu”. I don’t see why should we do anything else.
Wrong. There is no single “Turn on Advanced Features” option fitting everyone’s needs. For one user, it should enable features A, B and C; for another, B, D and Z…
Meaning that you likely don’t define the objects’ positioning properly.
Hahah, well I am not suggesting we take all the advanced features and stuff them in context menus. But, what I am suggesting is that we should not move every misunderstood feature from its normal location and hide it (move it) so that it is more difficult to find. So, my suggestion is that if the big concern from the devs here is that users are finding some features too advanced to use without a great deal of understanding, then you should keep them in the usual place but as “Advanced Features”, and just “unhide” them when the user turns on advanced features.
Yes exactly… and that is why “Moving” the features is the wrong way to fix your problem… because there is no single option for everyone’s needs. So, it is a mistake to hide commonly used features simply because some people find them too advanced.
If you must move them, because they are “too advanced”, then clearly they can be put in an “advanced features” category, but if there is no such category, then moving features for that same reason just hides them from experienced users.
There is an existing feature to put any command to a menu or toolbar, no matter how advanced it is.
There is an established practice of not putting too advanced / “dangerous” commands to context menus.
One too advanced, and often “dangerous”, command was removed from a context menu.
Problem solved. No change required. End of story.
Yes, and why this was not mentioned to the OP at the very beginning ? sigh.
Because they didn’t ask how to put it there (only that it’s not there). The OP was informed that the feature is still there in the dialog, very early. And before advising how to make it too prominent again, we’d better make sure that OP is not a person for whose benefit it was hidden in the first place.
Understood. Alright. Well thank you for your efforts.
I deduce from this statement you don’t use frame styles and prefer to position your images with the mouse, creating an extremely nasty direct formatting DF (DF on frames has really devastating effects). Frame styles have provision for (limited) automatic conflict resolution, no matter the image size. It works horizontally, which is your use case.
I admit that frame styles are a difficult matter. I don’t know if they qualify for “advanced feature” but they fit neatly in the style philosophy of Writer. Indeed, they require a lot of practice to understand the concept and deal with the limitations of the implementation. In the end they bring a lot of comfort and speed to your layout which automation becomes predictable and, most important, reliable (frames no longer jump unexpectedly).
Time spent to learn the concept and experiment is not wasted time. It boosts your efficiency later.
Look at the dates: The first question was answered the same day by Mike, and the perso starting the thread never asked again…
.
2 years later (2023) the first discussion came, another this year (2025) in august. So your continuation after another 3 month seems just a bit early…
Thanks. Yes, I have avoided frames. But, I might consider adding them in the future.
Images are a frame by themselves. If you need no caption or other attached data to an image (in other words, data which moves with the image), don’t add an extra frame. Frames cannot be related or constrained between each other. Adding a spurious frame would make things even more complicated.
What you have to do is to design a specific frame style. It must be conceived in a generic (or abstract) way, independent from size, so that it can be applied to many different images. This is the hard point.
The second difficulty (THE nightmare!) is the already present (frame) direct formatting on your images. Ctl+M is ineffective in this case because it addresses only typographical attributes. The only workaround I found was to apply a nonsensical style like built-in Formula then to apply the intended style. Also, frequently, you don’t see immediately the changes; then Tools>Update>Update All will cause reflow.
Thanks a lot, I managed to get it in, after some trial and error :-). Wonderful!