Created attachment 50857 [details] Document that exhibits the bug. Charts pasted into a Word 2010 .docx file from an Excel 2010 spreadsheet that remain interactive (that is, haven't been pasted as bitmap images yet) do not show up in Writer. Instead, there's a blank space. The same chart, however, does show up (though as a non-interactive bitmap) when it's in a .xlsx spreadsheet opened in Calc. Steps to reproduce: 1. Create a chart in Excel 2010. 2. Copy and paste the chart into Word 2010. 3. Save the document as a .docx file. 4. Open the file in LibreOffice Writer. 5. The chart will not be present; instead, there will be white space (which is essentially a lot of line breaks) that equals the amount of space occupied by the chart. This problem may also occur in Office 2007, but I don't have a copy to test it. I've attached a file that I've created using Office 2010 that exhibits the bug. If you need any more information, just let me know!
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
reproduced in LibO 3.5.0 beta 1 and from MSWord 2007 the same problem
Same error confirmed Ms Office 2007 and LibreOffice 3.4.5 OOO340m1 (Build:502) on Fedora 16.
"Version" is most early version of LibreOffice, where bug reproducible, not current version.
Reproduced in LO 3.5.5 on Windows 7 SP1.
Still present in 3.6.1.2 version. Unfortunately, I have a lot of such documents.
Created attachment 66516 [details] bt + console logs on master On pc Debian x86-64 with master sources updated today, I reproduced the problem. Since I enabled symbols, debug, I attached console logs + bt from each lines
Cedric: one for you?
Moved from 3.6 most annyoing bugs list to 3.5 most annoying bugs list, as appropriate (please see http://wiki.documentfoundation.org/Most_Annoying_Bugs).
Note the (related?) bug 51550, all OLE object, ie charts are also not saved when saving from LibO as docx. So fixing either of the bugs might warrant to retest the other.
Reproducible] with "LibreOffice 3.6.3.1” German UI/ German Locale [Build-ID: f8fce0b] on German WIN7 Home Premium (64bit) Already reproducible with LibO 3.3.3 and also with AOOo 3.4.1, so problem probably inherited from OOo May be roots of the problem can be reproduced very simply: 1. open new Writer document witn´h LibreOffice 3.6.3.1 2. Menu 'Insert -> Object -> Chart 3. Complete Chart insertion as simple as possible > Simple bar chart in document 4. Save as .docx (OOXML) and close 5. Reopen Bug: No chart visible But unfortunately the so created sample document can not be opened with MS WORD viewer, seems to be invalid. I will nominate this bug as HardHack on <http://wiki.documentfoundation.org/HardHacks> because this one is a really annoying very old bug.
*** Bug 46546 has been marked as a duplicate of this bug. ***
Created attachment 68528 [details] logs during creation of docx and reopen Following Rainer's comment 11, I attached logs during the creation of docx then during reopen. Made on pc Debian x86-64 with master sources updated today. PS: don't hesitate to grep -v "com.sun.star.awt.XWindow" and "NamedValueCollection::impl_assign: encountered a value type which I cannot handle"
Comment on attachment 68528 [details] logs during creation of docx and reopen (Fixed MIME type)
Err, do note that comment 11 and subsequent test the writing of embedded charts to .docx files, which is already covered in bug 51550 as a DATALOSS. This bug seems to be about loss of charts READING a .docx file that has been created in Microsoft Office.
Created attachment 69679 [details] First attachment, saved as PDF using msWord 2007
Still a problem with 4.0 - the (very useful) logs from Julien suggest the first 4 complaints are about docProps/app.xml: <HeadingPairs> <vt:vector size="2" baseType="variant"> <vt:variant> <vt:lpstr>Title</vt:lpstr> </vt:variant> <vt:variant> <vt:i4>1</vt:i4> </vt:variant> </vt:vector> </HeadingPairs> This section is not liked a whole lot ;-) nor is the next element: <TitlesOfParts> <vt:vector size="1" baseType="lpstr"> <vt:lpstr/> </vt:vector> </TitlesOfParts> But the real issue almost certainly is this one: warn:legacy.osl:21863:1:/home/julien/compile-libreoffice/libo/writerfilter/source/dmapper/DomainMapper_Impl.cxx:3424: DomainMapper_Impl::ImportGraphic warn:legacy.osl:21863:1:/home/julien/compile-libreoffice/libo/oox/source/helper/storagebase.cxx:74: StorageBase::StorageBase - missing base input stream
Created attachment 71026 [details] unpacked trace from Julien's nice archive (thanks !)
*** Bug 57948 has been marked as a duplicate of this bug. ***
As Michael has already confirmed that it's still an issue in LibreOffice4, moving it to 3.6 MAB as we're trying to close 3.5 MAB meta tracker since 3.5 is at EOL.
*** Bug 55715 has been marked as a duplicate of this bug. ***
unfortunately I do not have MS Excel so I cannot replicate instructions step-by-step. If I load the test document ( attachment 50857 [details] ) in LibO 4.0.4 or 4.1.0 I only see a blank page. should I see a chart? does Word visualize a chart on that document?
Yes open the PDF attached to this bug (https://bugs.freedesktop.org/attachment.cgi?id=69679) that is what you should see.
@skiani thanks 4 confirming issue with your pdf sample. I'm then moving it to mab4.0 vs. mab3.6 because 3.6 has reached EOL so we are in the process of closing the meta bug. by the way you should not change the version field that way... (you changed it from 3.3.0 to 4.1.0) version should indicate the first version where the bug has ever been reported, so according to what I read in previous comments the first ever reproducibile version is 3.3.3 ( Comment 11 ) even though is possible that this has been inherited from OOo and was already present in 3.3.0
Vinaya Mandke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=13e8e9e2fe32bc77058b5869c39948b683fb81ec fdo#40594 Fix for chart missing issue in Writer (for docx) 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.
Great thanks for fixing this bug!
*** Bug 68884 has been marked as a duplicate of this bug. ***
*** Bug 66371 has been marked as a duplicate of this bug. ***
*** Bug 67001 has been marked as a duplicate of this bug. ***
Fix verified using 4.2.0.0.alpha0+ Build ID: cc2a405915e82c4b332dd25457f76704dc536d7f TinderBox: Win-x86@39, Branch:master, Time: 2013-10-15_15:51:52.
*** Bug 72838 has been marked as a duplicate of this bug. ***
Created attachment 94135 [details] Word/Writer comparison of Bug 72838 I am reopening this bug, because 2 duplicates that it closed are still not rendering the charts properly. If this is not the correct course of action, please advise. Charts still rendered correctly: Bug 72838 Bug 66371 tested on Version: 4.3.0.0.alpha0+ Branch:master, Time: 2014-02-13_01:44:32
Created attachment 94136 [details] Chart from Bug 67339 attachment 83023 [details] The chart from Bug 67339 attachment 83023 [details] is also not imported correctly. Attached is a copy/paste of only the Chart. Please note: 1) Title axis is not vertically (270 deg) aligned 2) Legend is not placed at the bottom of the chart 3) First data label of 2nd column (250) is displayed on the bottom
Created attachment 94137 [details] Word/Writer comparison of Bug 72838 pg 39 Another example of charts not imported correctly from Bug 72838
Created attachment 94138 [details] Word/Writer comparison of Bug 72838 pg 41 Note that the pie chart is incorrectly rendered
Created attachment 94139 [details] Word/Writer comparison of Bug 72838 pg 41 Note the border around the chart is missing
Created attachment 94140 [details] Word/Writer comparison of attachment 94136 [details]
(In reply to comment #32) > Created attachment 94135 [details] > Word/Writer comparison of Bug 72838 > > I am reopening this bug, because 2 duplicates that it closed are still not > rendering the charts properly. If this is not the correct course of action, > please advise. @Luke first of all thank you for your tests. however I'm closing this bug report since the issue described here was: ".docx (MSO2010) does not show CHART object" the chart in attachment 50857 [details] is not shown in 4.1.x while it is shown in 4.2.0 after Vinaya Mandke fix (see Comment 25) in other words, the issue here was "chart not shown at all" which is fixed. all other "chart non perfectly rendered" issues need a separate report.
@tommy27 I've worked on several other projects, and it's always been my experience that when a feature is not supported, either the original report is used until all of the test cases are working OR associated cases are reopened. It is TDF’s policy to require new reports for failed test after the feature is only partially implemented? If you're going to use this bug to close other reports, shouldn't those reports be working? So when a feature is not implemented, reporters should always use in the title, "implemented it perfectly" or they will have to keep filing bug reports during the development cycle. Very strange.
@Luke please don't get upset. you asked for advise to know if your REOPEN was correct. what has been told to you is that it's better to open a new report. best thing would be to indicata that this is a "followup of Bug 40594" in the description. as said before, the original issue was that chart were not visible at all... now this is fixed... all the rendering imperfections you correctly pointed out has to be reported in a clean new report the present report has already 39 comment and multiple attachements, and is getting difficult to read and follow. so the decision to open new reports and keep this closed is to keep things simpler. best thing, as suggested, is to create new reports each one describing the exact issue you still encounter. for developers it will be easier to fix things if bug is splitted in different parts.
... and when you open the new report please drop a line here with the new Bug number. thanks for you understanding and for your tests.
@tommy27 Not upset just thought it was strange to close the parent before all the children were working. I already cloned this to create Bug 75057 and am in the process of populating it with the issues reported here. In my experience, new feature tend to generate a lot of comments. I'll do my best to help keep the tracker here organized.