Steps to reproduce: Steps to reproduce the bug: 1. Open attached Chart-Position.docx in LO writer 4.2.x 2. Open Chart-Position.docx in LO writer 4.4.x 3. Open Chart-Position.docx in Word2007/One Drive 4. Compare the documents. Expected Results: In LO the chart should be on the right side of the page, about 1/2 down from the top. Actual Results: In LO 4.2 the chart is on the top right. In Lo 4.4 the chart is now on the top left of the page. I think the LO import filter may be ignoring the paragraph anchor of the chart. If this is fixed, documents like attachment 81686 [details] should import correctly.
Created attachment 104911 [details] Simple .docx file with chart on middle right side of the page
Created attachment 104912 [details] LO 4.4 compared to Word 2007
Created attachment 104913 [details] LO 4.2 vs 4.4
The .doc version of the file, attachment 81316 [details] is correctly imported. The .doc importer uses "Anchor To Character", while the .docx importer uses "Anchor As Character". Could this be the source of the problem?
Confirmed on 4.2.6, 4.3.2 and master on Linux. When opening it in LibO, i see that the page is split into two columns and LibO is putting the chart in the column space as its anchor is set as 'as Character' rather than 'to Character' which is found in the doc file. The chart OLE doesnt appear in any versions before 4.2.
Adding moggi who's recently made some serious progress on the chart import/export code.
Created attachment 115322 [details] Simpler Single Column example This example also needs "anchor as" to be changed to "anchor to" to be positioned correctly.
70d45f7d4bae1f8993fa777cea78f84ae8eac7d4 is the first bad commit commit 70d45f7d4bae1f8993fa777cea78f84ae8eac7d4 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Mar 14 23:25:48 2015 +0800 source-hash-d185204737031955c56a24356ed003d342548434 commit d185204737031955c56a24356ed003d342548434 Author: Miklos Vajna <vmiklos@collabora.co.uk> AuthorDate: Thu Jul 17 14:59:19 2014 +0200 Commit: Miklos Vajna <vmiklos@collabora.co.uk> CommitDate: Thu Jul 17 15:29:40 2014 +0200 DOCX import: set DontBalanceTextColumns=true for the last section ... ... if it has multiple columns. See wwSectionManager::InsertSegments() for the related binary import code which already did this. Change-Id: I919f585bd864db748cd349e01789ec7805f031a1 :040000 040000 48fee3b85c2b572ae67e42a4b1d8cf275eccddec b5d6ae39d677004882b34715ff39b67286f0dad2 M opt # bad: [cf6ea17155fabb2a120ba07c150735591ac861d7] source-hash-3f94c9e9ddfd807b449f3bb9b232cf2041fa12d2 # good: [fc71ac001f16209654d15ef8c1c4018aa55769f5] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e git bisect start 'latest' 'oldest' # bad: [8cf60cc706948588e2f33a6d98b7c55d454e362a] source-hash-f340f0454627939f1830826fb5cc53a90e6c62a4 git bisect bad 8cf60cc706948588e2f33a6d98b7c55d454e362a # good: [d9885f526fc7a09cc8f9f8ee643af1b966be24bb] source-hash-d1465c64c6f64ad8dd25e40cdc69649b24b305ea git bisect good d9885f526fc7a09cc8f9f8ee643af1b966be24bb # bad: [c779cf7967f4d14c5e649a5c696b07279d550efd] source-hash-e9c5022580f14c0ca97503f8b3cc56b530fff174 git bisect bad c779cf7967f4d14c5e649a5c696b07279d550efd # good: [030e0477638f9d9110ad62f88fd4b881521e0541] source-hash-1a6e47e3fda10e6d220b67d766ec6fbdfd852b80 git bisect good 030e0477638f9d9110ad62f88fd4b881521e0541 # bad: [c9e7f255b30a0410226b2074702aeba9b49dce13] source-hash-2d5a7c36ee9ae7ff39d8415f81fb911ff822548e git bisect bad c9e7f255b30a0410226b2074702aeba9b49dce13 # bad: [d0dbfc8071785ec97868d0a98dec934d9eb81e5c] source-hash-24b6add3774f5f0807c907d5a233ba8ac11116f4 git bisect bad d0dbfc8071785ec97868d0a98dec934d9eb81e5c # good: [42270516a592a0472a672fc7058499203b949f21] source-hash-a3b6e0da35987af441042bd444c331d78a7c69b5 git bisect good 42270516a592a0472a672fc7058499203b949f21 # bad: [cfa02ddee0287417171af6f5d1ca6331687e0e19] source-hash-380855c3588092dc6d7472afb265c2457b163d10 git bisect bad cfa02ddee0287417171af6f5d1ca6331687e0e19 # good: [6ad9dfa039a451657b571a7a86db4ce993991b75] source-hash-fdb1d62a09f7320ee5c2828aa4ce84248a6e3e4e git bisect good 6ad9dfa039a451657b571a7a86db4ce993991b75 # bad: [f7488d5effe848d42df39eee53445f3bc596ed17] source-hash-9da4fe80c81b3464b2f6834052a24ce57c2fd07e git bisect bad f7488d5effe848d42df39eee53445f3bc596ed17 # bad: [70d45f7d4bae1f8993fa777cea78f84ae8eac7d4] source-hash-d185204737031955c56a24356ed003d342548434 git bisect bad 70d45f7d4bae1f8993fa777cea78f84ae8eac7d4 # good: [6e5f2f906ce7a1d0c8e91da70f2f2b5397a670e2] source-hash-642d64d8fe54b7577fb4184f1ad6e0e8b3f809c4 git bisect good 6e5f2f906ce7a1d0c8e91da70f2f2b5397a670e2 # good: [4abc107dd5e0b2a8245b7ba640125d8376de2684] source-hash-256281d8e6259dc1a71624b0f8576e9deb9cdc65 git bisect good 4abc107dd5e0b2a8245b7ba640125d8376de2684 # first bad commit: [70d45f7d4bae1f8993fa777cea78f84ae8eac7d4] source-hash-d185204737031955c56a24356ed003d342548434
That is not a chart issue. I suppose that is more one for Miklos.
Added László who's currently working on DOCX anchor issues.
Created attachment 119128 [details] Here is another example Steps to reproduce in Word: 1. Insert Chart 2. Layout Options -> Any of the "With Text Wrapping" options such as "In front of Text" 3. Save as "Docx" (MS-DOC format works) 4. Open in LO 4.2+ (LO < 4.3 works)
Migrating Whiteboard tags to Keywords: (filter:docx bibisected) [NinjaEdit]
Adding Cc: to Miklos Vajna
I'll take care of this. I fail to see how unconditional as-char anchor is a regression, though -- it was always like this, ever since the 13e8e9e2fe32bc77058b5869c39948b683fb81ec code introduced the chart-in-docx feature.
Created attachment 128680 [details] Shows how pictures get correct to/as settings while charts do not Miklos, The regression was purely the position is no longer correct. However, switching from 'as-char' to 'to-char' causes the chart to both move like it behaves in word and to move closer to the correct position. If they are unrelated and your fix for this only addresses the position, I'll file an enhancement about the 'to-char' to 'as-char' issue. The attached docx shows how pictures use correct settings while charts do not. If I save as .doc, we correctly import this file (both position and to/as setting).
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=10efab2b9a3cf7fc49655c90ba29db4512680c38 tdf#82824 DOCX import: fix at-char embedded object handling It will be available in 5.3.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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
No need to file a separate non-regression bug here, I think the above fixes it properly. :-)
Miklos Vajna, Thank you for fixing the anchoring type, but the position does not seem to be working yet. If you open attachment 104911 [details] or the simpler attachment 115322 [details] and got to object -> Type -> Position, you can see that the Horizontal and Vertical values are not being pulled in and still set to "0.00". You can see correct position from the screenshot or opening in LO 4.2 or MS Word.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d36587570890d3366222fc9cca8482275db85b3b&h=libreoffice-5-2 tdf#82824 DOCX import: fix at-char embedded object handling It will be available in 5.2.4. 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.
Created attachment 128970 [details] Picture with same anchor/position as attachment 115322 [details] correctly imported. Miklos, Either there's a bug setting everything to zero or we're missing some conditions that the image import handles. Should I file a new bug report or you want to track here?
Please open a follow-up bug for the non-working case. Thanks!
per comment 18, verified, hence status change.