Bug 66065 - VIEWING: Image anchor does not appear with paragraph to which it is anchored
Summary: VIEWING: Image anchor does not appear with paragraph to which it is anchored
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.4.2 release
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 90562 (view as bug list)
Depends on:
Blocks: Writer-Images Paragraph
  Show dependency treegraph
 
Reported: 2013-06-23 03:19 UTC by severoraz
Modified: 2020-10-02 06:31 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Demonstrates case 3a. (23.15 KB, application/vnd.oasis.opendocument.text)
2014-07-10 15:57 UTC, severoraz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description severoraz 2013-06-23 03:19:45 UTC
Steps to reproduce:
0. Turn on non-printing characters (Control+F10 by default)
1. Insert two empty paragraphs
2. Insert an image on the first empty paragraph with anchoring to paragraph
3a. Set the image's vertical alignment to top. You will see the anchor icon aligned to the topline of the image, but not over the paragraph sign to which the image is anchored
3b. Set the image's vertical alignment to bottom and try to anchor the image to the second empty paragraph by moving the anchor icon. You will see the anchor icon move just one line down, instead of over the second empty paragraph sign.

Expected behavior:
On either case (3a or 3b), it is expected to have the anchor icon move over the paragraph sign to which the image will be attached. This would let the user know, precisely, to which paragraph will the image be anchored. Other behavior is misleading and can lead to frustration!

              
Operating System: All
Version: 4.0.4.2 release
Comment 1 Dominique Boutry 2013-11-02 16:02:38 UTC
LibO 4.1.2.3 on Win7 : what I see :

- After a manual move, the containing paragraph is the one whose area contains the top-left corner of the moved image ; the vertical position of an image is computed and stored relative to the top-left corner of this paragraph (doubleclic on the image > Type > Position > Vertical > from TOP), no matter the previous vertical reference ("top" or "centre" or "bottom" or already "from top"). A choice was to be made between top and bottom, and top ("from top" with a given displacement) was the more logical,
- After a move of the anchor icon, the position of the image (relative to the containing paragraph) are unchanged ; this choice may however results to an image partially or totally out of the area of the paragraph containing the anchor : for instance if the image is "from top" with a big displacement. A subsequent manual image move begins in this case to a big paragraph jump,
- the anchor is drawn at the top-left corner of the containing paragraph (here too, logical choice) ; it coincide with the paragraph mark only if the paragraph is empty. Making the anchor always drawn on the paragraph sign would have been misleading, relative to the reference point retained after a manual image move.
Comment 2 Dominique Boutry 2013-12-07 16:51:51 UTC
Additional investigation under the LibO 4.2.0.0 béta2 on Win7: I confirm my comment 1.

Is it possible to switch this issue to NEW in order to have the point of view of a specialist or a developper ? A decision between two variants must be done.

Wolterh6 : what is your position ? Feel free to contact us if disagreeing.

Regards.
Comment 3 severoraz 2013-12-07 18:24:32 UTC
It seems we both agree in that the anchor symbol must always be rendered on the top-left corner of the attached-to paragraph. However, I find it is counter-intuitive to have the anchor symbol be rendered on the top-left corner of the paragraph area (see step 3a of the description) when this corner does not coincide with the first character in the paragraph. I. e., I think the anchor symbol should always appear on the top-left corner of the paragraph as is visually interpreted: over the first character of the paragraph.

I would also like to expand the steps to reproduce this bug (as I see it) in order to further evidentiate what I see wrong with this system. Below I copy the old steps modified.

Steps to reproduce:
0. Turn on non-printing characters (Control+F10 by default).
1. Insert two empty paragraphs.
2. Insert an image on the first empty paragraph with anchoring to paragraph
3a. Set the image's vertical alignment to top. You will see the anchor icon aligned to the topline of the image, but not over the paragraph sign to which the image is anchored.
3b. Set the image's vertical alignment to bottom and try to anchor the image to the second empty paragraph by moving the anchor icon. You will see the anchor icon move just one line down, instead of over the second empty paragraph sign.
4. Insert a second image and attach it to the second paragraph, vertically aligned to bottom, like the first.
5. See that the anchor symbol of the second image appears just one line below the first paragraph, and is aligned with the first image (not with the first character of the paragraph, in this case the non-printing paragraph symbol).
Comment 4 severoraz 2013-12-07 18:26:37 UTC
In short, my opinion is that since one aligns a figure "To Paragraph", the anchor symbol should always appear over the perceivable paragraph area; that is, on the top-left corner of the smallest rectangle that could cover all the letters in the paragraph.
Comment 5 retired 2013-12-29 12:39:41 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2014-07-08 17:28:50 UTC Comment hidden (obsolete)
Comment 7 severoraz 2014-07-10 15:57:56 UTC
Created attachment 102558 [details]
Demonstrates case 3a.
Comment 8 severoraz 2014-07-10 16:04:28 UTC
The attachment above demonstrates case 3a per the bug description. 

Case 3b can't be statically demonstrated because it is only observable while one is dragging the  anchor, thus case 3b is less important. What case 3b critiques can even be considered of subjective incorrectness.
Comment 9 Matthew Francis 2015-03-23 14:06:24 UTC
Confirmed on Libreoffice 4.4.0.3 / OSX 10.10

Setting -> NEW
Comment 10 Matthew Francis 2015-04-11 16:12:53 UTC
*** Bug 90562 has been marked as a duplicate of this bug. ***