Apache OpenOffice (AOO) Bugzilla – Issue 108978
WW8. exported OOo Spreadsheet disappears when re-imported in writer
Last modified: 2013-08-07 14:44:16 UTC
worksheet disappears in writer. Open writer document with a text (top) and down worksheet (format .doc compatible 97-2000-xp) - Create in BROffice 3.1. Opening in BROffice 3.1 work fine Opening in BROffice 3.2 rc5 worksheet disappears in writer.
Created attachment 67643 [details] spreadsheet/worksheet disappears in writer
MRU->HBRINKM: in the attached doc (exported by OOo) the Calc object will not be imported anymore since OOo 3.2.
*** Issue 109422 has been marked as a duplicate of this issue. ***
Hmmm, I am surprised that this bug was not marked as showstopper for OOo 3.2. It is a regression so I think it should be fixed for OOo 3.2.1. Added keywords regression and ms_interoperability I reproduce the bug on Ubuntu -> set OS to All Regards. JBF
Same problem in DEV300_m71.
Created attachment 67953 [details] bugdoc created in OOo 3.2
Created attachment 67954 [details] bugdoc converted in doc by JFN
Created attachment 67955 [details] bugdoc converted in doc by JBF
There is a condition to reproduce the bug but I do know which one. I have attached 3 files : - bugdoc_JFN.odt is a file created from scratch in OOo 3.2 FR (Xubuntu 9.04) by JFN. This file contains a Calc table inserted by copy-paste from Calc. - bugdoc_JFN.doc is the file odt converted in doc by JFN. After having closed OOo JFN reopened this file and he can see the Calc table. All other peoples from fr qa-team who tried to open this file do not see the table. But the table is visible if opened in OOo 3.1.1. - bugdoc_JFN_jbf.doc is the file I obtained myself by converting bugdoc_JFN.odt in doc format. No problem for me to see the Calc table when I reopen the file. Regards. JBF
Complement : if JFN opens bugdoc_JFN_jbf he can't see the table. But with an odt file create by myself and exported as doc, he can see the table. I'll attach these files. Regards. JBF
Created attachment 67961 [details] odt file created from scratch by JBF in OOo 3.2
Created attachment 67962 [details] test_jbf.odt exported as MS-Word file by JBF
JFN user made tests with 2 VM (XP and Xubuntu). For him every things work as designed. But when I open his doc files I do not see the Calc tables. I'll attach an archive with data test and a summary of tests made. Regards. JBF
Created attachment 67967 [details] JFN tests
*** Issue 109568 has been marked as a duplicate of this issue. ***
*** Issue 109880 has been marked as a duplicate of this issue. ***
*** Issue 109972 has been marked as a duplicate of this issue. ***
Am attaching original Word and saved OOo (Word 97/2000/XP) versions that illustrate the issue with the '.deb' 3.2 download. Both files are in missing-table-example.tar.gz
Created attachment 68312 [details] Original and OOo saved versions of a '.doc' file with table there and gone.
Updated target milestone accordingly to release blocker status.
*** Issue 110343 has been marked as a duplicate of this issue. ***
*** Issue 110375 has been marked as a duplicate of this issue. ***
Created a document with Calc OLE from scratch, exported as DOC. Reimporting worked fine. @anderson_freitas: Which version of OOo (milestone or build from the about box) did you use to create Test.doc? @mru: Do you know in which milestone OOo can still read Test.doc correctly?
MRU->HBRINKM: you have to generate a document as described in OOo 3.1.1. Then OOo 3.2 and DEV300 will not be able recognize the object in it. 3.1.1 will still be able to import the object - but not 3.2.
@hbrinkm: Create .doc in 2.x (probably)- this .doc is used for many years. Work Fine in version 3.1.1 - OOO310m19 Build:9420)
Tested Test.doc with OOo 3.2 (OOO320m4) on Windows: works fine
analysis: broke in DEV300_m68
Analysis: The OLE is converted on import and the writing of the temporary file fails with the following stack: #0 sax_expatwrap::SAXWriter::endDocument (this=0x2a3e81a0) at /Volumes/tank/OOo/sw321bf02/Source/sax/source/expatwrap/saxwriter.cxx:1117 #1 0x2338aa3e in SvXMLExport::exportDoc () #2 0x2337ab86 in SvXMLExport::filter () #3 0x29f1155b in ScViewOptions::ScViewOptions () #4 0x29efccf2 in ScViewOptions::ScViewOptions () #5 0x29efe97a in ScViewOptions::ScViewOptions () #6 0x29a32c19 in ScDocShell::AsciiSave () #7 0x29a32dac in ScDocShell::SaveAs () #8 0x00599155 in SfxObjectShell::SaveAsOwnFormat () #9 0x005a194b in SfxObjectShell::DoSaveObjectAs () #10 0x005fc8c0 in SfxBaseModel::storeToStorage () #11 0x2999d568 in OCommonEmbeddedObject::StoreDocToStorage_Impl () #12 0x299a29fe in OCommonEmbeddedObject::storeAsEntry () #13 0x0025156d in comphelper::EmbeddedObjectContainer::StoreEmbeddedObject () #14 0x00251921 in comphelper::EmbeddedObjectContainer::InsertEmbeddedObject () #15 0x294919f8 in sw::hack::DrawingOLEAdaptor::TransferToDoc (this=0xbfffb80c, rName=@0xbfffb808) at /Volumes/tank/OOo/sw321bf02/Source/sw/source/filter/ww8/writerhelper.cxx:314 #16 0x29449cd7 in SwWW8ImplReader::InsertOle (this=0x4160e00, rObject=@0x25aeb440, rFlySet=@0xbfffba24, rGrfSet=@0xbfffb8c0) at /Volumes/tank/OOo/sw321bf02/Source/sw/source/filter/ww8/ww8par4.cxx:260 #17 0x293f4a63 in SwWW8ImplReader::ImportReplaceableDrawables (this=0x4160e00, rpObject=@0xbfffba40, rpOurNewObject=@0xbfffba3c, pRecord=0x2a439460, pF=0xbfffba54, rFlySet=@0xbfffba24) at /Volumes/tank/OOo/sw321bf02/Source/sw/source/filter/ww8/ww8graf.cxx:3125 #18 0x293f927c in SwWW8ImplReader::Read_GrafLayer (this=0x4160e00, nGrafAnchorCp=90) at /Volumes/tank/OOo/sw321bf02/Source/sw/source/filter/ww8/ww8graf.cxx:2757 #19 0x29407c09 in SwWW8ImplReader::ReadChar (this=0x4160e00, nPosCp=90, nCpOfs=0) at /Volumes/tank/OOo/sw321bf02/Source/sw/source/filter/ww8/ww8par.cxx:2750 #20 0x29408579 in SwWW8ImplReader::ReadChars (this=0x4160e00, rPos=@0xbfffbd98, nNextAttr=91, nTextEnd=101, nCpOfs=0) at /Volumes/tank/OOo/sw321bf02/Source/sw/source/filter/ww8/ww8par.cxx:2576 #21 0x2940d6cf in SwWW8ImplReader::ReadText (this=0x4160e00, nStartCp=0, nTextLen=101, nType=MAN_MAINTEXT) at /Volumes/tank/OOo/sw321bf02/Source/sw/source/filter/ww8/ww8par.cxx:3054 #22 0x2941155b in SwWW8ImplReader::CoreLoad (this=0x4160e00, pGloss=0x0, rPos=@0x23b3332c) at /Volumes/tank/OOo/sw321bf02/Source/sw/source/filter/ww8/ww8par.cxx:4021 #23 0x294128d4 in SwWW8ImplReader::LoadThroughDecryption (this=0x4160e00, rPaM=@0x23b33320, pGloss=0x0) at /Volumes/tank/OOo/sw321bf02/Source/sw/source/filter/ww8/ww8par.cxx:4473 #24 0x29412ca3 in SwWW8ImplReader::LoadDoc (this=0x4160e00, rPaM=@0x23b33320, pGloss=0x0) at /Volumes/tank/OOo/sw321bf02/Source/sw/source/filter/ww8/ww8par.cxx:4802 #25 0x29413b42 in WW8Reader::Read (this=0x25ac8730, rDoc=@0x4137000, rBaseURL=@0x25a95e2c, rPam=@0x23b33320) at /Volumes/tank/OOo/sw321bf02/Source/sw/source/filter/ww8/ww8par.cxx:4869 #26 0x213aa4bb in SwReader::Read (this=0x25a95e10, rOptions=@0x25ac8730) at /Volumes/tank/OOo/sw321bf02/Source/sw/source/filter/basflt/shellio.cxx:190 #27 0x214c25cd in SwDocShell::ConvertFrom (this=0x25955ec0, rMedium=@0x25987060) at /Volumes/tank/OOo/sw321bf02/Source/sw/source/ui/app/docsh.cxx:282 #28 0x0059a017 in SfxObjectShell::DoLoad () #29 0x005f653f in SfxBaseModel::load () #30 0x00655b33 in SfxViewShell::TryContextMenuInterception () #31 0x185afd7d in dyld_stub_rtl_uStringbuffer_newFromStr_WithLength () #32 0x185b0454 in dyld_stub_rtl_uStringbuffer_newFromStr_WithLength () #33 0x185a1d0f in dyld_stub_rtl_uStringbuffer_newFromStr_WithLength () #34 0x185a2457 in dyld_stub_rtl_uStringbuffer_newFromStr_WithLength () #35 0x002a7934 in comphelper::SynchronousDispatch::dispatch () #36 0x004d6f86 in SfxApplication::LoadTemplate () #37 0x00797308 in SfxShell::CallExec () #38 0x00694d0c in SfxDispatcher::HideUI () #39 0x006955b7 in SfxDispatcher::_Execute () #40 0x00695a67 in SfxDispatcher::Execute () #41 0x00695b36 in SfxDispatcher::Execute () #42 0x004d9428 in SfxApplication::LoadTemplate () #43 0x00797308 in SfxShell::CallExec () #44 0x00694d0c in SfxDispatcher::HideUI () #45 0x00695295 in SfxDispatcher::_Execute () #46 0x006953c0 in SfxDispatcher::_Execute () #47 0x006bb74f in SvxSearchItem::QueryValue () #48 0x006bb6ff in SvxSearchItem::QueryValue () #49 0x0151d7d0 in Window::~Window () #50 0x015c873e in component_writeInfo () #51 0x0137064f in Application::Yield () #52 0x013706e6 in Application::Execute () #53 0x001df885 in dyld_stub_strcmp () #54 0x0137627f in DeInitVCL () #55 0x015c80dc in component_writeInfo () #56 0x015cb942 in SalGetDesktopEnvironment () #57 0x96a7ac4f in -[NSApplication run] () #58 0x96a72c85 in NSApplicationMain () #59 0x015c8dd8 in component_writeInfo () #60 0x0137630b in SVMain () #61 0x0020cfd2 in soffice_main () #62 0x00002bba in main ()
Calc relies on notification of SFX_EVENT_SAVEDOCDONE or SFX_EVENT_SAVEASDOCDONE after saving, to update the stream positions of individual sheets in the content.xml stream of the document's storage (this is needed to distinguish from saving for AutoRecovery, which doesn't modify the document's storage). But for the embedded Calc object, the events aren't notified after saving. This causes an error when saving the second time. Issue 110692 is related to this, but not the same: There, the stream from the document's storage can't be opened, so I didn't look for the notification until now. The change in DEV300m68 was the fix for issue 106854 (directly using the document's storage instead of opening it from its URL). mav: Is the missing notification for embedded objects intentional? We could then disable partial saving for embedded objects.
@nn: The problem is that during embedded object storing the model notifications regarding storing do not really make sense. It is more an implementation detail how the object transfer the contents from the model to the storage. Actually this approach ( no model-storing notification during embedded object storing ) and implementation is very old, so the fix for the showstopper should be done by adjusting the storing process in the calc. But I would not turn the partial saving off for embedded objects, it would be a hack. The correct solution looks to be turn the partial saving on only in case SFX_EVENT_SAVEASDOC, SFX_EVENT_SAVEADOC and may be ( if -DONE event is supported ) SFX_EVENT_SAVETODOC are sent. The events SFX_EVENT_SAVE...DOC are always sent before SFX_EVENT_SAVE...DOCDONE and also before the storing process. If you believe that such a notification on the model level is necessary for the embedded object, please submit a new enhancement. We could introduce new events for this then.
I made the change on CWS fwk140. Partial saving is done only if one of the SAVE events is sent before saving (including SAVETO - but then the positions aren't updated after saving). Embedded objects usually don't have several sheets, so the performance gain of partial saving isn't so important there. In all other cases, it still works as in 3.2.
reassigning...
Bug is not resolved. Downloaded OOO320m14 to verify. Embedded Spreadsheet OLE in a word doc created by Writer 3.1 does not appear in 3.2 Writer or the developer snapshot.
rcaron, you have to wait for a milestone where fwk140 is integrated, see http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=OOO320%2Ffwk140 Reassigning to QA for verification. Note: When you save the doc file again, you run into issue 110692. But that is fixed for 3.2.1, too.
Verified fix in CWS fwk140.
*** Issue 110922 has been marked as a duplicate of this issue. ***
Checked in OOO320m18 and DEV300m83.