Problem description: Anchor image to cell. Change text size in a cell above the image with autowrap enabled so height of row increases and the image anchor gets broken
Steps to reproduce:
1. Insert image into cell
2. Anchor using tool bar anchor (which appears to anchor to cell)
3. Change text size in a cell above that has autowrap enabled thus increasing the row height.
Current behavior: Images appear anchored but have moved up in relation to their anchored cell.
Expected behavior: They remain in their cell no matter what you do to row heights anchored to top left
reproducible with LO 18.104.22.168 (Win 8.1)
The behaviour of this has changed multiple times.
Before (1) the vertical position of a cell-anchored image remained correct after wrapped text expansion.
After (1) wrapped text doesn't expand and the image is placed wrongly to begin with
After (2) the initial position of the image is correct but wrapped text still doesn't expand
After (3) wrapped text expands but the position of a cell-anchored image in a following row doesn't shift accordingly.
(Of the below authors, Daniel Bankston was GSoC and is no longer involved, Kohei Yoshida doesn't receive Bugzilla email, and Markus Mohrhard has asked not to be Cc'd on bugs - so nobody to forward this to)
(1) source-hash-d59024b652ccfaf7247da113ec36788fe260de74 in bibisect 43all, probably:
Author: Daniel Bankston <firstname.lastname@example.org>
Date: Mon Jun 25 01:21:26 2012 -0500
Stop calculating row heights and instead use imported row heights only
Author: Kohei Yoshida <email@example.com>
Date: Tue Aug 14 16:46:44 2012 -0400
Calculate positions of cell-anchored objects upon ods import.
Since we no longer re-calc row heights on ods import, we need to do
this manually, in order to position cell-anchored objects correctly.
Previously we were getting this for free since the row height recalc
code path did it as part of it.
Author: Markus Mohrhard <firstname.lastname@example.org>
Date: Tue Jan 22 23:50:47 2013 +0100
reset automatic row height flag after import, fdo#59193
*** Bug 88958 has been marked as a duplicate of this bug. ***
just for information, on kingsoft WPS office suites/calc application, images move properly down and that's very comfortable when you have images..
is anyone looking after this in libreoffice-CALC ?!
'scrolling of images' seems to work fine when deleting (or inserting) a row above the image : the image moves up (and down).
it still doesn't work with automatic wrap (wrapping text in a cell, or when pasting a wrapped cell) images don't scroll
*** Bug 90434 has been marked as a duplicate of this bug. ***
Unfortunately in Apache OpenOffice 4.1.1 this problem doesn't exist, so either they never had it or they fixed it. The bug is not solved since more than a year in LibreOffice.
libreoffice 5, just tried, still same wrong behaviour
Seems selecting the whole sheet and the doing a Menu/Format/Rows - Optimal heigh put the images in the right place.
that is interesting...so the anchor is not broken... changes in wrapped text are simply not managing images to re-position according to anchor (or the anchor is not moving the image) ?
in my case anyhow, using optimal row height is not acceptable unfortunately as i'm using a mixed formulas/presentation sheet (kind of a pricelist with images as well, which frequently updates taking data from other sheets) and changing row heights would ruin the pages to print
or maybe calc should have as well 'anchor image as character'
hoping this bug will be addressed very very very very soon..thanks
Migrating Whiteboard tags to Keywords: (bibisected)
This bug is introduced since the fixing of another bug:
In bug 67712 the draw-objects were completely distorted throughout the spreadsheet. With the fixing of that bug things got significantly better, but still not perfect.
when selection of multiple sheets (shift+click on the sheets) is active,
1) changing a value in a cell, causes images in different sheets to lose their precise position sometimes visually sometimes only in a pdf (try also with print/pdf printer ; it seems with export pdf as well) and have to select images /right click/anchor to cell even if this setting is already ok (it works as well on multiple section : shift+click on all images, right click, reactivate anchor to cell even if it is already active)
2) changes in format (for instance character height, as well borders...) can change format in other multiple-selected sheet
this happens to me with no. 2 sheets both selected (for instance to print selected areas of multiple selected sheets, leaving multiple selected of sheets on, changing something in a sheet), so i have to deselect multiple sheets to make changes
after 2 years, this is not fixed ?
Really sad that this bug is still not solved in LibreOffice 5, despite it is solved in OpenOffice since version 4.1.1.
1) on rows above the image : activating 'shrink to fit cell size', and 'wrap text automatically' (format cells / alignment tab) causes the same problem every time a row above the image automatically is adjusting its height : the image (anchored to a cell and position lock) still does not move with its cell (though the anchor moves with the cell)
-> it would be enough to update the image position according to the anchor, everytime the height adjusts
2) selecting all the cells of the sheet (top left corner) and 'optimal row' (value +0.1): this brings the image to the proper position BUT 'shrink to fit cell size' does not work anylonger (though it is still flagged);
- if i manually increase or reduce the row height : the image moves properly with its anchor !!
- if i double click on the row low border(margin), and the first time i do this the image moves properly with the cell, 'shrink to fit cell size' starts working again (!) but the image does not move anylonger with the cell (when row height automatically adjust
30th Jan 2017
LIBREOFFICE Version: 22.214.171.124
Build ID: 1:5.2.2-0ubuntu2
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default;
libreoffice 5.3 has same problem : images do not follow their cell (anchor to cell, position lock) when above rows automatically adjust
Between the first and last commits identified in comment 2, that initially turned off height adjustment, and finally returned it back, there was another commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=b10833d4db6046f2d32ea44a60cb19a626d80447 - that most possibly changed the places where the object positions get recalculated. I suppose it may be the real cause of this.
A patch was submitted for review: https://gerrit.libreoffice.org/34165
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":
tdf#76183: refresh objects' positions on optimal height recalc
It will be available in 5.4.0.
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
.. when refreshing rows (no answer to the discussion https://bugs.documentfoundation.org/show_bug.cgi?id=55433 )
problem : 'optimal row height' does not refresh after text input
behaviour : 'optimal row height' is already selected (+0,1cm ; on multimple rows by right clicking on row-number head), when a text is entered or modified, 'optimal row height' is not refreshed (nor applied) : optimal row height has to be manually selected again (right click on the row-number-head) and the dialog window appears saings already the value selected initally (+0,1cm), clicking 'ok' applies the optimal row height again,
expected behaviour : after changing cell content in a row with an optimal row height value <>0, 'optimal row height' should be refreshed/applied automatically again
is it maybe just a refresh to be done after the content of a cell is modified (where optimal row height was pre-selected)
(it could be also appropriate in the 'format cell' tabs [ctrl+1] to show the optimal row value for the cell )
Version: 126.96.36.199 / Build ID: 1:5.3.1-0ubuntu1~yakkety0
same problems on : Version: 188.8.131.52
Build ID: 1:5.3.3~rc2-0ubuntu0.17.04.1~lo0
(In reply to a from comment #20 and comment #21)
Please read the issue's whiteboard, and comment 20's "It will be available" part.
Thanks Mike, your bugfix works great.
Works in Version: 184.108.40.206 (x64)
Build ID: 92a7159f7e4af62137622921e809f8546db437e5
CPU threads: 8; OS: Windows 6.19; UI render: GL;
Locale: de-DE (de_DE); Calc: CL