1. Grouping a dataline (Data-->Grouping)
2. Sizing the grouped cell-height to 5cm
3. Insert an image "Insert Graphic" into the grouped cell
4. Collapsing and expanding the group + insided image ---> io.
5. Save the file to ods.
6. Reload the file
7. The image is lost
Please check and fix.
Steps to Reproduce:
User Profile Reset: No
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Can you please explain more about Step3,4.
I couldn’t understand Step3:”Insert Graphic”(did you mean chart or image),and Step4.
Step 3: Insert an image into a grouped cell (Menu->Insert->Image). I bind the image-position to a cell, not to a table-sheet. If the image-height is smaller as the collapsed-area, the image can be collapsing and expanding.
Step 4: If I collapsing/expanding the grouped dataline, the image disappears/appears. That's ok. But if I save the file to .ods and reload it, the image is lost.
The problem of losing image didn't happen on my test. But when I followed the steps you mentioned to reproduce the bug, when collapsing/expanding the group it seem like the image is not inserted inside the grouped cell.
Version: 188.8.131.52.alpha0+ (x64)
Build ID: 77a535285f0fd5f2464430abdc67cf99be024868
CPU threads: 4; OS: Windows 10.0; UI render: GL;
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-01-23_23:04:23
Locale: de-DE (de_DE); Calc: CL
Created attachment 140011 [details]
Collapsing/Expanding image in grouped line - loosing image after repeated save to .ods
(In reply to rh77 from comment #0)
> 3. Insert an image "Insert Graphic" into the grouped cell
Please attach an example Calc document at this step.
Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the document.
Created attachment 140464 [details]
After saving the file and reload it, the image is not lost
Created attachment 140465 [details]
After saving the file and reload it, the image is lost
(In reply to rh77 from comment #6)
> Created attachment 140464 [details]
> After saving the file and reload it, the image is not lost
Repro disappearance after collapse, save & reload. 3.6 is not affected.
Arch Linux 64-bit
Build ID: 856c57f20f9b07c686a854e0ccbb6ee3b0ee4791
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4;
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on March 7th 2018
Arch Linux 64-bit
Version 184.108.40.206 (Build ID: e183d5b)
d34912b1eb89f5b0fde219ea57902f3a7d05cb7a is the first bad commit
Author: Matthew Francis <email@example.com>
Date: Fri Sep 18 10:34:06 2015 +0800
Bibisect: This commit covers the following source commit(s) which failed to build
Author: Noel Power <firstname.lastname@example.org>
AuthorDate: Tue Feb 19 17:29:32 2013 +0000
Commit: Noel Power <email@example.com>
CommitDate: Tue Feb 19 18:09:24 2013 +0000
fdo#56276 - resize/reposition rotated shapes in a sensible way
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Still reproducible in
Build ID: b92293b3943423324064a8513c2e114d18817179
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3;
Locale: en-US (en_US.UTF-8); UI-Language: en-US
@Regina, since you fixed bug 119191, I thought you might be interested in this issue...
(In reply to Xisco Faulí from comment #11)
> @Regina, since you fixed bug 119191, I thought you might be interested in
> this issue...
Yes, but I will not have much time in the next weeks.
Workaround: Do not anchor the image with "to cell (resize with cell)" but use "to cell".
If the row is resized to 0cm height because of collapsing, the image will resize to 0cm height too in case of anchor "to cell (resize with cell)".
When you reopen the collapsed version, you see in the Navigator, that the image still exists. Expand the group, then double-click the image entry in the Navigator to select the image. You should see some green handles. If you use the Position&Size dialog, it tells you a height of 0,01mm, if you use the Crop-dialog it tells you a height of 1%.
Errors which I see:
The image does not grow if the group is expanded.
If you use "Original size" from context menu, it does not set it to original size.
If you use the Crop-dialog and set Scale to 100%, the anchor moves to cell A1 and the image looses its position.
Further problem: If you collapse the column, to which the image is anchored, the image is not hidden. So the behavior is inconsistent.
If the image size should be restored on setting the row to "show", then the size and position information of the images needs to be kept and written to file. Such would require a different method to 'hide' the image of a collapsed cell then setting its size to zero. I can image to use the layer "hidden" for that purpose. But that is a larger, principle change and therefore has to be discussed.
I know what happens and will fix it together with other problems for cell anchored objects
Should be fixed with https://cgit.freedesktop.org/libreoffice/core/commit/?id=1f0b3c7a40edfa81bbc7a58d123a6a2dfd83e4ca
(The patch covers several bug reports, therefore no automatic notification.)
Arch Linux 64-bit
Build ID: 2764c334c3b9cf428e4e7ab0c28ce6a34036fa77
CPU threads: 8; OS: Linux 5.9; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Built on 2 November 2020