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?
(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.
(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).
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.
(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.
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)
(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?
(In reply to Heiko Tietze from comment #6) > Thanks for the code pointer. Is it an easyhack? Likely.
Hi! I'd like to take that one, and implement Mike Kaganski's #2 solution. And thanks for the code pointers !
(In reply to Louis Meyrat from comment #8) > I'd like to take that one, and implement Mike Kaganski's #2 solution. And > thanks for the code pointers ! I guess I may remove Assigned, after such a long time.
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".
(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.
*** Bug 134488 has been marked as a duplicate of this bug. ***
Hi, I would like to work on this bug.
dipanshu124 committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7ed980aa6a57f69f039147a28da8a472811678f2 tdf#120469 Move anchored object if enter is inserted at Para begin It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Works well, thanks for the fix, Dipanshu! Tested with 7.2.0.0.alpha0+ (3e4eb070787d4d44b3bdc95046e5b231dbbef42b) / Ubuntu.
*** Bug 139669 has been marked as a duplicate of this bug. ***