Download it now!
Bug 63368 - FORMATTING: Images attached to cell get mispositioned when cell above is edited
Summary: FORMATTING: Images attached to cell get mispositioned when cell above is edited
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.0.2.2 release
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Calc-Images Cell-Line-Spacing
  Show dependency treegraph
 
Reported: 2013-04-10 09:58 UTC by sergio.callegari
Modified: 2020-09-26 20:07 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Test case (9.12 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-05-30 08:01 UTC, sergio.callegari
Details
Screenshot of mispositioned image after several line breaks (19.01 KB, image/png)
2020-09-26 10:20 UTC, Thomas Lendo
Details
Handles correctly aligned to cells, but image now disaligned wrt its own handles (20.17 KB, image/png)
2020-09-26 16:36 UTC, sergio.callegari
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sergio.callegari 2013-04-10 09:58:16 UTC
Problem description: 

Say that you have a spreadsheet and that you insert an image and attach it to a cell.

Now, say that in an upper cell you select a format such that the text can wrap.

When you put text in this upper cell, and the text wraps, the image does not anymore stay aligned with the cell it is anchored to.


Operating System: Ubuntu
Version: 4.0.2.2 release
Comment 1 Joel Madero 2013-05-29 21:55:11 UTC Comment hidden (obsolete)
Comment 2 sergio.callegari 2013-05-30 08:01:49 UTC
Created attachment 80018 [details]
Test case

Test case.

1) Open attached document
2) Note that the cloud image is anchored to cell B2, and placed in such a way that the top of the cloud is about half-way in row 2.
3) Now, select row 1 and insert a row before row 1. This works: the cloud correctly moves down, since it remains still relative to its anchor point (now cell B3). Now the top of the cloud is about half-way in row 3.
4) Put your cursor in cell A2 at the end of the world "Foo", press CTRL-ENTER to insert a line break and type "Bar". Note that this is not handled properly. The height of cell A2 is increased in order to accomodate the two lines of text. This means that cell B3, to which the cloud image is anchored moves down. However, the cloud image does not move down, so that its relative position with respect to the anchor point is changed. The top of the cloud should have remained about half-way in row 3, but now it is at the bottom of row 2.
Comment 3 Joel Madero 2013-05-30 13:55:37 UTC
In the future please read the instructions in their entirety:

"Marking as NEEDINFO - once you attach document and explain steps mark as UNCONFIRMED and we will verify the problem."

In general QA doesn't look at NEEDINFO bugs at all as we assume the reporter needs to add details, the bug must be in UNCONFIRMED status to get triaged
Comment 4 ign_christian 2013-06-09 02:34:04 UTC
I can confirm same behavior as comment 2 on LO 4.0.4.1 (Win7 32bit)
Comment 5 QA Administrators 2015-12-20 16:17:59 UTC Comment hidden (obsolete)
Comment 6 sergio.callegari 2015-12-21 14:29:43 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2017-01-03 19:55:37 UTC Comment hidden (obsolete)
Comment 8 Thomas Lendo 2017-03-06 00:29:00 UTC
Bug still present in 5.3.0.3.

I created Bug 106336 for the same behavior especially for columns before I found this bug. I didn't notice that the image positioning problem (if anchored to cell) not only exists with columns but also with rows.

But this bug is cluttered with meaningless comments, the other bug has a too special summary (up to now). A LibO bugzilla expert should decide what to do.
Comment 9 sergio.callegari 2017-03-07 13:25:07 UTC
Issue is still present as of 5.3.1 RC 1
Comment 10 Regina Henschel 2017-12-19 17:41:08 UTC
I do not see the problem in Version: 5.4.3.2 (x64)
Build ID: 92a7159f7e4af62137622921e809f8546db437e5
CPU threads: 8; OS: Windows 6.19; UI render: GL; 
Locale: de-DE (de_DE); Calc: CL
Comment 11 Thomas Lendo 2017-12-30 01:05:57 UTC
The special case described in commend 2 really seems to be fixed.

But copying a column or row with a defined height and inserting it before the column or row with an image, this image isn't correctly repositioned. See also bug 106336.

Version: 6.1.0.0.alpha0+
Build-ID: 38f5e768b0f858f8f990a8f297396821c75d45dc
CPU-Threads: 4; BS: Linux 4.10; UI-Render: Standard; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-12-29_01:09:09
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group threaded
Comment 12 QA Administrators 2018-12-31 03:42:25 UTC Comment hidden (obsolete)
Comment 13 sergio.callegari 2018-12-31 16:24:16 UTC
Improved, but still a bit buggy in LibO 6.2.0 RC 1.

Test case to have an issue needs to be slightly changed to still show the buggy behaviour

Test case (again with attachment 80018 [details])

1) Open attached document

2) Note that the cloud image is anchored to cell B2, and placed in such a way that the top of the cloud is about half-way in row 2.

3) Now, select row 1 and insert a row before row 1. This works: the cloud correctly moves down, since it remains still relative to its anchor point (now cell B3). Now the top of the cloud is about half-way in row 3.

4) Put your cursor in cell A2 at the end of the world "Foo", press CTRL-ENTER to insert a line break and type "Bar". This is broken in LibO < 6.2 and working (sort of) in LibO 6.2. In LibO 6.2 the cloud correctly moves down, since it remains (almost) still relative to its anchor point (now cell B3). Now the top of the cloud is about half-way in row 3. Actually, the behavior is still buggy, because there must be some miscalculation and the image moves /slightly/ up relative to its anchor point.

