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
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.
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.
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
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
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
Seen on LibO 4.2.3.3 too (under Kubuntu). In LibO 3.5-3.6 there was no problem. Thanks
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.
(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
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
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.
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
Created attachment 115041 [details] example calc spreadsheet with graphics attached to cells
I can confirm this annoying bug for version 4.4.2.2 (Build-ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6) on Windows 8.1.
Bug confirmed on LibreOffice 5.0.0.5 / Ubuntu 15.04.
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.
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
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.
*** Bug 93037 has been marked as a duplicate of this bug. ***
*** Bug 79937 has been marked as a duplicate of this bug. ***
behavior is the same in AOO 4x and LibreOffice 3.3.4 Setting priority and severity to more realistic values
*** This bug has been marked as a duplicate of bug 98931 ***
@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.
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."
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”.
Thanks for retesting with the latest version. Setting to RESOLVED WORKSFORME as the commit fixing this issue hasn't been identified.