Issue 108978 - WW8. exported OOo Spreadsheet disappears when re-imported in writer
Summary: WW8. exported OOo Spreadsheet disappears when re-imported in writer
Alias: None
Product: Writer
Classification: Application
Component: open-import (show other issues)
Version: OOo 3.2 RC5
Hardware: PC All
: P3 Trivial with 8 votes (vote)
Target Milestone: ---
Assignee: michael.ruess
QA Contact: issues@sw
Keywords: ms_interoperability, regression
: 109422 109568 109880 109972 110343 110375 110922 (view as issue list)
Depends on:
Blocks: 109046
  Show dependency tree
Reported: 2010-02-05 10:34 UTC by anderson_freitas
Modified: 2013-08-07 14:44 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

spreadsheet/worksheet disappears in writer (33.00 KB, application/msword)
2010-02-05 10:39 UTC, anderson_freitas
no flags Details
bugdoc created in OOo 3.2 (14.24 KB, application/vnd.oasis.opendocument.text)
2010-02-21 08:38 UTC, jbf.faure
no flags Details
bugdoc converted in doc by JFN (17.50 KB, application/msword)
2010-02-21 08:39 UTC, jbf.faure
no flags Details
bugdoc converted in doc by JBF (17.50 KB, application/msword)
2010-02-21 08:40 UTC, jbf.faure
no flags Details
odt file created from scratch by JBF in OOo 3.2 (12.59 KB, application/vnd.oasis.opendocument.text)
2010-02-21 09:33 UTC, jbf.faure
no flags Details
test_jbf.odt exported as MS-Word file by JBF (14.00 KB, application/msword)
2010-02-21 09:36 UTC, jbf.faure
no flags Details
JFN tests (47.64 KB, application/x-gzip)
2010-02-21 17:41 UTC, jbf.faure
no flags Details
Original and OOo saved versions of a '.doc' file with table there and gone. (16.25 KB, application/x-gzip)
2010-03-12 17:31 UTC, gerardr
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description anderson_freitas 2010-02-05 10:34:57 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.
Comment 1 anderson_freitas 2010-02-05 10:39:51 UTC
Created attachment 67643 [details]
spreadsheet/worksheet disappears in writer
Comment 2 michael.ruess 2010-02-05 10:54:26 UTC
MRU->HBRINKM: in the attached doc (exported by OOo) the Calc object will not be
imported anymore since OOo 3.2.
Comment 3 michael.ruess 2010-02-19 08:52:18 UTC
*** Issue 109422 has been marked as a duplicate of this issue. ***
Comment 4 jbf.faure 2010-02-20 18:53:36 UTC
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
Comment 5 jbf.faure 2010-02-20 19:03:54 UTC
Same problem in DEV300_m71.
Comment 6 jbf.faure 2010-02-21 08:38:34 UTC
Created attachment 67953 [details]
bugdoc created in OOo 3.2
Comment 7 jbf.faure 2010-02-21 08:39:27 UTC
Created attachment 67954 [details]
bugdoc converted in doc by JFN
Comment 8 jbf.faure 2010-02-21 08:40:07 UTC
Created attachment 67955 [details]
bugdoc converted in doc by JBF
Comment 9 jbf.faure 2010-02-21 09:16:54 UTC
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
Comment 10 jbf.faure 2010-02-21 09:32:21 UTC
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
Comment 11 jbf.faure 2010-02-21 09:33:41 UTC
Created attachment 67961 [details]
odt file created from scratch by JBF in OOo 3.2
Comment 12 jbf.faure 2010-02-21 09:36:07 UTC
Created attachment 67962 [details]
test_jbf.odt exported as MS-Word file by JBF
Comment 13 jbf.faure 2010-02-21 17:39:55 UTC
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
Comment 14 jbf.faure 2010-02-21 17:41:04 UTC
Created attachment 67967 [details]
JFN tests
Comment 15 michael.ruess 2010-02-24 15:05:46 UTC
*** Issue 109568 has been marked as a duplicate of this issue. ***
Comment 16 michael.ruess 2010-03-08 09:36:22 UTC
*** Issue 109880 has been marked as a duplicate of this issue. ***
Comment 17 michael.ruess 2010-03-09 14:39:21 UTC
*** Issue 109972 has been marked as a duplicate of this issue. ***
Comment 18 gerardr 2010-03-12 17:29:57 UTC
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
Comment 19 gerardr 2010-03-12 17:31:19 UTC
Created attachment 68312 [details]
Original and OOo saved versions of a '.doc' file with table there and gone.
Comment 20 jbf.faure 2010-03-23 19:27:45 UTC
Updated target milestone accordingly to release blocker status.
Comment 21 michael.ruess 2010-03-24 08:11:19 UTC
*** Issue 110343 has been marked as a duplicate of this issue. ***
Comment 22 michael.ruess 2010-03-25 08:28:58 UTC
*** Issue 110375 has been marked as a duplicate of this issue. ***
Comment 23 openoffice 2010-03-29 17:12:17 UTC
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 

