When I try to convert a docx file to odt format in LibreOffice charts disappear (regardless of the fact where the docx was created: LibreOffice or Word). I checked opening the zip file that the charts are there but the reference is wrong, i.e. the chart content is in a Object 1 folder inside the zip but in content.xml the reference is Object 3. In fact if I have multiple charts even though the chart objects seem to be saved fine for the references inside content.xml we find Object 3, Object 6, Object 9, Object 12 and so long so forth. Moreover all alt text is also lost screwing up accesibility. I tested in a few different LO versions in different systems (Linux and Windows) and the bug is always there. Regards, Eduardo
On pc Debian x86-64 with master sources updated today, I don't reproduce this. Here are the steps I did: - create brand new docx file from LO - insert by default chart (just click chart icon) - save in docx - close docx + reopen - save in odt - close odt file + reopen Could you give to last stable LO version 6.3.4? Also could you provide an example? (take a look at https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission before)
Created attachment 157887 [details] Converted odt file I attach a converted ODT file and you can check that the reference to the chart is wrong...I used my local 6.1.3 in Windows but the problem also reproduces in other versions with LINUX
Thank you for your quick feedback. On pc Debian x86-64 with LO Debian package 6.4.0.3 or with master sources updated today, I can see the chart in your file.
Created attachment 157888 [details] Same file converted in LibreOffice/6.3.4.2$Linux_X86_64 LibreOffice_project/30$Build-2 This is the same docx file converted on LINUX with LO 6.3.4.2 Like you can check in content.xml the reference to the chart is wrong...
In the release notes for 6.4 there is no info that that bug has been removed. By the way my 6.3.4.2 runs on Ubuntu18.04
Created attachment 157889 [details] Screen capture zip odt file generated with LO 6.4.0.3 on Windows I just updated my LO version in Windows to 6.4.0.3 and the same thing happens: I attach a screen capture where you can see the zip file open with Objects 1, 2, 3 and 4 while the reference in content.xml are Object 3, 6, 9 12. I higkighted the relevant chunks in the image :-) Thanks for your help, Eduardo
I can also see the chart on the new attachment with LO Debian package 6.4.0 and with LO master sources updated today. Since I don't have more question, I'll put back to UNCONFIRMED. I suppose I missed something but don't know what. Certainly another QA person will reproduce this.
Created attachment 157890 [details] Open this file with multiple charts The charts appear scrambled. The second chart is repeated and the last chart just does not show up. Are you familiar with ODF XML standard? If so please check the content.xml file associated with the odt file and you will see that it is WRONG :-) Otherwise, please, forward the bug to someone more familiar with the inners of LO. The bug is there it is not that I am stubborn :-) Regards and sorry about insisting, Eduardo
I don't know if the charts are scrambled but the second one is indeed repeated and the last one doesn't appear, there's only "Object 12". => NEW Could you provide the original docx file before conversion corresponding to your last example? The goal is to have an example file for testing conversion.
Created attachment 157891 [details] Zip with original docx file and converted odt file I attach the docx file and the odt file within a zip so you can check that everything is messed up. But the most relevant thing, I believe, is the fact that the content.xml file is clearly wrong because the reference to the charts are messed up: they seem to be created always with the pattern 3, 6, 8, 12 like I showed in my screen capture. Thanks for your help :-)
Created attachment 157894 [details] console logs opening docx On pc Debian x86-64 with master sources updated today, I could reproduce this from docx file. Here are the console logs when opening initial docx file
Created attachment 157895 [details] console logs saving into odt then close
Just a couple of comments just in case they may be of help: 1. Charts are there, they are just not properly referred in content.xml: if you edit the generated content.xml file after conversion and change manually the draw:object xlink:href attribute the chart reappears. 2. IMPORTANT: Even though the chart reappears the accesibility info, i.e. alt text is lost. Thanks again for your time and effort :-) Eduardo
Adding some logs on AddEmbeddedObject method, I retrieved these during opening: AddEmbeddedObject rName=Object 1 AddEmbeddedObject rName=Object 2 AddEmbeddedObject rName=Object 3 AddEmbeddedObject rName=Object 1 AddEmbeddedObject rName=Object 3 AddEmbeddedObject rName=Object 4 AddEmbeddedObject rName=Object 5 AddEmbeddedObject rName=Object 2 AddEmbeddedObject rName=Object 5 AddEmbeddedObject rName=Object 6 AddEmbeddedObject rName=Object 7 AddEmbeddedObject rName=Object 3 AddEmbeddedObject rName=Object 7 AddEmbeddedObject rName=Object 8 AddEmbeddedObject rName=Object 9 AddEmbeddedObject rName=Object 4 It seems embedded objects management is quite tricky: comphelper::EmbeddedObjectContainer::AddEmbeddedObject can be called from: 1) comphelper::EmbeddedObjectContainer::CreateEmbeddedObject via SvxOle2Shape::createObject 2) comphelper::EmbeddedObjectContainer::InsertEmbeddedObject via SwXFrame::attachToRange 3) EmbeddedObjectContainer::InsertEmbeddedObject this time via SwOLEObj::SetNode <- SwOLENode::SwOLENode <- SwNodes::MakeOLENode <- sw::DocumentContentOperationsManager::InsertEmbObject <- SwXFrame::attachToRange (the same as 2) ) 4) EmbeddedObjectContainer::InsertEmbeddedObject this time via comphelper::EmbeddedObjectContainer::RemoveEmbeddedObject
With this change: diff --git a/svx/source/svdraw/svdoole2.cxx b/svx/source/svdraw/svdoole2.cxx index fe137647b01b..7f7f77f477b3 100644 --- a/svx/source/svdraw/svdoole2.cxx +++ b/svx/source/svdraw/svdoole2.cxx @@ -1136,6 +1136,7 @@ void SdrOle2Obj::Disconnect_Impl() { if ( getSdrModelFromSdrObject().getUnoModel().is() ) { +/* // remove object, but don't close it (that's up to someone else) comphelper::EmbeddedObjectContainer* pContainer = mpImpl->mxObjRef.GetContainer(); if ( pContainer ) @@ -1147,6 +1148,7 @@ void SdrOle2Obj::Disconnect_Impl() // since no container is adjusted, actually the empty string could be provided as a name here mpImpl->mxObjRef.AssignToContainer( nullptr, mpImpl->aPersistName ); } +*/ DisconnectFileLink_Impl(); } when converting to odt and reopening odt, everything is fine. Of course, it's just a test, this patch must be wrong, it just shows there's something indeed broken in object naming.
Dear Julien, I understand your patch is not the definitive one but did you check if "alt text" was also preserved? That is also important :-) Regards, Eduardo
(In reply to Eduardo Ramos from comment #16) > I understand your patch is not the definitive one but did you check if "alt > text" was also preserved? That is also important :-) I had put this aside, what is "alt text" and how to test this?
You may add alt text to an image or chart in order to help blind people with screen readers to understand what is the image or chart about. In Libre Office if you rigth-click on a chart a contextual menu shows up. If you then click on the Properties menu option a tabbed pop up menu shows and in the Options tab you may include a name, an alternative text and a description that will help people with accessibility problems. I did check that those values were lost in the content.xml created upon conversion to odt format (not only the reefrences to the charts were scrambled but that data disapears). If you need more help I may do a little screencast for you... Regards, Eduardo
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6a1e0590c0aac7460cd8fb823f065621c33b2729 Related tdf#130681: convert number format if model not deleted It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(remove target since it's not the fix)
(In reply to Eduardo Ramos from comment #18) > You may add alt text to an image or chart in order to help blind people with > screen readers to understand what is the image or chart about. > > ... On Windows 10 with master sources updated today, here what I did: - opened docx from your zip package - right clicked on the different images of charts - Properties - Options tab => Alternative (Text only) was empty I also opened the docx file with MsOffice Word, no replacement text too. So nothing lost since there was nothing in the initial docx file.
Created attachment 158006 [details] Docx file with charts with alt text There seems to be another bug :-( I attach a docx file with alt text in Word that is not rendered in LibreOffice even before conversion to ODT format. The bug is: alt text added in docx chart in Word does not render in LibreOffice when open as a docx file, i.e. Word accesibility info is lost in Libre Office. Should I register a different bug? Regards and thanks for your help, Eduardo
(In reply to Eduardo Ramos from comment #22) > Created attachment 158006 [details] > Docx file with charts with alt text > > There seems to be another bug :-( > > I attach a docx file with alt text in Word that is not rendered in > LibreOffice even before conversion to ODT format. > ... You attached an odt file instead of a docx file.
Created attachment 158011 [details] Docx file with alt text in charts Sorry now goes the docx :-)
I can see the alternative text "first" for first chart in Word but not in LO (or missed it). So it seems there's a pb at the import.
On pc Debian x86-64 with master sources updated today, I could reproduce the alternative text pb too. Could you please submit a new bugtracker since it's another bug?
I just did :-)
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/17f49b0cddaac5657a9c308328215a0eb3a87442 Related tdf#130681: use "Standard" page style if nothing else found It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Just another patch related too this one but not the fix.
Created attachment 165072 [details] compared MSO LO This bug is very hard to follow. Report should be consise and clear, with screenshot to compare. That being said, LO saved DOCX opens fine in LO and MSO, so I set WFM. I see that LO saved DOC is not OK in MSO, that needs to be checked separately.
(In reply to Julien Nabet from comment #1) > On pc Debian x86-64 with master sources updated today, I don't reproduce > this. > Here are the steps I did: > - create brand new docx file from LO > - insert by default chart (just click chart icon) > - save in docx > - close docx + reopen > - save in odt > - close odt file + reopen These are wrong steps. Source file can only be ODT from LO or DOC/X from MSO, not DOCX from LO. And source DOCX from comment attachment 157891 [details] is wrongly LO.
Timur: In comment 30 you put WFM then, in the last comment, you indicate a way to reproduce a bug. I must recognize I haven't re-read the whole bugtracker but indeed don't hesitate to submit a new bugtracker so it'll be more clear.
(In reply to Julien Nabet from comment #32) > Timur: In comment 30 you put WFM then, in the last comment, you indicate a > way to reproduce a bug. > I must recognize I haven't re-read the whole bugtracker but indeed don't > hesitate to submit a new bugtracker so it'll be more clear. Forget it, I suppose it's tdf#136426