Bug Hunting Session
Bug 42705 - Graphics Anchored to Cell Do Not Move With Data When Sorted, 'Protect Position' Set or Not, 'Link' or Not
Summary: Graphics Anchored to Cell Do Not Move With Data When Sorted, 'Protect Positio...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 79937 93037 (view as bug list)
Depends on:
Blocks: Calc-Images
  Show dependency treegraph
 
Reported: 2011-11-08 06:36 UTC by u2nBz
Modified: 2018-04-24 19:01 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
example calc spreadsheet with graphics attached to cells (10.73 KB, application/vnd.oasis.opendocument.spreadsheet)
2015-04-23 21:29 UTC, d.rick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description u2nBz 2011-11-08 06:36:42 UTC
After inserting a graphic into a cell and setting 'Anchor to Cell', behavior is normal with cut/paste.

However, when a range containing the graphic is sorted manually (Data | Sort) and the rest of the row moves, the graphic remains fixed at the same location.

This holds true whether Protect Position is set or not, and whether the graphic is inserted as a link or not.

This behavior was noted with v. 3.4.3, OOO340m1 (Build:302) running under Ubuntu 64-bit (amd), but would seem to be non-platform-specific.

Bug possibly related to this one: https://bugs.freedesktop.org/show_bug.cgi?id=41342
Comment 1 Jeff D. Hanson 2012-10-01 22:23:37 UTC
LibreOffice 3.5.4.2 
Build ID: 350m1(Build:2)
Ubuntu 12.04 (Precise Pangolin)/Linux Mint 13 (maya)

I'm encountering this also.  The "Position and Size" dialog for a graphic image anchored to a cell references the absolute page position of the anchor, not relative to the cell position.  Changing the X/Y position to 0,0 causes the image to move to the upper-left corner of the page, not the upper-left corner of the cell.  This isn't going to function properly with most types cell manipulation (like sorting).  Calc tries to hide the defect with copy/paste by adjusting the absolute position but if the target cell is a different size then the image is obviously positioned incorrectly.
Comment 2 Jeff D. Hanson 2012-10-01 23:05:52 UTC
I just updated to:
LibreOffice 3.5.6.2 
Build ID: 350m1(Build:2)