5) Put your cursor in cell A2 at the end of the world "Bar" and press CTRL-ENTER 10 times. This adds 10 empty lines to cell A2 and makes evident the miscalculation reported at the previous point 4). Now the top of the cloud is not anymore half-way in row 3.



 Note that this is not handled properly. The height of cell A2 is increased in order to accomodate the two lines of text. This means that cell B3, to which the cloud image is anchored moves down. However, the cloud image does not move down, so that its relative position with respect to the anchor point is changed. The top of the cloud should have remained about half-way in row 3, but now it is at the bottom of row 2.
Comment 14 sergio.callegari 2018-12-31 16:25:52 UTC
Sorry for the editing mistake in the previous comment, please ignore the last 6 lines.
Comment 15 Timur 2020-09-25 09:41:20 UTC
I don't see a bug here so I close as WFM because of change. 
If I'm wrong, UX can correct.
Comment 16 sergio.callegari 2020-09-25 21:41:25 UTC
Unfortunately on my system the problem is still there, even if it manifests slightly differently:

1) Open test doc
2) Note top of cloud picture halfway through the second row. Also note that the mid top handle of the cloud is on the cloud.
3) Put the cursor in A1 at the end of the word "foo". Press CTRL+ENTER 20 times to add 20 empty rows in the cell. Now the first row is much taller, but the top of the cloud is still halfway through the second row of the spreadsheet
4) Press CTRL-Z to undo the last change. Now the first row is back to a 1-line height. However, the cloud is now vertically mispositioned (top of the cloud is close to the bottom of the second row). Also note that the mid top handle of the cloud is slightly above the top of the cloud.

... at least on my system with LibO 7.0.2.1

Not a dramatic issue, but a burden if you have a spreadsheet with logos that must be accurately text aligned and someone does a lot of editing and undoes that end up messing the alignments...
Comment 17 sergio.callegari 2020-09-25 21:43:28 UTC
Funny thing is that now the image handles remain correctly positioned, but the image gets mispositioned wrt its own handles.
Comment 18 Thomas Lendo 2020-09-25 22:33:36 UTC
Putting back to NEW as steps in comment 13 still are reproducible. The more more line breaks the more mispositioned is the image.
Comment 19 Thomas Lendo 2020-09-25 22:34:40 UTC
(In reply to Thomas Lendo from comment #18)
> Putting back to NEW as steps in comment 13 still are reproducible. The more
> more line breaks the more mispositioned is the image.
Tested with Version: 7.1.0.0.alpha0+
Build ID: 83aa172697c11a9550c27a28f8e62b523ec7086d
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-09-10_21:26:34
Comment 20 Timur 2020-09-26 07:18:13 UTC
What's the purpose of this bug, just to stay open for years? 
I tested and didn't see a problem. If you claim there is one, make clear experienced and expected, like screenshot marking expected position, or comparison screenshot with other software behaving as you expect.
Comment 21 sergio.callegari 2020-09-26 08:36:51 UTC
Looks like Thomas Lendo is also reproducing the issue, but evidently there isn't any. Let's reduce the bug count, then.
Comment 22 Thomas Lendo 2020-09-26 10:20:20 UTC
Created attachment 165863 [details]
Screenshot of mispositioned image after several line breaks

Version: 7.1.0.0.alpha0+
Build ID: a8c218a52a639b0e7f689dea878a0421702628e0
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-09-25_22:25:07
Comment 23 Thomas Lendo 2020-09-26 10:33:33 UTC
Timur and Sergio, I don't want an edit war, but what's the purpose of a bug when it's closed because it's old but somebody can still reproduce the issue?

I can reproduce the issue.

Sure, it's not so eye-catchting as in the past, thanks to the devs! But it's there and you can see it when you insert many line breaks (ctrl+return) in a cell above an image like in the test file of this bug report.

The more line beaks the more is the issue visible.

I set this issue status back to NEW.

If someone is saying this is not a valid bug and the behavior is as is should be, then please close the bug as WORKSFORME.

Adding Samuel Mehrbrodt to CC list as he worked on image anchoring in the past e.g. at bug 114552.
Comment 24 sergio.callegari 2020-09-26 16:25:29 UTC
Sorry Thomas, thought it was clear that I was still seeing the bug and that to me it should have stayed open, no matter how old, even if there are no resources available to fix in the near time, at least to document the potential issue to other users who might encounter it and get surprised. However, this is no fun and I'd rather give in.
Comment 25 sergio.callegari 2020-09-26 16:31:23 UTC
To Thomas again, I've seen your screenshot and I have a question. Once in the condition illustrated in the screenshot, if you select the cloud picture, are its handles also slightly misaligned with the cloud image itself?
Comment 26 sergio.callegari 2020-09-26 16:36:25 UTC
Created attachment 165874 [details]
Handles correctly aligned to cells, but image now disaligned wrt its own handles
Comment 27 Thomas Lendo 2020-09-26 20:07:50 UTC
(In reply to sergio.callegari from comment #25)
> To Thomas again, I've seen your screenshot and I have a question. Once in
> the condition illustrated in the screenshot, if you select the cloud
> picture, are its handles also slightly misaligned with the cloud image
> itself?
Hi Sergio, you are right and that is what I've overlooked: The handles of the image are on the right position but the image itself is misaligned/mispositioned.