@mru: Do you know in which milestone OOo can still read Test.doc correctly?
Comment 24 michael.ruess 2010-03-30 09:59:02 UTC
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.
Comment 25 anderson_freitas 2010-03-31 13:30:09 UTC

Create .doc in 2.x (probably)- this .doc is used for many years.

Work Fine in version 3.1.1 - OOO310m19 Build:9420)
Comment 26 Mathias_Bauer 2010-04-09 14:20:27 UTC
Tested Test.doc with OOo 3.2 (OOO320m4) on Windows: works fine
Comment 27 openoffice 2010-04-12 10:28:19 UTC
analysis: broke in DEV300_m68
Comment 28 openoffice 2010-04-12 13:37:01 UTC
Analysis: The OLE is converted on import and the writing of the temporary file fails with the following 

#0  sax_expatwrap::SAXWriter::endDocument (this=0x2a3e81a0) at 
#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 
#16 0x29449cd7 in SwWW8ImplReader::InsertOle (this=0x4160e00, rObject=@0x25aeb440, 
rFlySet=@0xbfffba24, rGrfSet=@0xbfffb8c0) at 
#17 0x293f4a63 in SwWW8ImplReader::ImportReplaceableDrawables (this=0x4160e00, 
rpObject=@0xbfffba40, rpOurNewObject=@0xbfffba3c, pRecord=0x2a439460, pF=0xbfffba54, 
rFlySet=@0xbfffba24) at 
#18 0x293f927c in SwWW8ImplReader::Read_GrafLayer (this=0x4160e00, nGrafAnchorCp=90) at 
#19 0x29407c09 in SwWW8ImplReader::ReadChar (this=0x4160e00, nPosCp=90, nCpOfs=0) at 
#20 0x29408579 in SwWW8ImplReader::ReadChars (this=0x4160e00, rPos=@0xbfffbd98, 
nNextAttr=91, nTextEnd=101, nCpOfs=0) at 
#21 0x2940d6cf in SwWW8ImplReader::ReadText (this=0x4160e00, nStartCp=0, nTextLen=101, 
#22 0x2941155b in SwWW8ImplReader::CoreLoad (this=0x4160e00, pGloss=0x0, 
rPos=@0x23b3332c) at 
#23 0x294128d4 in SwWW8ImplReader::LoadThroughDecryption (this=0x4160e00, 
rPaM=@0x23b33320, pGloss=0x0) at 
#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 
#26 0x213aa4bb in SwReader::Read (this=0x25a95e10, rOptions=@0x25ac8730) at 
#27 0x214c25cd in SwDocShell::ConvertFrom (this=0x25955ec0, rMedium=@0x25987060) at 
#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 ()
Comment 29 niklas.nebel 2010-04-12 16:46:38 UTC
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.
Comment 30 mikhail.voytenko 2010-04-13 11:36:22 UTC
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.
Comment 31 niklas.nebel 2010-04-13 14:33:37 UTC
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.
Comment 32 niklas.nebel 2010-04-13 14:37:22 UTC
Comment 33 rcaron 2010-04-13 15:50:55 UTC
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.
Comment 34 niklas.nebel 2010-04-14 12:37:26 UTC
rcaron, you have to wait for a milestone where fwk140 is integrated, see

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.
Comment 35 michael.ruess 2010-04-15 15:54:11 UTC
Verified fix in CWS fwk140.
Comment 36 michael.ruess 2010-04-16 08:07:37 UTC
*** Issue 110922 has been marked as a duplicate of this issue. ***
Comment 37 michael.ruess 2010-06-24 14:20:43 UTC
Checked in OOO320m18 and DEV300m83.