When loading a docx file, Writer will not load an Equation created in MS Word, and any text after it.
This is a regression. This didn't happen in LO 3.3.2. In Writer 3.3.2 the document is fully loaded and the Equation is displayed and opened in MS Equation Editor for editing.
Just for the record it didn't happen in OOo Writer 3.3 either. But OOo 3.4 Beta loads the whole text and just ignores the Equation.
Please attach a sample document!
Created attachment 46469 [details]
docx sample file with text and equation on the second page
I did add the attachment when I submitted the bug report... Apparently it wasn't uploaded...
*** This bug has been marked as a duplicate of bug 36496 ***
huh, seems I marked this as a duplicate of the wrong bug ;-(
But.. I was able to reproduce this on windows but not on linux ( although my linux build is the latest build of the 3.4 branch ) I need to install the official 3.4 to check if this is really fixed in later builds or just a windows only bug
seems this really is windows specific ( which seems weird ) tor, could you have a look please
I opened the document in LibreOffice 3.3.2 under Ubuntu 10.04 and the equation does show up. Double clicking the equation opens it in LO Math. But clicking on the equation crashes LO every time.
It seems my results confirm Noel's suspect, problem is [Reproducible] with reporter's sample document and "LibreOffice 3.4Beta5 – WIN7 Home Premium (64bit) English UI [DEV300m103 (Build:5)]", equation and following text are not shown.
MS WORD Viewer shows equation and following text.
Can't test with my own documents, it seems LibO does not export Math objects from Writer to docx (math formula invisible when reopen in LibO and also in MS WORD Viewer, but text behind missing formula object visible).
I modified Status to Assigned due to facts.
Since this is a regression from 3.3.2 and it prevents loading of documents, shouldn't it be considered a blocker and get higher importance?
May be you should ask for an answer before you modify the fields?
I doubt that this one is a blocker due to the definitions
<http://wiki.documentfoundation.org/Release_Criteria#Blocker_Bug_Nomination>, other docx problems mostly are classified with importance "medium / normal", so it will be difficult to substantiate a "blocker":
Comparing this issue with all other 100000 things on the to do list i can't see more importance for this one than "medium / normal". Please keep in mind that an other "critical" fix would have to be shifted to 3.4.1 in favor of this one, can you decide which one it will be?
You are right about the version. Sorry.
My point is that this is a REGRESSION and causes DATA LOSS. But you are correct that it only applies to docx. Are all the docx problems the same degree of importance?
In 3.4rc1 I get a crash, even, when opening the sample document from comment #2.
This bug is fixed in MinGW build 93e3a869-b211287-090bcba-45cf606 but not in the MSVC build 130028f-b211287-090bcba-45cf606-05891e7.
Does this information help?
*** Bug 43429 has been marked as a duplicate of this bug. ***
Hint: Bug 43429 "Opening of docx-file with mathematical formulas crashed writer. (Sample provided)" is a duplicate of this bug, I think, but the additional comments to Bug 43429 contain some information which may be helpful for fixing this bug ...
Under some circumstances (not sure, when) Writer just ignores the contents of the DOCX file after (and including) the first formula, under other circumstances Writer crashes opening the DOCX file. Not sure what makes the difference. Both phenomena happen on Windows only, of course.
*** Bug 44289 has been marked as a duplicate of this bug. ***
could be considered more important ?
Hmm medium/high is for the dev to set, IIRC, so could be blocker in stead of major .. ?)
I can confirm, but I have no idea how to debug a windows-only problem.
Lubos - it is rather hard; is the import valgrind clean ?
It is valgrind-clean.
I increase the priority and severity because it causes data loos. See also the bug 46716.
This is the stack trace I get:
00 00e3b900 00e3b8dc 1450d122 ooxmllo!boost::detail::sp_counted_base::add_ref_copy+0x12
01 0f836dc4 87a1cce9 00e3b8fc ooxmllo!boost::detail::shared_count::shared_count+0x23
02 0f836dc0 87a1cd2d 0f838858 ooxmllo!boost::shared_ptr<writerfilter::ooxml::OOXMLProperty>::shared_ptr<writerfilter::ooxml::OOXMLProperty>+0x42
03 00e3b940 87a1cd61 0f835388 ooxmllo!writerfilter::ooxml::OOXMLPropertySetImpl::resolve+0x61
04 0016014b 0f7ef2c8 0016014b ooxmllo!writerfilter::ooxml::OOXMLFastContextHandlerProperties::handleOLE+0x75
05 091905a8 87a1cdad 0f7ef2c8 ooxmllo!writerfilter::ooxml::OOXMLFactory_vml_officeDrawing::endAction+0x46
06 091905a8 0007010f 87a1cdf9 ooxmllo!writerfilter::ooxml::OOXMLFactory::endAction+0x72
07 0007010f 091905a8 00e3ba0c ooxmllo!writerfilter::ooxml::OOXMLFastContextHandler::lcl_endAction+0x5b
08 0007010f 87a1ce39 0f8388e8 ooxmllo!writerfilter::ooxml::OOXMLFastContextHandler::endAction+0x1b
09 0007010f 00e3ba6c 0f3962d3 ooxmllo!writerfilter::ooxml::OOXMLFastContextHandlerProperties::lcl_endFastElement+0x34
0a 091905bc 0007010f 87ad165f ooxmllo!writerfilter::ooxml::OOXMLFastContextHandler::endFastElement+0x18
0b 0f806638 0f5b9a28 00e3bb44 fastsax_uno!sax_fastparser::FastSaxParser::callbackEndElement+0x103
0c 0f5b9a28 0f806638 00000001 fastsax_uno!call_callbackEndElement+0x16
0d 0f77f2c8 00000000 0f3c9cf0 fastsax_uno!doContent+0x842
0e 0f77f2c8 0f80ca51 0f810a18 fastsax_uno!contentProcessor+0x38
0f 0f77f2c8 0f3c9cf0 0f80ca51 fastsax_uno!doProlog+0x7e2
10 0f77f2c8 0f80ca18 0f810a18 fastsax_uno!prologProcessor+0x6f
11 0f77f2c8 0f80ca18 0f810a18 fastsax_uno!prologInitProcessor+0x40
12 0f77f2c8 00004000 00000000 fastsax_uno!XML_ParseBuffer+0xc8
13 0f77f2c8 0f620010 00004000 fastsax_uno!XML_Parse+0x1c2
14 87ad1367 00e3f8e0 00000000 fastsax_uno!sax_fastparser::FastSaxParser::parse+0xbf
15 0f5b9a3c 00e3bfcc 87a1cbc1 fastsax_uno!sax_fastparser::FastSaxParser::parseStream+0x3eb
16 0f7d3f84 87bf5cbd 00e3f8e0 ooxmllo!writerfilter::ooxml::OOXMLDocumentImpl::resolve+0x293
17 0f5d3f8c 00e3c49c 93842a8b writerfilterlo!WriterFilter::filter+0x7eb
18 0f777348 00000000 938429bf sfxlo!SfxObjectShell::ImportFrom+0x923
19 0f777348 9384272b 03f98548 sfxlo!SfxObjectShell::DoLoad+0xc6c
1a 08c7c350 00e3cab4 938425f3 sfxlo!SfxBaseModel::load+0x29f
1b 0ee96a00 00e3cccc 00e3ccc8 sfxlo!SfxFrameLoader_Impl::load+0x6ec
1c 93f3054b 0ed300d0 0ed300c8 fwklo!framework::LoadEnv::impl_loadContent+0xa52
1d 93f306a7 00e3f8e0 00000000 fwklo!framework::LoadEnv::startLoading+0xfe
1e 00e3cf58 00e3cf88 00e3e158 fwklo!framework::LoadDispatcher::impl_dispatch+0x2f3
1f 0ed30094 00e3cf58 00e3cf88 fwklo!framework::LoadDispatcher::dispatchWithReturnValue+0x5f
20 00e3d348 00e3e174 00e3d34c comphelpMSC!comphelper::SynchronousDispatch::dispatch+0x27a
21 00e3e2c0 00e3e1b8 016c1052 sfxlo!SfxApplication::OpenDocExec_Impl+0x2e97
22 072ddc48 00e3e2c0 072ddc48 sfxlo!SfxStubSfxApplicationOpenDocExec_Impl+0xf
23 016dae70 00e3e2c0 93840c2f sfxlo!SfxShell::CallExec+0x12
24 072ddc48 01ae6f4c 00e3e2c0 sfxlo!SfxDispatcher::Call_Impl+0x327
25 072ddc48 01ae6f4c 00e3e2c0 sfxlo!SfxDispatcher::_Execute+0x17b
26 0000157d 00000001 00000000 sfxlo!SfxDispatcher::Execute+0x11f
27 0000157d 00000001 0f77c768 sfxlo!SfxDispatcher::Execute+0x1f
This bug seems to be fixed by
It has been approved and pushed for other branches as well:
branch libreoffice-3-5 to be used in LO-3.5.2
branch libreoffice-3-4 to be used in LO-.3.4.6:
branch libreoffice-3-4-6 to be used in LO-3.4.6-rc2: