Bug 76183 - Image cell anchor broken when autowrap text size increase causes row height change
Summary: Image cell anchor broken when autowrap text size increase causes row height c...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Mike Kaganski
Whiteboard: target:5.4.0
Keywords: bibisected, bisected, regression
: 88958 90434 (view as bug list)
Depends on:
Blocks: Calc-Images
  Show dependency treegraph
Reported: 2014-03-14 16:36 UTC by me
Modified: 2018-01-15 14:02 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description me 2014-03-14 16:36:05 UTC
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
Comment 1 A (Andy) 2014-03-14 22:33:17 UTC
reproducible with LO (Win 8.1)
Comment 2 Matthew Francis 2015-02-16 04:37:51 UTC
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:
commit cd2f8a1cabbfb924c62d7af2aac3ac09288c2d4c
Author: Daniel Bankston <daniel.e.bankston@gmail.com>
Date:   Mon Jun 25 01:21:26 2012 -0500

    Stop calculating row heights and instead use imported row heights only
    Change-Id: I1a5e33c292fb915e61511efbdb9ce4a0cfd7265f

commit 4606ca07de17c930b658206a19446516cf0d4eb7
Author: Kohei Yoshida <kohei.yoshida@gmail.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.
    Change-Id: I8ab5dd1fe7cd8a45b7968e101c893b442d7ce132

commit 62bf434229f9f86469dea3123bc6180bd9979c2c
Author: Markus Mohrhard <markus.mohrhard@googlemail.com>
Date:   Tue Jan 22 23:50:47 2013 +0100

    reset automatic row height flag after import, fdo#59193
    Change-Id: Ied9cb4a2b6a17d8c7b65f4fec3cb17219a5afa5b
Comment 3 Matthew Francis 2015-02-16 04:56:00 UTC
*** Bug 88958 has been marked as a duplicate of this bug. ***
Comment 4 a 2015-03-04 07:20:54 UTC
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  ?!
Comment 5 a 2015-03-11 21:53:58 UTC
'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
Comment 6 Alex Thurgood 2015-04-03 15:02:30 UTC
*** Bug 90434 has been marked as a duplicate of this bug. ***
Comment 7 Passiflora 2015-07-01 21:53:55 UTC
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.
Comment 8 a 2015-08-06 08:58:08 UTC
libreoffice 5, just tried, still same wrong behaviour
Comment 9 m.a.riosv 2015-11-21 15:51:01 UTC
Seems selecting the whole sheet and the doing a Menu/Format/Rows - Optimal heigh put the images in the right place.
Comment 10 a 2015-11-22 18:51:23 UTC
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
Comment 11 Robinson Tryon (qubit) 2015-12-10 01:18:30 UTC Comment hidden (obsolete)
Comment 12 Gerco-Kees 2015-12-18 10:53:26 UTC
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.
Comment 13 a 2015-12-19 09:45:48 UTC
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
Comment 14 a 2016-02-15 06:52:43 UTC
after 2 years, this is not fixed ?
Comment 15 Passiflora 2016-07-07 13:46:11 UTC
Really sad that this bug is still not solved in LibreOffice 5, despite it is solved in OpenOffice since version 4.1.1. 
Comment 16 a 2017-01-30 14:56:32 UTC

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

Build ID: 1:5.2.2-0ubuntu2
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default;

ubuntu 16.10
Comment 17 a 2017-02-06 07:32:03 UTC
libreoffice 5.3 has same problem : images do not follow their cell (anchor to cell, position lock) when above rows automatically adjust
Comment 18 Mike Kaganski 2017-02-11 09:56:04 UTC
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.
Comment 19 Mike Kaganski 2017-02-13 07:26:10 UTC
A patch was submitted for review: https://gerrit.libreoffice.org/34165
Comment 20 Commit Notification 2017-02-13 21:38:55 UTC
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.
Comment 21 a 2017-05-04 08:33:17 UTC
.. 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: / Build ID: 1:5.3.1-0ubuntu1~yakkety0
Comment 22 a 2017-05-11 14:24:25 UTC
same problems on : Version:
Build ID: 1:5.3.3~rc2-0ubuntu0.17.04.1~lo0
Comment 23 Mike Kaganski 2017-05-11 14:27:00 UTC
(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.
Comment 24 Passiflora 2017-09-15 15:01:17 UTC
Thanks Mike, your bugfix works great.
Comment 25 Regina Henschel 2017-12-19 17:10:20 UTC
Works in Version: (x64)
Build ID: 92a7159f7e4af62137622921e809f8546db437e5
CPU threads: 8; OS: Windows 6.19; UI render: GL; 
Locale: de-DE (de_DE); Calc: CL