The credits go to me: was more or less based on my experience and 
https://bugs.documentfoundation.org/show_bug.cgi?id=135836#c5

Roman could please add a or multiple uses cases where 'To page' useful? 

And obviously the annoying argument you can modify the Context Menu/ toolbar if you really need it.

There lots of pro and contra's here.

For more than 20 years millions of users saw no need to request the change made in bug 135836. After all that time you pushed for something only you wanted.

I work with a lot of documents with inserted images and removing this anchoring option creates more work and inconvenience for me.

(In reply to Dave Barton from comment #2)
> For more than 20 years millions of users...

The request was based on the fact that anchoring to page is discouraged thus hiding to option from the UI makes sense. You can easily customize it back into toolbars and context menus. My take on this ticket => NAB/WF

(In reply to Heiko Tietze from comment #3)
> (In reply to Dave Barton from comment #2)
> > For more than 20 years millions of users...
> 
> The request was based on the fact that anchoring to page is discouraged thus
> hiding to option from the UI makes sense. You can easily customize it back
> into toolbars and context menus. My take on this ticket => NAB/WF

About that, I have some trouble how to edit the anchor context menu. Which is obviously requirement.. I expected it would be, but I can't find it (or looking at the wrong place)

(In reply to Telesto from comment #4)
> About that, I have some trouble how to edit the anchor context menu...

True, you cannot change the Anchor group. But you can add the "Anchor To Page" command into the Image context menu after this "Anchor >" submenu, for example.

*** Bug 141091 has been marked as a duplicate of this bug. ***

7.1 isn't an old version and nobody reverted bisected patch, so the problem still here

Anchor still can be changed to page from the properties dialog. It was removed from the context menu on purposed as discussed in bug 135836. My take: WONTFIX

(In reply to Xisco Faulí from comment #9)
> Anchor still can be changed to page from the properties dialog. It was
> removed from the context menu on purposed as discussed in bug 135836. My
> take: WONTFIX

Comparize number of action for anchor changing when you use the widget and when you use the dialog. And then multiple it to number of images in a document.

I still want revert the patch

1. The last time I checked "To Page" was still present IN HELP. If option was removed or hidden it should be noted in HELP that it moved to an another place.

2. I was using it every time I needed to anchor large, 90% page sized image to a page and never ever let it move when text flows around it.

Without it reverting to old school HTML solution: "put it in a table" is necessary and it is a rather bad solution. In generic there was always a pain when You had to place many LARGE images on page all anchored to same paragraph. Adding hard page break without "to page" was only sometimes helpful. 

I must admit however that it was in a past and I'm doing that this way now because it was proven to always work. Maybe other anchors do work good now, I don't know. Yet just few hours ago I still have seen images anchored to same paragraph getting one over another at any text edit, so I don't think it is a case.

3. (see 135836) No sane person expects that cross format conversion is done perfectly. It never is and never will be. This is why people do use different formats: because they do things better in some specific cases. 

The statement  that Word can't do it can be also turned into a statement: "Discourage fonts because Notepad can't do it". LibreOffice was far BETTER than Word for many years. It should not try to step back. Blah... it should NOT even try to follow anything what Word does. In my personal experience many changes made in Word are counter-productive. Don't follow them.

4. Nobody I asked could find where this option is now (in some tabs in some dialogs accessible from some context menu, ten clicks away). The user interface is now inconsistent. If there is an "Anchor" menu it should be consistent in terms of functionality across the entire application. Otherwise we have to think... hmmm... is that Anchor sub-menu in context menu the same Anchor as in toolbar? Maybe... maybe not. Or maybe we can try some other dialogs and options to check if there is an another menu with exactly the same name but different content? 

Geezzz... Try teaching somebody to use it.

5. Removing options which were there for Years is always a bad choice. Yes, I know it was not removed. It was hidden in such a way so that You could not find it. 

6. If we can agree that  the rationale that "To page" was incorrectly specified or that the Word can't do it is right, then a proper way of fixing it is:

   a) make a clean specification and put in in HELP;

   b) make a motion for a DOCX to start supporting it.

Best regards,
  Tomasz Sztejka.

(In reply to Tomasz Sztejka from comment #11)

I am not a fan of the removal (although possibly I'm the one to blame for inspiration for the removal); yet, I do still believe that by far most of real-life uses of To Page anchoring are misguided. Users do not realize what it does, and how could *what they really need* be achieved [1]. They confuse this *rarely needed* option for something different, and then have problems (there are lots of questions e.g. on Ask related to that).

Also our anchoring and positioning has many shortcomings (tdf#141160, tdf#141161, tdf#141162 could possibly make people lives easier, and make the urge to use To Page anchoring less).

So this option is actually a power-user option... with a potential to confuse most of not-so-power users (the majority). So despite, as said, I am not a fan of the change implemented in tdf#135836, I see it in fact as a big opportunity for people to educate themselves on the proper way of doing things...

(I agree that if it is done, it should be documented, and possibly advertised with some explanation of the proper way of doing what created most confusion.)

> No sane person expects that cross format conversion is done perfectly

Heh, I rarely see statements that have so little in common with reality ;-P The truth is the opposite (or alternatively, 99% users are insane - but I suppose they are just not too tech-savvy).

[1] https://wiki.documentfoundation.org/Faq/Writer/AnchoringAndPositioning

*** Bug 141686 has been marked as a duplicate of this bug. ***

https://ask.libreoffice.org/en/question/201131/anchor-to-page/
https://ask.libreoffice.org/en/question/65057/photos-and-anchor-to-page/
https://ask.libreoffice.org/en/question/298444/how-do-i-anchor-text-to-a-page-in-a-document/
https://ask.libreoffice.org/en/question/198458/insert-page-and-move-images/
https://ask.libreoffice.org/en/question/86692/cant-anchor-image-in-header/
https://ask.libreoffice.org/en/question/174730/writer-anchor-images-to-centre-of-their-respective-cells-within-table/
https://ask.libreoffice.org/en/question/302665/how-to-insert-a-new-empty-page-without-a-page-break/
https://ask.libreoffice.org/en/question/290561/additional-page-with-heading/
https://ask.libreoffice.org/en/question/257728/text-frames-from-subdocument-doesnt-appear-in-master-document-solved/
https://ask.libreoffice.org/en/question/252226/cant-synchronize-logo-in-labels/
https://ask.libreoffice.org/en/question/225549/cant-get-rid-of-blank-pages-from-image-sub-documents-in-master-doc/
https://ask.libreoffice.org/en/question/246617/writer-how-to-insert-frames-from-subdocuments-into-a-master-document/

Those are the questions where users misused (misunderstood) the "to page" anchoring, and had problems because of that. That is *quite common* problem, and I now think that it was good move to remove the "to page" from the prominent places.

What is missing is documenting this in release notes (with a link to FAQ), and fix the help that refers to the removed UI parts.

To comment #14

Maybe it is a problem because it never worked as it should work?

It seems, from links You have posted and my experience with users at work, that most people expect that:

1.Object anchored to paragraph moves with paragraphs keeping a specified offset from beginning of it. 

This works roughly as expected. They tap enter and image moves.

Except it is getting messy if You try to anchor image to a certain paragraph which is NOT right above an image. Any attempt to move anchor moves an image and any attempt to move image moves an anchor. Trying to arrange two or more images aside of each other is a real pain. This is covered by what You kindly pointed out (tdf#141161, tdf#141162) so nothing more needs to be said.

2.Object anchored to character moves together with a character.

This doesn't work at all as expected. Image does not keep offset from a character as character moves. Behaves exactly as "to paragraph". And by looking at Image->Properties->Type->Position it does what it is told to do. Be like "to paragraph" with the only difference is where the anchor icon is shown. I can't follow the idea behind it. 

I think that restriction of the set of possible selections in Position based on anchor mode is done incorrectly and chaotic and unnecessarily removes some possibilities. For an example if I do select ->To page and then ->To character then a possible selection set is different if I do ->As character and then ->To character. 

3.Object anchored as a character is just a custom letter. 

This works always in a consistent way. Great option for my job, where I need to often use custom graphics to say: "press that key" in manuals I write.

4.Object anchored to page stays in it's relative position to page corner.

This is in fact a bit problematic because it is hard to guess to "which page corner". This, as far as I remember from an old OpenOffice, used to work fine with manual page breaks, but now it seems to ignore it what is confusing. 




In my opinion maybe the LibreOffice team rather than focusing on encouraging or dis-encouraging use of certain options because we, users do not understand it, should focus on making it right?

The obvious question is "what is right?"

The primary source we, users may look at is the HELP. So what is in there?

https://help.libreoffice.org/7.0/en-US/text/shared/01/05260100.html?&DbPAR=WRITER&System=UNIX

and almost the same, but in more vague way is repeated at:

https://help.libreoffice.org/7.0/en-US/text/swriter/01/05060100.html?System=UNIX&DbPAR=WRITER&HID=modules/swriter/ui/frmtypepage/width#bm_id3150761

(I do use 7.0 version, but a quick check on https://help.libreoffice.org/latest/ shows no difference)

1.To paragraph:
"Anchors the selected item to the current paragraph.
The anchor icon is displayed at the left page margin at the beginning of the paragraph."

No single word is said if it moves with text or not. Nothing. Null. Zero.

2.To character:
"Anchors the selected item to a character. This command is only available for graphic objects"

followed by enigmatic:

"To align a graphic relative to the character that it is anchored to, right-click the graphic, and then choose Properties. Click the Type tab, and in the Position area, select Character in the to boxes."

No single word again how it moves when character moves. The enigmatic hint however may enlighten some of us how we can achieve what we like. That is that the "anchor" is just the "anchor icon" while the actual flow in text is controlled by Image->Properties->Type where all possible tricks may be set. 

3.As character:
"Anchors the selected item as a character in the current text. If the height of the selected item is greater than the current font size, the height of the line containing the item is increased."

Again, no single word how the image should move if text is edited.

4.To page:
"Anchors the selected item to the current page.
The anchored item remains on the current page even if you insert or delete text."

This option is, surprisingly most clearly explained. The image stays on page if you add or delete TEXT. There is no single word about how it should behave if You add or remove a MANUAL PAGE BREAK. In my opinion it should move then.




Sorry, guys, but I'm totally not surprised that people understand it incorrectly because.... there is no much to understand. 




How I look at is the problem is NOT in users not understanding how do things work, but in users NOT HAVING A WAY to find how it was meant to work.

Cleaning up and clarifying help is an important step which needs to be done. Users can understand only that what is presented to them. LibreOffice is quite well documented, in fact much better than many commercial software, but still lacks tooltips in far too many places. As far as I can observe a good tooltip is often a key to success. A context sensitive hinting system (check the status line in Inkscape for an example) is also a great way to direct users to some less obvious options. Help is usually a last resort for users, but if help fails to explain what is what then what a poor lad can do?

On the other hand I think that maybe a slightly better selection of what is set in Image->Properties->Type->Position when anchor changes may straighten most of confusions. Surprisingly a functional "To Page" asked by users You quote is in fact "To Paragraph" with "Position" in Image->Properties->Type set "to entire page". It stays at position relative to page, but if page is inserted either due to large text edit or page break insertion it moves as expected.




And, by the way @comment #12, yes, good point, You are right. Most silly people are expecting that conversion is done well, and because most of them are silly... well... on the other hand I'm frequently considered to be a bit off the side with the sanity too. ;)

But they do think that only for the first time.

They do quickly learn that it doesn't work with anything more complex than a short letter. Microsoft Office is especially annoying in this manner because it tends to hijack odt/ods on each update and many of my coworkers don't notice they did open odt with Word. I can hear the swearing and cursing an hour later when they found out that some subtle but important stuff got broken and what they did during that time needs to be re-done again from a backup copy. If they have such, that is.

(In reply to Tomasz Sztejka from comment #15)

Thanks for the post!
Basically, I wanted to say that your post is not a contradiction to mine, but rather a clarification of some points there. E.g., I write "... Users do not realize what it does, and how could *what they really need* be achieved ..." and "... users misused (misunderstood) the "to page" anchoring ...", and you describe how *some* (minority of ;-P) users *could* discover that. I mostly agree with you (well, except for "Object anchored to page stays in it's relative position to page corner. This is in fact a bit problematic because it is hard to guess to "which page corner". This, as far as I remember from an old OpenOffice, used to work fine with manual page breaks, but now it seems to ignore it what is confusing" - no, it worked this way from the beginning, e.g. in OOo 1.0.3; and except for "if You add or remove a MANUAL PAGE BREAK. In my opinion it should move then", which is exactly the misconception which caused this bug).

But would you like to implement what you rightfully mention as missing? It's as easy as:
1. Creating an account at TDF;
2. Logging in to https://gerrit.libreoffice.org/;
3. Browsing to "help" repository;
4. Creating a new change for it;
5. Opening the xhp file named like the related help page (e.g., for https://help.libreoffice.org/7.0/en-US/text/shared/01/05260100.html it would be "text/shared/01/05260100.xhp");
making the required changes in plain text in the Web UI, and starting a review.

More on that at https://wiki.documentfoundation.org/Documentation.

> Maybe it is a problem because it never worked as it should work?

Note that "work" is an ambiguous. In this discussion, it's important to disambiguate the two aspects:
1. How anchored objects behave when layouting (i.e., how they behave when the anchored-to object moves, when the anchor settings do not change);
2. How the anchoring UI behaves (i.e., how the tools work that define the anchor settings).

And #1 generally works as it should. But #2 needs much improvements (my bugs mentioned in comment 12, and largely your comment, are focused on this).

(In reply to Mike Kaganski from comment #16)
> which is exactly the misconception which caused this bug

Please ignore the "which caused this bug", it was a thinko (I was thinking about a different bug - tdf#89477 - when wrote this).

> But would you like to implement what you rightfully mention as missing? 

No. Sorry.

How could I do it if I do not know how it was DESIGNED to work? The only thing I could do it would be to describe how it WORKS with all BUGS and MISUNDERSTANDINGS INCLUDED.

It would just cause more mess and would cast in stone some possibly buggy behavior. As a result I would put developers in a pinch - whenever they would find a bug I did cast in stone and try to fix it they would be against published , well known end user specification.

This is like Microsoft API. Whenever API is not specific enough coders do "try it out". Since Microsoft is slow on responding and fixing, so this "tried out" becomes after a year or ten "de-facto standard". And then when they finally fix it to works as it was DESIGNED but never DESCRIBED to users thousands of applications do break. Remember Sinclair? They almost went bankrupt because of a bug fix in Spectrum+ since it broke "de-facto standard" they unintentionally set.

This is also true for any other end user documentation. It must be consistent with DESIGN even if implementation is buggy. Otherwise fixing implementation will be confusing and annoy users.

Hmmm.... it was designed, wasn't it? Somebody wrote it down, right? At least in source code comments? If I would have access to such specs I might try to do put it in help. At least in Polish, because my English is... well... You read it right?

I hope it's true otherwise I see a dark future for the LibreOffice.


Sorry for a delayed reaction, I have tons of work on my head and almost zero spare time.

Removal from the Anchor context menus and TB split button was a little heavy handed, but NAB.

Users needing a 'to Page' anchor (e.g. for laying out a large single page poster) can customize and add the 'Anchor to Page' (.uno:SetAnchorToPage) to a specific context menu object type--or to a generic Menu, Toolbar, NB, or a Keyboard shortcut assignment.

Back to UX-Advise

IMHO a => WF is fair. Not too much to be gained by reverting, but some Help and UG treatment is certainly now needed.

No need for further input from UX. The patch was initiated by the group and I see no argument challenging the reason: safety/consistency.

*** Bug 146374 has been marked as a duplicate of this bug. ***

*** Bug 146816 has been marked as a duplicate of this bug. ***

I do not understand that. As it is now, it is misleading and incomprehensible! You can no longer create layouts that actually remain fixed. This definitely needs to be changed!

(In reply to Werner Schneider from comment #24)
> You can no longer create layouts that actually remain fixed.

Yes you can: the "to page" anchoring is there in the object properties dialog. But are you sure that you really need that anchoring? Most of the time, people believe they need that, when in fact they need "to paragraph" anchoring, and some fixed *positioning* (as explained in FAQ linked in comment 12).

I know the function on the side in the properties, I also use it as a workaround because it is now missing in the context menu.
If you use an paragraph and protect the position of the inserted objects, then the objects will move if you insert something before the paragraph, because the protection is only effective inside the paragraph. That's why anchoring to the side is important.
I think I can judge what I need and what not. Hopefully more proven features won't be cut.

(In reply to Werner Schneider from comment #26)
Only a suggestion:

Tools -> Customize -> Context Menu Tab (or Toolbars tab)

1) Target -> Image (or for toolbars tab 'Frame')
2) Search for 'To Page'
3) Select Anchor To Page
4. Arrow right button in 
5. Move it the desired position in context menu 

Press OK.

(In reply to Werner Schneider from comment #26)
> If you use an paragraph and protect the position of the inserted objects,
> then the objects will move if you insert something before the paragraph,
> because the protection is only effective inside the paragraph. That's why
> anchoring to the side is important.
> I think I can judge what I need and what not. Hopefully more proven features
> won't be cut.

Assume you have anchored an object "to page" and this page is currently the fifth page of the document. When you then enter a TOC on one page and a preface on one page at the beginning, then the object is still on the fifth page of the document. But this fifth page is two pages before the content, where the object was when you had anchored the object. That is very likely not the behavior you want.

To keep the object at top of page, for example, you anchor it to paragraph. Then in the Properties or the Position&Size dialog (depends on object), tab Type go to the section Position. There you set Horizontal... To and Vertical... To to 'Entire Page' or 'Page text area' as needed. When you then enter pages before the anchor paragraph, then this paragraph might go to the next page and the objects too. But the objects are still at the same position relative to the page as before.
You only need to know, that you must not move the object by mouse or keyboard, because that turns the absolute position back to position relative to paragraph.

If you insist on using "to page" then add the command to a toolbar or context menu respectively, see comment #20.

Thank you for the hints!
I already know them. They all have their place, just like the anchor on the side. After all, it has been used successfully for many years. There was no advantage in removing it from the context menu, only disadvantages.
So what is this? So far, everyone has been able to choose how they want to anchor in the context menu, and that was a good thing. Why is something like this being changed, it makes no sense.

(In reply to Werner Schneider from comment #29)
> So what is this? So far, everyone has been able to choose how they want to
> anchor in the context menu

No. "I have been able to choose how I want to anchor" is *not* the same as "everyone". That you know how anchoring and positioning works is good, but that doesn't mean that everybody does; and careful reading of the issue would allow you to discover that the rationale is *multiple* issues in users who are confused by the feature. Anchoring to page is not intuitive to users; it has its serious drawbacks that should be realized when it is used; and so it is a *power user* feature, that should not be offered as prominently, to avoid more confusion in inexperienced users than it brings advantage to those who would be able to find it anyway.

Not all users use L.O. for the same applications. For our applications, the anchor on the side in the context menu is missing. This is crap! Basta!

So the change was intended (and the original report, which has identified the change from the start, and knew that it was intended, claimed "regression" incorrectly); its reasons are sound; everyone who really needs the function is able to use it from the respective dialog; it may be also added to menus using normal customization methods. It is a power user; and no power user would be unable to find it. When poser users ignore the facts and just claim something crap because of own arrogance, that is not an argument.

Closing WONTFIX.

*** Bug 148436 has been marked as a duplicate of this bug. ***

Not that it will change anything, but just to add my ha'penneths worth to the disgruntled user base whom this change affects.

I use this "power" feature every time I type a letter with my scanned signature inserted into it. I deliberately anchor the image to the page, and have done now for over 20 years of using StarOffice/OpenOffice/LibreOffice. This page constitutes my signature page, and is preceded by a page break.

If I use an existing document to overwrite and/or modify its content, then having the signature remain on the allocated last page is a useful check to make sure I haven't left anything I don't want by mistake.

As a result, for all of this feature being deemed a "power user" feature, the change has broken my longstanding workflow. On both a personal and professional level, I don't find that at all helpful, nor do I find the recommendation by some here to "simply" reconfigure the submenu with the appropriate UNO command to be appropriate either. The fact is that user configuration changes to menus/submenus have had a tendency in my experience in the past to get overwritten by newer versions of the software. What that means is that I've gone from a simplistic workflow to a now much more complicated process of having to reconfigure the menu, and hope that my change doesn't somehow get overwritten with a future version update, and/or save my application configuration somewhere else.

Please would someone explain to me how that has simplified my life ?

By all means, encourage users to use the software in a way which is deemed "the one true way", but please don't remove stuff that people have relied upon for 20+ years and then tell them that they only have to "simply" reconfigure their environment to bring it back. That kind of approach doesn't endear users like myself to the product. It is literally another straw on the camel's back.

"anchor to page" was a very important option for us.
We anre publishers and consultant in publishing  and in all books, you have a pagenumber in the top or the bottom of pages.
But, whithout "anchor to page" option, it is no more possible for us to mask some page numbers. We do it using a single form which is anchored on the page et just transfered  by copy to all the pages where it's needed.

(In reply to Arnold Couchard from comment #35)

Then please continue using this feature as before, just using the dialog and/or customized toolbar/menu. It is not going to be removed.

*** Bug 160815 has been marked as a duplicate of this bug. ***

*** Bug 161175 has been marked as a duplicate of this bug. ***