from the Ubuntu PPA.  Same behavior.  Tables in Writer support images properly.
Comment 3 Michel Rudelle 2014-01-09 11:43:49 UTC
The problem is the same with pictures or objects (tables, formulas) and always in the latest versions
Version: 4.1.4.2 Vista-32b
Version: 4.2.0.1 Vista-32b
Best regards
Comment 4 Olivier Cousinou 2014-01-21 11:07:02 UTC
Hi,
I am working as a curator in a modern art museum in Marseilles, France, and everybody here is using "Libre Office" in the administration/scientific team.
We often have to deal with spreadsheets and many of them do contain little images.
When spreadsheets contain images, we are unable to sort them, and it is a huge issue for us.
Please could you fix this bug so we can work easily with this stuff ?
Many thanks and best regards,
Olivier Cousinou
Marseille, France
Comment 5 Michel Rudelle 2014-01-21 18:44:14 UTC
Hi Olivier,
Please, don't change the version, it must be the version where the bug was found. This is very helpfull for developpers.
Regards
Comment 6 elcico2001 2014-06-16 11:16:06 UTC
Seen on LibO 4.2.3.3 too (under Kubuntu).
In LibO 3.5-3.6 there was no problem.
Thanks
Comment 7 Felix55 2014-06-19 06:38:50 UTC
The release 3.6.6.2 is the latest in which the position of the images is working properly, all subsequent showed that by varying the height of the cells (for example, increase or decrease the text contained in them), the image moves from original position and the greater is the displacement as is the number of pages that make up the spreadsheet.
In practice, I had to go back to the 3.6.6.2 release and fix (by hand) to the new location of all the images.
Comment 8 Felix55 2014-06-19 11:02:51 UTC
(In reply to comment #7)
> The release 3.6.6.2 is the latest in which the position of the images is
> working properly, all subsequent showed that by varying the height of the
> cells (for example, increase or decrease the text contained in them), the
> image moves from original position and the greater is the displacement as is
> the number of pages that make up the spreadsheet.
> In practice, I had to go back to the 3.6.6.2 release and fix (by hand) to
> the new location of all the images.
My systems:
Ubuntu 14.04 64bit
Windows Seven 64 e 32 bit
Comment 9 Felix55 2014-06-19 11:03:47 UTC
The release 3.6.6.2 is the latest in which the position of the images is
working properly, all subsequent showed that by varying the height of the
cells (for example, increase or decrease the text contained in them), the
image moves from original position and the greater is the displacement as is
the number of pages that make up the spreadsheet.
In practice, I had to go back to the 3.6.6.2 release and fix (by hand) to
the new location of all the images.

My systems:
Ubuntu 14.04 64bit
Windows Seven 64 e 32 bit
Comment 10 u2nBz 2014-06-19 14:43:56 UTC
Got excited that there might be a version with a fix. Added the repo and upgraded, but found bug still present in 3.6.6.2 also.

There may be some confusion. This bug is not for shifting of existing row order (though that may be a separate bug), but for sorting, altering the row order: The data moves but the images don't.

Still looking forward to a fix.
Comment 11 Jarl Arntzen 2015-03-03 13:47:57 UTC
I can confirm that this bug is also found in 4.4.0.3 on both Windows 8 and Ubuntu 14.04 64-bit. Although it only cost me a couple of minutes in extra work, I'm still 
For the home user or children in school, this bug is quite easily discoverable since those users are more likely to paste in pictures, clipart or similar. 

As much as the bug is quickly encountered, it also equally requires very frequent corrections to the document to work around it. Every single time any data is modified (wrap/nowrap, additional lines added or removed, additional rows added or removed) , all images below the affected row have to move up or down, accordingly. There's no single one-time workaround but instead a frequently re-occurring re-adjustment of pictures.

This quickly turns into a major annoyance for anyone, even the expert user and only the latter will even consider filing a bug report. The rest will quickly depart for any other spreadsheet application which supports sane treatment of in-cell images.

Version: 4.4.0.3
Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7
Locale: nb_NO

Kind regards,
Jarl Arntzen
Comment 12 d.rick 2015-04-23 21:29:58 UTC
Created attachment 115041 [details]
example calc spreadsheet with graphics attached to cells
Comment 13 d.rick 2015-04-23 21:32:03 UTC
I can confirm this annoying bug for version 4.4.2.2 (Build-ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6) on Windows 8.1.
Comment 14 lsalle 2015-08-16 16:15:46 UTC
Bug confirmed on LibreOffice 5.0.0.5 / Ubuntu 15.04.
Comment 15 allcoms 2015-11-14 19:56:37 UTC
If I anchor an image to a cell under LO calc 5.0.2.2 (Arch Linux) that image does not get copied or moved if I copy or cut the cell it is anchored too.
Comment 16 Paul AMIET 2017-01-02 13:59:38 UTC
Bug confirmed in LibreOffice Version: 5.2.3.3
Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf
Threads CPU : 8; Version de l'OS :Mac OS X 10.11.6; UI Render : par défaut; 
Locale : fr-FR (fr.UTF-8); Calc: group
Comment 17 u2nBz 2017-10-01 00:27:11 UTC
Just tested Debian/Ubuntu(x64) release 5.1.6.2 and find graphics still frozen like a stone while other data sorts normally.

Nothing tried -- and pretty sure I've tried everything -- makes the graphics move with their rows when sorted.

When a graphic is anchored to a cell, it's like the anchor passes through to anchor instead to the page. If that's what's happening, this could be a very easy bug to fix. Just need a developer to take a look.
Comment 18 Regina Henschel 2017-12-19 17:19:35 UTC
*** Bug 93037 has been marked as a duplicate of this bug. ***
Comment 19 Regina Henschel 2017-12-19 17:38:27 UTC
*** Bug 79937 has been marked as a duplicate of this bug. ***
Comment 20 Cor Nouws 2017-12-24 09:21:26 UTC
behavior is the same in AOO 4x and LibreOffice 3.3.4
Setting priority and severity to more realistic values
Comment 21 Samuel Mehrbrodt (CIB) 2018-04-05 06:03:54 UTC

*** This bug has been marked as a duplicate of bug 98931 ***
Comment 22 Xisco Faulí 2018-04-09 20:41:58 UTC Comment hidden (obsolete)
Comment 23 u2nBz 2018-04-21 19:41:50 UTC
@Regina Henschel, @Samuel Mehrbrodt (CIB), and @ Xisco Faulí;

Please note this bug:

 - Is NOT a duplicate of 98931 (which it predates anyway)

 - Is still present in the latest release, 5.3.6.1

 - Still needs to be fixed.

Before making any changes here, please download the example Calc spreadsheet created by @d.rick@freenet.de and do a manual sort to see that this bug is still present. And it still has nothing to do with bug 98931.
Comment 24 u2nBz 2018-04-21 20:00:18 UTC
EDIT:

Just checked further down that bug page (way long) and find the fix is pushed out to 6.1.

Only finding 6.0.3 currently available so can not verify. However, trusting this will be resolved in the 6.1 release, marking so. If still present in 6.1 though, "I'll be back."
Comment 25 Adolfo Jayme 2018-04-22 19:17:49 UTC
Do not use the status “FIXED” if you haven’t identified the precise commit which solved the issue. If the problem is no longer reproducible in the latest daily version, use the status “WORKSFORME”.
Comment 26 Xisco Faulí 2018-04-24 19:01:47 UTC
Thanks for retesting with the latest version.
Setting to RESOLVED WORKSFORME as the commit fixing this issue hasn't been identified.