Bug 140702 - Removal of "To page" anchor context menu entries for frames, images, OLE objects (comment 3)
Summary: Removal of "To page" anchor context menu entries for frames, images, OLE obj...
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.1.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected
: 141091 141686 146374 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-02-27 16:51 UTC by Roman Kuznetsov
Modified: 2021-12-22 21:34 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Kuznetsov 2021-02-27 16:51:20 UTC
Description:
It dissapeared "To page" item from Anchor drop-down widget on Frame toolbar in Writer

Steps to Reproduce:
1. Open Writer
2. Instert any image in to document and select it
3. Click on Anchor widget on Frame toolbar
4. Look at only three items without "To page"

Actual Results:
I can't anchor an image to page using Anchor widget on Frame toolbar, because someone delete "To page" item from it

Expected Results:
I can anchor an image to page using Anchor widget


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.0.3 (x64) / LibreOffice Community
Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: CL

but there is the item in 7.0 => regression

I bisected it with win64-7.1 bisect repo and got

09c24681a3414092fde50ec0f617c9f7c79e8a61

https://gerrit.libreoffice.org/c/core/+/103648

https://git.libreoffice.org/core/commit/09c24681a3414092fde50ec0f617c9f7c79e8a61

Added CC: to Heiko Tietze and Seth Chaiklin
Comment 1 Telesto 2021-02-27 19:10:15 UTC
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.
Comment 2 Dave Barton 2021-02-28 13:55:12 UTC
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.
Comment 3 Heiko Tietze 2021-03-01 08:23:50 UTC
(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
Comment 4 Telesto 2021-03-01 08:51:08 UTC
(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)
Comment 5 Heiko Tietze 2021-03-01 08:56:22 UTC
(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.
Comment 6 Buovjaga 2021-03-18 06:45:24 UTC
*** Bug 141091 has been marked as a duplicate of this bug. ***
Comment 7 Harshita Nag 2021-03-25 09:53:08 UTC Comment hidden (obsolete)
Comment 8 Roman Kuznetsov 2021-03-25 10:16:00 UTC
7.1 isn't an old version and nobody reverted bisected patch, so the problem still here
Comment 9 Xisco Faulí 2021-03-26 16:30:35 UTC
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
Comment 10 Roman Kuznetsov 2021-03-26 17:12:38 UTC
(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
Comment 11 Tomasz Sztejka 2021-04-07 14:49:45 UTC
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.
Comment 12 Mike Kaganski 2021-04-07 15:27:34 UTC
(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
Comment 13 Mike Kaganski 2021-04-14 10:51:40 UTC
*** Bug 141686 has been marked as a duplicate of this bug. ***
Comment 14 Mike Kaganski 2021-04-14 11:27:05 UTC
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.
Comment 15 Tomasz Sztejka 2021-04-21 22:59:42 UTC
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.
Comment 16 Mike Kaganski 2021-04-22 06:10:50 UTC
(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).
Comment 17 Mike Kaganski 2021-04-22 06:33:47 UTC
(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).
Comment 18 Tomasz Sztejka 2021-05-09 15:21:59 UTC
> 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.
Comment 19 Harald Berger 2021-06-07 14:39:09 UTC Comment hidden (me-too)
Comment 20 V Stuart Foote 2021-06-07 15:39:38 UTC
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.
Comment 21 Heiko Tietze 2021-06-07 17:56:03 UTC
No need for further input from UX. The patch was initiated by the group and I see no argument challenging the reason: safety/consistency.
Comment 22 Mike Kaganski 2021-12-22 21:34:30 UTC
*** Bug 146374 has been marked as a duplicate of this bug. ***