Bug 146445 - Change behaviour of anchor to character in an empty paragraph (see comment 15)
Summary: Change behaviour of anchor to character in an empty paragraph (see comment 15)
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.6.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
: 149162 (view as bug list)
Depends on:
Blocks: Anchor-and-Text-Wrap Writer-Images
  Show dependency treegraph
 
Reported: 2021-12-28 07:35 UTC by Dieter
Modified: 2022-05-23 06:10 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Example file (9.38 KB, application/vnd.oasis.opendocument.text)
2022-05-05 07:32 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dieter 2021-12-28 07:35:32 UTC
Steps to Reproduce:
1. Create a Writer Document and change style of first paragraph to "Heading 1" (not necessary, but makes more visible what's happening"
2. Insert an image
3. Set cursor to first paragraph.
4. Press Enter key several times.

Actual Results:
Anchor of image switches to new paragraph and image moves down.

Expected Results:
Anchor of image should be connected with first paragraph.

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 9c95415de877af1430ab5b7123e11dedd0ea622c
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

and

Version: 7.0.6.2 (x64)
Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL

but not

Version: 6.3.6.2 (x64)
Build-ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: CL
Comment 1 Mike Kaganski 2021-12-28 07:40:21 UTC
You are creating a clear dupe of bug 146443 - why? And additionally, that specific behavior was *asked for* in tdf#120469.
Comment 2 Dieter 2021-12-28 08:15:56 UTC
(In reply to Mike Kaganski from comment #1)
> You are creating a clear dupe of bug 146443 - why?

Because I could reproduce the problem in LO 7.0.6.2, but I couldn't reproduce problems described in bug 146443 wit LO 7.0.6.2. So I think, it couldn't be the same bug.
Comment 3 Mike Kaganski 2021-12-28 08:17:27 UTC
Ah, I might see the point: this one is "since 7.0" (actually since 6.4).

There are *two* changes around this.

1. In 7.0 (and backported to 6.4), there was https://git.libreoffice.org/core/+/a7528cd6f17ea5c5b29e7d607e54c62de0d9e7db, that explicitly aimed to anchor inserted images *to character* (as opposed to previous "to paragraph", with an intermediate "as character" moment during the development phase). That made images follow what was *always* the behavior of "to character"-anchored objects, which was move with its paragraph.

2. In 7.2, tdf#120469 was fixed, which made even to-paragraph-anchored images to follow the paragraph (if #1 would not happen, it would change here anyway).

Both are intentional, not a regression.
Comment 4 Dieter 2021-12-28 08:23:14 UTC
(In reply to Mike Kaganski from comment #3)
> 1. In 7.0 (and backported to 6.4), there was
> https://git.libreoffice.org/core/+/a7528cd6f17ea5c5b29e7d607e54c62de0d9e7db,
> that explicitly aimed to anchor inserted images *to character* (as opposed
> to previous "to paragraph", with an intermediate "as character" moment
> during the development phase). That made images follow what was *always* the
> behavior of "to character"-anchored objects, which was move with its
> paragraph.

Thanks for quick response and explanation. But problem is, that paragraph doesn't move, but anchor changes to new paragraph. I think this is only a problem in empty paragraphs (see further explanations in bug 146443 comment 7.
Comment 5 Mike Kaganski 2021-12-28 08:32:24 UTC
(In reply to Dieter from comment #4)
> But problem is, that paragraph doesn't move

This is just a flaky definition of "paragraph move" concept. See bug 120469 comment 4.
Comment 6 Mike Kaganski 2021-12-28 08:36:47 UTC
(In reply to Dieter from comment #4)
> (In reply to Mike Kaganski from comment #3)
> > That made images follow what was *always* the behavior of
> > "to character"-anchored objects, which was move with its paragraph.
> 
> But problem is, that paragraph doesn't move

Also excuse for the not completely correct phrase above. The behavior of to-character-anchored objects is actually to move *with its character* position, and that implied for empty paragraphs to move when pressing enter in that empty paragraph.

That doesn't change things much, just a clarification of #1.
Comment 7 Aron Budea 2022-01-14 21:52:22 UTC
(In reply to Mike Kaganski from comment #6)
> Also excuse for the not completely correct phrase above. The behavior of
> to-character-anchored objects is actually to move *with its character*
> position, and that implied for empty paragraphs to move when pressing enter
> in that empty paragraph.
> 
> That doesn't change things much, just a clarification of #1.
It does, as Dieter's comments are all related to paragraphs, eg.:

> (In reply to Dieter from comment #4)
> > But problem is, that paragraph doesn't move
Dieter, the image isn't anchored to a paragraph, but to character, as Mike has explained it. If you want to extend the description to include adjusting to To Paragraph anchoring, this is a duplicate of bug 146443.
Comment 8 Dieter 2022-02-08 21:41:55 UTC
(In reply to Aron Budea from comment #7)
> Dieter, the image isn't anchored to a paragraph, but to character, as Mike
> has explained it. If you want to extend the description to include adjusting
> to To Paragraph anchoring, this is a duplicate of bug 146443.

Perhaps my initial comment was not well formulated, but I've never talked about anchor "To Paragraph". It's of course anchor "To Character", but character is obviously part of a paragraph.


So I still think, that - from a user perspektive - it's an unexpected result. At least for the reason of consistency, you should get same result with an empty paragraph and a paragraph containing one character.
Comment 9 Dieter 2022-02-08 21:43:34 UTC Comment hidden (obsolete)
Comment 10 Dieter 2022-02-08 21:44:07 UTC Comment hidden (obsolete)
Comment 11 Aron Budea 2022-02-23 06:55:46 UTC
(In reply to Dieter from comment #8)
> Perhaps my initial comment was not well formulated, but I've never talked
> about anchor "To Paragraph". It's of course anchor "To Character", but
> character is obviously part of a paragraph.
You specifically mentioned paragraph in comment 4: "paragraph doesn't move, but anchor changes to new paragraph". The anchor doesn't change to the new paragraph, the anchor moves with the caret, just like a character after the anchor would move to the new paragraph if you hit Enter with the caret before it.

Also, if you set the anchor to To Character manually between steps 2 and 3 from the description, the behavior is the same in LO 3.3.0. Therefore this isn't a regression.
Comment 12 Dieter 2022-02-26 09:52:36 UTC
I understand, that initial bug report is misleading. So, to be more precise:

Steps to Reproduce:
1. Create a Writer Document and change style of first paragraph to "Heading 1" (not necessary, but makes more visible what's happening"
2. Insert an image. Anchor of image is "To Character" (Although it is not clear to me, what character is in an empty paragraph)
3. Set cursor to first paragraph.
4. Press Enter key several times.

Actual Results:
Anchor "To Chracter" is part of the new paragraph (still don't know what character) and image moves down.

Expected Results:
Anchor "To Character" should be still part of same paragraph (I assume, that - at least in normal text - a character is always part of a paragraph).

(In reply to Mike Kaganski from comment #6)
> The behavior of
> to-character-anchored objects is actually to move *with its character*
> position,

No problem with that

> and that implied for empty paragraphs to move when pressing enter
> in that empty paragraph.

But why is this a necessary behaviour? But I'm not a developer and I don't have to understand in detail. I just can't imagine, that a user expects, that new paragraphs are inserted above an image, if he presses enter in a paragraph below that image.
Comment 13 Mike Kaganski 2022-02-26 10:05:35 UTC
(In reply to Dieter from comment #12)
> > and that implied for empty paragraphs to move when pressing enter
> > in that empty paragraph.
> 
> But why is this a necessary behaviour?

It is not "necessary"; it is just how anchor to character is defined (the anchor is a special invisible "character" that is inserted *before* the anchored-to actual character); and that means, for empty character, that the inserted anchor is *before* ... what? it's before the paragraph end, which serves the anchoring point in this case. So when you put a cursor into an empty paragraph, it is *after* paragraph start, and *before* paragraph end; when you press Enter, you logically insert a "paragraph end - paragraph start" pair in the place where your cursor is, moving the existing old paragraph end to the following new paragraph; and since that moved paragraph end is the anchoring point, the anchored object moves accordingly.
But it is of course possible to special-case it as much as wanted ... just some clear unambiguous and non-confusing specification of expected behavior is needed.

> But I'm not a developer and I don't
> have to understand in detail. I just can't imagine, that a user expects,
> that new paragraphs are inserted above an image, if he presses enter in a
> paragraph below that image.

This is illogical. You are talking about the image being "above" paragraphs - and here you mix the anchoring with the orthogonal positioning; an image anchored to this character may be above or below, may have a fixed position on page, etc. This is not relevant to the discussion.
Comment 14 Mike Kaganski 2022-02-26 10:06:38 UTC
(In reply to Mike Kaganski from comment #13)
> and that means, for empty character, ...

Sorry, a typo: should be "and that means, for empty paragraph"
Comment 15 Dieter 2022-05-02 09:13:40 UTC
(In reply to Mike Kaganski from comment #13)
> and that means, for empty paragraph, that the
> inserted anchor is *before* ... what? it's before the paragraph end, which
> serves the anchoring point in this case. So when you put a cursor into an
> empty paragraph, it is *after* paragraph start, and *before* paragraph end;
> when you press Enter, you logically insert a "paragraph end - paragraph
> start" pair in the place where your cursor is, moving the existing old
> paragraph end to the following new paragraph; and since that moved paragraph
> end is the anchoring point, the anchored object moves accordingly.

Thank you for your detailed explanation. Just let me rephrase, what I understand and let me explain, why I still see inconsistency here and a need for an enhancement:

After inserting an image in an empty document, we have empty paragraph below document and order within this paragraph is: paragraph start | anchor | paragraph end
After placing cursor in that empty paragraph we have: paragraph start | cursor | anchor | paragraph end

Scenario A: press enter => paragraph break between paragraph start and anchor  => New empty paragraph before image (so this is, what you explained as expected behaviour and I can understand it now and therefore I won't consider the current behaviour a bug)

Scenario B:
Press spacebar (or any character) (Order within paragraph is: paragraph start | character (with connected anchor to character) | cursor | paragraph end)
Press Enter => New paragraph after the old paragraph and anchor to character is still part of the old paragraph (Expected)

So I think we can reduce problem to the question: To what should we anchor an anchor to character, if there is no character inside
a) paragraph start => with cursor we have order: paragraph start | anchor | cursor | paragraph end (I would prefer this solution)
b) paragraph end => with cursor we have order: paragraph start | cursor | anchor | paragraph end (current behaviour)
c) Not possible to have anchor to character in an empty paragraph

So let me give some resons for solution a)
1. Consisteny I: If we have anchor to (an empty) paragraph order seems to be: paragraph start | cursor | anchor (to paragraph) | paragraph end
2. Consistency II: Similar behaviour in an empty paragraph and in a paragraph after inserting a character.
3. User expectations: If there is an image with an empty paragraph below and user presses enter we can assume, that he would like to insert a new paragraph below the empty paragraph and not above the image (this is at least what he sees as a result).

So I would see it as enhancement, I've changed bug summary and added design-team for additional input.
Comment 16 Mike Kaganski 2022-05-02 09:46:01 UTC
(In reply to Dieter from comment #15)
> Just let me rephrase, what I understand

Your rephrase is very correct.

Only one, very specific problem in your following explanation (the UX problem itself, and the proposal that you suggest, looks OK to me):

> 3. User expectations: If there is an image with an empty paragraph below and
> user presses enter we can assume, ...

Please do *not* talk in terms of "below/above" in such cases. As I explained in the end of comment 13, the relative position of object and its anchor point is absolutely irrelevant. As soon as you try to define your proposal in terms of "user sees the image above the cursor -> they expect this or that" ... you create a huge inconsistency potential. If you suggest to make insertion of paragraph *before* the anchor when the anchor is the only paragraph contents, then it should be the only behavior: we must do it no matter if the image is above, or below, or to the left or to the right, when it's positioned absolute or relative ...

So please drop that "below". Or the result will quickly become even more confusing.
Comment 17 Mike Kaganski 2022-05-02 09:48:12 UTC
(In reply to Mike Kaganski from comment #16)
> If you suggest to make insertion of paragraph *before* the anchor ...

I'm sorry to create even more confusion. I meant to write "after" where I typed that "before". Sorry. So please read the above as

> If you suggest to make insertion of paragraph *after* the anchor ...
Comment 18 Dieter 2022-05-02 10:00:38 UTC
(In reply to Mike Kaganski from comment #16)
> So please drop that "below". Or the result will quickly become even more
> confusing.

Second try:

So let me give some resons for solution a)
1. Consisteny I: If we have anchor to (an empty) paragraph order seems to be: paragraph start | cursor | anchor (to paragraph) | paragraph end
2. Consistency II: Similar behaviour in an empty paragraph and in a paragraph after inserting a character.
3. Consistency III: There should be the same behaviour as in empty paragraphs without an anchor: New paragraph is inserted after the paragraph (So I assume, this is what users also expect for empty paragraphs with an anchor to character inside)
Comment 19 Heiko Tietze 2022-05-04 11:53:13 UTC
If the caret comes after the object it would become delete on backspace (see also bug 132321). Right now you can delete the empty paragraphs until the second (this is inconsistent as backspace on the very first empty paragraph does not delete but del does).

(In reply to Dieter from comment #15)
> c) Not possible to have anchor to character in an empty paragraph

Sounds logical to me: no character, no anchor. 

Having <space><image><space> allows me to delete both spaces as long one remains. And in case of <space><space><image><space><space> the image is highlighted if the middle section is selected. Very consistent, IMO.

It would be an improvement if the anchor would become a clear symbol for As/To Character.
Comment 20 Dieter 2022-05-05 07:13:50 UTC
(In reply to Heiko Tietze from comment #19)
> Sounds logical to me: no character, no anchor.
+1

> Having <space><image><space> allows me to delete both spaces as long one
> remains.
I confirm that. But that also means, that anchor changes to a different character, if the original character is deleted 8might be the expected behaviour; O.K. for me)

> And in case of <space><space><image><space><space> the image is
> highlighted if the middle section is selected.
I can't confirm that. Image is only highlighted, if I select all spaces (But I have no idea, how it is possible to see, that it is <space><space><image><space><space> or <space><image><space><space><space> or any other combination.)
 
> It would be an improvement if the anchor would become a clear symbol for
> As/To Character.
+1

But what is your conclusion for the current report: "If paragraph is empty, image should be anchored to paragraph instead to character?" I'm fine with that.
Comment 21 Telesto 2022-05-05 07:20:11 UTC
(In reply to Heiko Tietze from comment #19)
> Sounds logical to me: no character, no anchor. 

Well if you insert an object to empty page, and the default default anchor is 'to character', it must be anchored so.. So this actually should work, a contrary what the label might suggest.. 

And keep in mind why To Character became default...

--
> It would be an improvement if the anchor would become a clear symbol for
> As/To Character.

Maybe, but well the anchor is only visible if you have the image selected. And 'to paragraph' anchor is pretty obvious to detect; it's always anchored at the start of paragraph. To character anchor is mostly somewhere in the paragraph. 
Except if the document based on empty paragraphs.. 

I'm undecided if toggle formatting marks should have some marker for anchors

Off-topic side note: it's really hard to use 'to character' to anchor an image to specific word [or more specific a specific character of a word] + positioning the image with drag and drop. To character anchor kind of suggests control over the anchor, but well that's not exactly the case.
Comment 22 Telesto 2022-05-05 07:32:46 UTC
Created attachment 179940 [details]
Example file

I still think the current behaviour being correct.. I admit there are some cases where this actually suboptimal..

1. Open the attached file
2. Press backspace (nothing happens; related to step 7)
3. Press Enter.. -> Notice paragraph being created before the textbox. Also happening in Word
4. Undo everything
5. Type say 'A' character & press Enter -> position sticks (also in Word)
6. Press CTRL+Z to undo the new paragraph
7. Press backspace to delete the 'A' -> Textbox gets deleted). Not happening in Word.. But this should be covered by bug 148868

Above happens independent of anchoring type 'to paragraph' or 'to character'
Comment 23 Mike Kaganski 2022-05-05 07:34:32 UTC
(In reply to Telesto from comment #21)
> Off-topic side note: it's really hard to use 'to character' to anchor an
> image to specific word ...

Yse, completely off-topic, covered by tdf#141160, tdf#141161, tdf#141162.
Comment 24 Heiko Tietze 2022-05-05 10:01:13 UTC
(In reply to Dieter from comment #20)
> But what is your conclusion for the current report: "If paragraph is empty,
> image should be anchored to paragraph instead to character?" I'm fine with
> that.

As Telesto pointed out it's the only straight-forward solution in case of empty documents if we disable the type of anchor in empty paragraphs. The alternative is to accept the current situation, which is more or less clear as Mike explained. If the anchor symbol would become a "pointy anchor" it should be easier to understand.

So many if-then arguments but no clear recommendation from my side ;-).
Comment 25 Dieter 2022-05-05 11:19:15 UTC
(In reply to Heiko Tietze from comment #24)
> So many if-then arguments but no clear recommendation from my side ;-).

So who can decide in such a situation?
Comment 26 Heiko Tietze 2022-05-05 13:39:52 UTC
(In reply to Dieter from comment #25)
> So who can decide in such a situation?

As always, the do-er decides ;-). I would be afraid of messing up with the anchor, we likely missed side-effects, and rather change the indicator. WF could also be a resolution.
Comment 27 Cor Nouws 2022-05-10 09:33:10 UTC
(In reply to Heiko Tietze from comment #24)
> As Telesto pointed out it's the only straight-forward solution in case of
> empty documents if we disable the type of anchor in empty paragraphs. The

But the empty documents is - I think - a rare example of what this report is about: an empty paragraph.

> alternative is to accept the current situation, which is more or less clear
> as Mike explained. If the anchor symbol would become a "pointy anchor" it
> should be easier to understand.

I didn't follow all comments - sorry - but has it been discussed that maybe a possible change is that the cursor is between the anchoring point and the paragraph marker?
Then pressing Enter would not move the anchor.
Comment 28 Cor Nouws 2022-05-10 09:34:44 UTC
(In reply to Cor Nouws from comment #27)

> I didn't follow all comments - sorry - but has it been discussed that maybe
> a possible change is that the cursor is between the anchoring point and the
> paragraph marker?
> Then pressing Enter would not move the anchor.

Ah, but that is ~opposite to the behavior introduced in bug 120469
Comment 29 Cor Nouws 2022-05-10 09:41:12 UTC
the behavior is odd - I do recognize it - but I see no sensible, always logic, way to improve that..?
Comment 30 Heiko Tietze 2022-05-10 12:09:14 UTC
(In reply to Cor Nouws from comment #27)
>... the cursor is between the anchoring point and the paragraph marker?

Comment 13 has some wisdom
Comment 31 Heiko Tietze 2022-05-12 08:30:02 UTC
The topic was on the agenda of the design meeting.

The current situation can be explained (comment 13) and is straightforward. Some may expect the object to move some want it to remain. And ultimately the discussion is somewhat academic anyway. So the recommendation is to keep the current behavior. => WF
Comment 32 Mike Kaganski 2022-05-18 21:18:38 UTC
*** Bug 149162 has been marked as a duplicate of this bug. ***
Comment 33 Roman Kuznetsov 2022-05-18 21:45:37 UTC
(In reply to Heiko Tietze from comment #31)
> The topic was on the agenda of the design meeting.
> 
> The current situation can be explained (comment 13) and is straightforward.
> Some may expect the object to move some want it to remain. And ultimately
> the discussion is somewhat academic anyway. So the recommendation is to keep
> the current behavior. => WF

And I disagree with current behavior and it's fully unclear for users now