Description: Image to character/paragraph at the end or beginning of a paragraph isn't included in a single line section Steps to Reproduce: 1. Open the attached file 2. Select the image 3. Arrow left/right (to get the anchor shown at the actual position) 4. Select the "Lorem ipsum" in any way you pick (keyboard/dragging). you won't get the image included 5. Select up down to include 2 lines.. not it's working 6. Change the anchor of the image to paragraph.. 7. Repeat 4.. same thing If you drag the image around.. (with to character anchoring) you will notice the image is constantly anchored at the end.. (which not wrong with.. but makes obvious the this kind of anchoring not being uncommon) Drag the image up.. now it's attached to the heading.. You can select the heading Actual Results: Image ins't included in selection Expected Results: Should be possible Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) Build ID: e97a81e94511b52987a50b7bdb72c922899da588 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 168319 [details] Example file
Fine (for the to character anchoring in) Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL
Also fine in 6.2.9 (for the exact issue as in this bug report) Moving the image to Lorem between the to headings.. and this same thing doesn't work.. which is even the case in 3.3.0
Created attachment 168328 [details] Bibisect log Bisected to: author Michael Stahl <Michael.Stahl@cib.de> 2020-04-09 18:31:50 +0200 committer Michael Stahl <michael.stahl@cib.de> 2020-04-14 16:59:00 +0200 commit 971205dc2110c1c23ff1db1fc4041e2babf6fa9f (patch) tree 206e18ddc8ee58be806c59ed4e78724550647498 parent 11785217594d863efb518aa8b8f2910cdcb9c59d (diff) sw: fix fly at-char deletion API behaviour change 28b77c89dfcafae82cf2a6d85731b643ff9290e5 changed at-char anchored fly selection. WollMux calls setString("") to remove one character in the first paragraph and a fly anchored at the start of the body text is deleted due to the new IsAtStartOfSection() check. It would be possible to treat deletion via API differently than via UI, as there is already a flag ExcludeFlyAtStartEnd but it would require passing the flag through 10 functions and also to store it in SwUndoDelete... The main intent of the IsAtStartOfSection() check was that Ctrl+A should delete every fly; this can be achieved by checking that everything was selected, so that selections only inside the first/last paragraph don't delete the flys at the edges. https://cgit.freedesktop.org/libreoffice/core/commit/?id=971205dc2110c1c23ff1db1fc4041e2babf6fa9f
Adding CC: to Michael Stahl Didn't work properly in similar cases prior to this commit.. so this regression is also an improvement in the sense of more consistent.. Except the outcome isn't ideal from user point of view (who visually edits; no clue about the programmers of WollMux)
Tested with Version: 7.1.3.2 (x64) / LibreOffice Community Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL For me it seems, that there is the general rule: You can select an image (anchored to paragraph or to character), if paragaph has at least one character and it isn't the last paragraph. Not sure, if this is a bug or not, because I don't understand comment 4. Michael, what do you think?
Confirming in Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ccbd2b0c663fa19be5301f0ea8ac74caa055fe47 CPU threads: 14; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: threaded
yep, the image anchored at the edge of a section will be selected only if the selection spans multiple paragraphs. but this is already the case if it's anchored at the end of any paragraph, the difference is just that in this case you can't extend the selection in the direction where the image is anchored, because there's nowhere to go, you have to extend it in the *other* direction. i don't think there's an easy tweak to this that preserves the API compatibility that comment#4 is about, and it's a rather minor problem, you can always click on the image to delete it that way. so i guess it could be NOTABUG or WONTFIX...
Created attachment 180761 [details] Example file Second attempt (In reply to Michael Stahl (allotropia) from comment #8) > i don't think there's an easy tweak to this that preserves the API > compatibility that comment#4 is about, and it's a rather minor problem, you > can always click on the image to delete it that way. A small retry probably better describing the 'issue'. Primary question: What's the value of anchoring an image to an character if the anchor is broken with ease. The anchor suggests a connection between 'the character' and the image . The image is positioned relative to the anchor point, so if the characters move (drag/drop or copy/paste) the image should be following. 1. Open the attached file 2. Double click Lorem Ipsum 3. Drag the text to the top of the page (say it's a list without bullets) 4. Notice the image moving (why: image is anchored to character, and the anchor is manually attached to 'm' of ipsum 5. CTRL+Z 6. Change the anchor of the image to 'to paragraph' 7. Change the anchor back to 'to character' (anchor will but after ipsum). Now drag the text up again.. Image stay's behind (expected to move along with the text) as in 4 8. Undo the dragging up (but anchor still behind 'ipsum') 9. Press CTRL+A and enable bulleted list 10. Move Ipsum Lorum up (with arrows). Notice the anchor moving along. I guess there being an explanation for each and every case in technical sense. But from end-user perspective this kind of arbitrary. And well 'to character' has to states. (A). Truly positioned to a character. (B) put after a characters (most common, I guess). Which is not truly a to character anchor, IMHO In case of 'to paragraph' we end up' what 'anchor to paragraph' means. Is the image bound to the paragraph (the characters) or bound to paragraph location. Currently it's mixture of both (case dependent) A fix would be to actually anchoring the anchor to a character and not the 'invisible' behind or in case of to paragraph 'prior' the visible character. [sorry, for the bad terminology]. But I'm not overseeing the consequences..
(In reply to Telesto from comment #9) > Created attachment 180761 [details] > Example file Second attempt > > (In reply to Michael Stahl (allotropia) from comment #8) > > i don't think there's an easy tweak to this that preserves the API > > compatibility that comment#4 is about, and it's a rather minor problem, you > > can always click on the image to delete it that way. > > A small retry probably better describing the 'issue'. Primary question: > What's the value of anchoring an image to an character if the anchor is > broken with ease. The anchor suggests a connection between 'the character' > and the image . The image is positioned relative to the anchor point, so if > the characters move (drag/drop or copy/paste) the image should be following. > > 1. Open the attached file > 2. Double click Lorem Ipsum > 3. Drag the text to the top of the page (say it's a list without bullets) wow, writer can do that? > 4. Notice the image moving (why: image is anchored to character, and the > anchor is manually attached to 'm' of ipsum the anchor is between "u" and "m" so it is not at the end of the paragraph so it is included in the selection. > 5. CTRL+Z > 6. Change the anchor of the image to 'to paragraph' > 7. Change the anchor back to 'to character' (anchor will but after ipsum). > Now drag the text up again.. Image stay's behind (expected to move along > with the text) as in 4 now the anchor is after "m" at the end of the paragraph so it is not included in the selection. > 8. Undo the dragging up (but anchor still behind 'ipsum') > 9. Press CTRL+A and enable bulleted list > 10. Move Ipsum Lorum up (with arrows). Notice the anchor moving along. now this moves entire nodes, so anything attached to the node will move with it (except things that span multiple nodes, then it gets complicated and maybe crash prone...). > I guess there being an explanation for each and every case in technical > sense. But from end-user perspective this kind of arbitrary. > > And well 'to character' has to states. (A). Truly positioned to a character. > (B) put after a characters (most common, I guess). Which is not truly a to > character anchor, IMHO generally anything in writer is either a character itself or positioned *between* 2 characters; "as-char" is an example of the former, "at-char" an example of the latter, and "at-para"/"at-fly"/"at-page" are weird exceptions.
Created attachment 180813 [details] Example file Sorry that I keep going .. 1. Open the attached file 2. Select the highlighted text 3. Move the text up. Yellow and orange shape not moving (yes, I know: anchored at beginning and end of a singe paragraph) 4. CTRL+Z 5. Place arrow before 'ghi' 6. Press Shift Arrow Down (2 paragraph selected). Drag and drop the text below heading 1 -> all images follow 7. CTRL+Z 8. Double click 'Blue' 9. Drag & drop below heading 1.. image not following (image anchored 'before' b) 10. CTRL+Z 11. Place cursor after 'yellow' and select blue with the space before 12. Drag up below heading 1. -> Only "blue' text moves image stays I do not really understand why multi-line paragraph will include images.. but single paragraph not.. And why an anchor at the left of word isn't included with the selection (especially if the space is also included) There is obviously the possibility that I'm mistaking about what to character anchoring is and how it should be used. Aka I might have different expectations compared to the design (how I think it should working < - > How it's actually working). And there obviously also a difference between 'ideal situation' and the part which is technically possible. And yes, sure, there likely always which don't fit any model. (So being off)
I would like some extra input/ other perspectives on the topic here @Seth, You fixed quite a number of documentation issues... and well you're also good at investing a design.. This might become a documentation topic some point anyhow @Eyal You're comments are always appreciated..
"Image to character/paragraph at the end or beginning of a paragraph isn't included in a single line section" Do you mean "an image anchored to a character or to a paragraph, or at the beginning of a paragraph, isn't included when selecting the single line containing that character, or the end of the paragraph, or the beginning of the paragraph respectively"? If not, please try to rephrase the title.
(In reply to Telesto from comment #11) In short and in general: Problems in comment 11 seem to stem from difficulties in knowing how to select an anchor (see bug 146445 for relevant explanations), which is related to/interacts with difficulty in knowing how to interpret the current anchor icon properly to determine the anchor location. Bug 138351 discusses the issue of improving the display of anchor location -- but even if that is improved, it is necessary to know how to insure that the anchor is included in the selection. Possible "responses": - make it easier for a user to know when an anchor is included in a text selection (but no proposals offered for design changes.) - give better documentation about how to insure selection of an anchor (but less effective for those users who expect the interface to be "intuitive", and therefore will not read documentation). About selecting the anchor: Here are three examples that will illustrate how to "succeed" in places where you have "failed". Perhaps these positive examples (along with the explanations in bug 146445) will help you to form an understanding of what is needed to insure that an anchor is selected. > 3. Move the text up. Yellow and orange shape not moving Do NOT repro with cursor placed in paragraph and Ctrl+Alt+Up arrow. All shapes move. Do repro with Ctrl+X on selection and Ctrl+V. > 8. Double click 'Blue' > 9. Drag & drop below heading 1.. image not following > 11. Place cursor after 'yellow' and select blue with the space before > 12. Drag up below heading 1. -> Only "blue' text moves image stays 8 and 11 show examples where you have failed to select the anchor. Additional tests to show how to drag blue shape up, by including the anchor in the selection. 13. Open attachment 180813 [details], place cursor before "b" in blue, then select two characters to left (i.e., space and "w" at end of yellow). Drag selection to Heading 1, see "blue" shape follow. 14. Open attachment 180813 [details], select blue shape, move anchor to middle of word "blue". Double-click "blue", drag to Heading 1, see "blue" shape follow.
(In reply to Eyal Rozenberg from comment #13) > "Image to character/paragraph at the end or beginning of a paragraph isn't > included in a single line section" > > Do you mean "an image anchored to a character or to a paragraph, or at the > beginning of a paragraph, isn't included when selecting the single line > containing that character, or the end of the paragraph, or the beginning of > the paragraph respectively"? Selecting a single paragraph (single line or multiple lines of text) and using drag and drop (or cut and paste) with images anchored to character with the anchor located at the very start or very end of this paragraph, will be outside the selection: thus not included in the cut or drag action and thus remain at the old position when moving the paragraph. Those anchors will be included if you select multiple (2 or more) paragraphs The 'very start of the paragraph' anchor 'to character' is the same position as 'to paragraph' anchor has. The problem isn't limited to 'to character' 'to paragraph' does the same thing. > If not, please try to rephrase the title. Did modify it a little, but feel adjust it even more
(In reply to sdc.blanco from comment #14) > (In reply to Telesto from comment #11) > > In short and in general: Problems in comment 11 seem to stem from > difficulties in knowing how to select an anchor (see bug 146445 for relevant > explanations), Three parts * It's partly about visibility. It nice to now if a selection does include an anchor (and which images shapes/and such entails; images get highlighted; shapes not * If a text selection automatically include the anchor (to character) directly to the left and/or right of the selection. * The intuitivity/ predictability of the behaviour. Select a single text paragraph does *not* include images anchored at the start/end of the paragraph, but multiple paragraphs does. If the paragraph being a bulleted list it does include images too. I still don't grasp the reasoning why a single paragraph should behave differently. >which is related to/interacts with difficulty in knowing how > to interpret the current anchor icon properly to determine the anchor > location. Yes >Bug 138351 discusses the issue of improving the display of anchor > location -- but even if that is improved, it is necessary to know how to > insure that the anchor is included in the selection. Yes > > Possible "responses": > - make it easier for a user to know when an anchor is included in a text > selection (but no proposals offered for design changes.) Yes. One would be making anchor visible as formatting mark regardless of the selection (so being aware of the anchor being present) However this still partial fix. There can be overlapping anchors (multiple at the same spot. And you still don't know which anchor belongs to which shape/image. And you might want distinction between the anchor icon for 'to paragraph' and 'to character' anchors. > - give better documentation about how to insure selection of an anchor (but > less effective for those users who expect the interface to be "intuitive", > and therefore will not read documentation). Yes > > About selecting the anchor: > > Here are three examples that will illustrate how to "succeed" in places > where you have "failed". Perhaps these positive examples (along with the > explanations in bug 146445) will help you to form an understanding of what > is needed to insure that an anchor is selected. > > > 3. Move the text up. Yellow and orange shape not moving > Do NOT repro with cursor placed in paragraph and Ctrl+Alt+Up arrow. All > shapes move. > Do repro with Ctrl+X on selection and Ctrl+V. > > > 8. Double click 'Blue' > > 9. Drag & drop below heading 1.. image not following > > 11. Place cursor after 'yellow' and select blue with the space before > > 12. Drag up below heading 1. -> Only "blue' text moves image stays > 8 and 11 show examples where you have failed to select the anchor. > > Additional tests to show how to drag blue shape up, by including the anchor > in the selection. > > 13. Open attachment 180813 [details], place cursor before "b" in blue, then > select two characters to left (i.e., space and "w" at end of yellow). Drag > selection to Heading 1, see "blue" shape follow. Noticed that, but well obviously a strange selection.. but well > > 14. Open attachment 180813 [details], select blue shape, move anchor to > middle of word "blue". Double-click "blue", drag to Heading 1, see "blue" > shape follow. Yes, true. If you move an image/shape to different paragraph (drag and drop) the anchor will by design move the next paragraph & snap behind (so anchor at the right) of a word (if it's a non-empty paragraph). How snap to character in paragraph exactly works is still black box to me. It does pick some character in the paragraph. I have tendency to say, if an image is moved by drag and drop to different paragraph, mimic the behaviour of to paragraph, and simply but at the start of the paragraph. So skipping the - to me arbitrary - picking of some character.. [but well I'm adding lots of different topics in a single bug report] I'm currently using this bug as a 'discussion topic'. To figure out if there is a bug (or bugs) and which part being documentation or UI feedback issues.
Tried to shorten the title while preserving the meaning, but with less detail.
(In reply to Telesto from comment #16) > How snap to character in paragraph exactly works is still black box to me. There is no "snap to character" in the sense of an automatic positioning/tracking in relation to the location of "to character" anchor, unless you select (in Position and Size Horizontal "to" "Character"). Positioning always depends on the positioning controls selected in the Position and Size dialog (where most of the controls are to define positions in relation to the page or the paragraph where the anchor is located, also when "to character" anchor is used). If you know where you want the image/shape positioned in relation to the anchor, then set the position with the controls and drag the anchor. The shape will "follow" and "keep" its position (as defined in the controls). > I have tendency to say, if an image is > moved by drag and drop to different paragraph, mimic the behaviour of to > paragraph, and simply but at the start of the paragraph. So skipping the - > to me arbitrary - picking of some character. In terms of positioning, "to character" and "to paragraph" anchors are almost identical, except that "to character" also offers positioning options that depend on the character (e.g., font size, padding) or line of text where the "to character" anchor is positioned. If you are not going to use those character-specific options (and do not want to move individual words with "attached" objects, as in your word "blue" with blue shape), then "to paragraph" anchor is sufficient. In general, if you approach positioning solely in terms of "drag and drop" (and never use the positioning options) (and do not have a need to link objects to individual words) then there is no reason to use "to character" anchoring.
(In reply to sdc.blanco from comment #18) Ah, very helpful -- Still kind of interested what the (personal) preference/opinion/idea/ gut feeling is on this: Selecting a single paragraph (single line or multiple lines of text) and using drag and drop (or cut and paste) with images anchored to character with the anchor located at the very start or very end of this paragraph, will be outside the selection: thus not included in the cut or drag action and thus remain at the old position when moving the paragraph. Those anchors will be included if you select multiple (2 or more) paragraphs Should the images/shapes being concluded if a single paragraph is selected (in theory), to be included in the move (drag drop) or cut paste by default. Or is the current behaviour the more sensible one I find the current behaviour unintuitive. But that's only an opinion of a single user..
(In reply to Telesto from comment #19) > Should the images/shapes be included if a single paragraph is selected > (in theory), to be included in the move (drag drop) or cut paste by default. > I find the current behaviour unintuitive. "Intuition" here may depend on your understanding of the intended design. Consider these speculations/observations: 1. Text selection is doing just that. Selecting text, not "paragraph" (in the technical meaning/implementation of paragraph). So drag and drop is moving the selected "text", but it is not possible to select beyond the first character to get the "to paragraph" anchor (or "to character" anchor if placed at paragraph [or word] start or paragraph [or word] end (presumably because the anchor is anchored to "paragraph start" or "end of paragraph"). Because the anchor cannot be selected in these positions, the anchored objects will not be included in the drag-and-drop. 2. When "paragraphs" (as opposed to "text") are moved, then "to paragraph" anchor (or "to character" anchor at start or end of paragraph) is included (so anchored objects move). For example, when you select two paragraphs (and also necessary to mention that the first paragraph has the anchors), you are now selecting the "paragraph" (not only the text), which means that the anchors are also selected/included as part of the paragraph. Now the objects move. (and actually, you only need to select the first character of the second paragraph, because the issue is to select the "paragraph" with the anchors (not just the "text" in the paragraph). (note that if the anchors are on the second paragraph, then drag-and-drop will fail to move the objects, because only the text in the second paragraph is selected, not the "paragraph") As noted before, Crtl+Alt+Up/Down will also move the anchored objects with the text, because that command is moving the "paragraph" (even if the appearance from user POV is the same as drag-and-drop). In short, "to paragraph" anchor must be understood literally as "that paragraph to which the anchor appears". Selecting and moving the text in the paragraph is moving the text, not the paragraph, so the anchor remains with the paragraph. From user POV (and not knowing the technical implementation), I would expect that selecting the entire text content of a paragraph would also include any anchors, so that moving the text would also move the anchors. But maybe there is a good argument/reason for leaving the anchor with the paragraph. In any event, once the actual behavior is understood, then it seems "manageable."
Have changed summary to also indicate "selection" behavior of "to character" anchor in relation to a word. Possibly this "word" behavior is related to bug 149269.