Created attachment 68900 [details] Sample Document Steps to reproduce with "LibreOffice 3.6.3.1” German UI/ German Locale [Build-ID: f8fce0b] on German WIN7 Home Premium (64bit) : 1. Open attachment 2. compare positions of dimensionings and compare to view in LibO 3.5.6.2 (screenshot in document Expected behavior: dimensioning at Actual: dimensionings lost their position The dimensioning drawings have been created in a DRAW document, copied to the WRITER document and there by copy/paste the original drawing element has been duplicated and adapted several times Drawings are at correct positions if you open the document with 3.5.6.2 It's not a problem of versions interoperability. The problem also is visible when you put the drawings to the correct positions, save - close - ropen the document with 3.6 Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121011 Firefox/16.0 SeaMonkey/2.13.1
I can confirm this behavior; I did a bibisect using bibisect36 and bibisect40. Marking it also as regression. Kind regards, Joren
Created attachment 73884 [details] bibisect36 log
Created attachment 73885 [details] bibisect40 log
Miklos: I've bisected this, and it is caused by the following commit. Can you please have a look? :-) Thank you! 51cfbf0cfaec395a99a00f2c20fcba96de9a4427 is the first bad commit commit 51cfbf0cfaec395a99a00f2c20fcba96de9a4427 Author: Miklos Vajna <vmiklos@suse.cz> Date: Thu Mar 22 10:34:24 2012 +0100 n#751054 fix VML import of absolutely positioned pictures There were multiple issues here: - convertEmuToHmm() not handling negative values - position:absolute style property being ignored - mso-position-vertical-relative is not converted to text::RelOrientation - SwAnchoredDrawObject::_SetPositioningAttr() re-positioning already positioned objects - DomainMapper_Impl::PushShapeContext() inserting positioned objects as character :040000 040000 2fc3e3cbfcf5ab76e0c77239775b0310976d2d1d c3528fe459fbd7fe250070d3d3634e154329ff28 M oox :040000 040000 3a0fca3c323e3a868db0dc4c837f8702222158d9 29e2cfe186b7dc83a60764741a53812cc368abb3 M sw :040000 040000 5cf252f29d818148c64275efc1d582e2b0a22645 99dc2ddb332addc63c505d5854d7598d779c8c70 M writerfilter
I just checked the n#751054 testcase, and after reverting the SwAnchoredDrawObject::_SetPositioningAttr changes, the test still passes, so that part is no longer necessary. I'll fix this in a bit.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4ae71885ec61f87c46285150ef4ca84192627b7a fdo#56272 SwAnchoredDrawObject::_SetPositioningAttr: fix position 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
4-0 review: https://gerrit.libreoffice.org/2547
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=104947d1825b99503d5df59dfd85ad6e603e1407&h=libreoffice-4-0 fdo#56272 SwAnchoredDrawObject::_SetPositioningAttr: fix position It will be available in LibreOffice 4.0.2. 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
bibisection shows pre-branchoff commit, thus it was at least in 3.6beta, if not earlier