Bug 120469 - Object anchored to paragraph doesn't move if an enter is inserted at the beginning of the paragraph
Summary: Object anchored to paragraph doesn't move if an enter is inserted at the begi...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyInteresting, easyHack, skillCpp
: 134488 (view as bug list)
Depends on:
Blocks: Anchor-and-Text-Wrap
  Show dependency treegraph
 
Reported: 2018-10-09 19:10 UTC by Aron Budea
Modified: 2020-10-02 07:37 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample ODT (8.66 KB, application/vnd.oasis.opendocument.text)
2018-10-09 19:10 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2018-10-09 19:10:39 UTC
Created attachment 145541 [details]
Sample ODT

In the attached document the shape is anchored to the 3rd paragraph ("33 33").
If you press enter at the beginning of the paragraph, essentially moving the whole paragraph, the shape stays anchored to the empty paragraph.

To me the straightforward behavior would be that if the whole paragraph is moved down, the object stays anchored to the moved paragraph, not to the empty new one beforehand. It's also how Word behaves.

Could we consider switching to this behavior, or are there reasons to stick to the existing one? Miklos, what are your thoughts?
Comment 1 Mike Kaganski 2018-10-09 19:20:12 UTC
(In reply to Aron Budea from comment #0)
> If you press enter at the beginning of the paragraph, essentially moving the
> whole paragraph, the shape stays anchored to the empty paragraph.

Well - technically you are not moving the paragraph, but split the existing one, creating *a new following paragraph* with the contents from previous... thus it's strictly speaking correct that all paragraph anchors continue to point to the paragraph object that has lost its content, but not its identity...

I see the point from user's PoV though.
Comment 2 Aron Budea 2018-10-12 20:41:21 UTC
(In reply to Mike Kaganski from comment #1)
> Well - technically you are not moving the paragraph, but split the existing
> one, creating *a new following paragraph* with the contents from previous...
> thus it's strictly speaking correct that all paragraph anchors continue to
> point to the paragraph object that has lost its content, but not its
> identity...

I'd say in this case we can safely say the identity moves along with all the content (though yes, I'm primarily considering the user experience/expectation).

Interestingly, our Word import is inconsistent, in DOCX files anchor to paragraph is kept, while in DOC files they become anchored to character (the first in the paragraph).
Comment 3 Heiko Tietze 2018-11-26 11:54:54 UTC
Adding paragraphs above moves the object, so effectively the anchor is set to the end of the previous paragraph. So I agree with Aron's change request.
Comment 4 Mike Kaganski 2019-11-28 07:27:55 UTC
(In reply to Heiko Tietze from comment #3)
> Adding paragraphs above moves the object, so effectively the anchor is set
> to the end of the previous paragraph.

As far as I know, there is no "adding paragraphs above" function in writer's normal text. When your cursor is inside a paragraph, it's *inside* the paragraph; its position is "M leading paragraph characters to the left of the cursor; N trailing paragraph characters to the right of the cursor". The M and N vary, and M might be 0, but the principle doesn't change. And when the cursor is at 3rd character, and Enter is pressed, no one would be surprised that the image anchored to the paragraph stays with the first two characters that stay where they were.

As I said in comment 1, special-casing of position 0 makes sense - because it might be intuitive; or because it's currently no means to move images anchored to very first paragraphs without re-anchoring. But the implementation needs discussing. I see the following options:

1. Make only the very first position in the document special: because for other places in the document, you always can insert paragraphs before this one by putting cursor at the end of the previous paragraph.

2. Make any paragraph's start special (may possibly create other inconveniences for users not expecting that, but I cannot invent a case at the moment).

3. Introduce an "Insert paragraph above this" special function, using Alt+Enter, *consistent with behaviour in the beginning of a table*. IMO that would introduce consistency and avoid special-casing.
Comment 5 Mike Kaganski 2019-11-28 08:35:01 UTC
Or maybe I'm just inventing problems, and option #2 is just fine.

The split is performed by DocumentContentOperationsManager::SplitNode (in sw/source/core/doc/DocumentContentOperationsManager.cxx), and then in SwTextNode::SplitContentNode (in sw/source/core/txtnode/ndtxt.cxx)
Comment 6 Heiko Tietze 2019-12-02 08:27:34 UTC
(In reply to Mike Kaganski from comment #4)
> 1. Make only the very first position in the document special...
> 2. Make any paragraph's start special...
> 3. Introduce an "Insert paragraph above this" special function...

Hard to imagine that users can follow the arguments of position 0 vs 1, which is your point here. So #2 sounds good to me. 

Thanks for the code pointer. Is it an easyhack?
Comment 7 Mike Kaganski 2019-12-02 08:53:15 UTC
(In reply to Heiko Tietze from comment #6)
> Thanks for the code pointer. Is it an easyhack?

Likely.
Comment 8 Louis Meyrat 2020-01-20 18:37:13 UTC Comment hidden (obsolete)
Comment 9 Timur 2020-10-01 14:35:29 UTC Comment hidden (obsolete)
Comment 10 Timur 2020-10-02 06:19:38 UTC Comment hidden (obsolete)
Comment 11 Aron Budea 2020-10-02 06:54:47 UTC
(In reply to Timur from comment #10)
> I don't go into explanation of the bug, but I'm in favor of WontFix. 
> It's intuitive enough to press enter after "22 22".
Sure, this is a sample, and not a real document. In a real document perhaps you have a table instead of "22 22", so you can't go and press enter after that. And perhaps it's a Word document, there are smaller import problems, and all you want for it to open and look closely the same in Writer, and if not, be able to fix it with the bare minimum amount of steps, like adding a single line break, and not having to do all kind of gymnastics that likely messes up the document even further.
Comment 12 Timur 2020-10-02 07:37:27 UTC
*** Bug 134488 has been marked as a duplicate of this bug. ***