Created attachment 65418 [details] Example MSO 2007 document containing formulae How to reproduce: - Import DOCX document from attachment - Both formulae are editable - Save document as ODT - Reload ODT in LO Expected result: - Both formulae are editable Actual result: - Only first formula is editable as formula - The frame edit dialog appears when trying to edit the second formula Settings under Options - Load/Save - Microsoft Office: MathType to LibreOffice Math or reverse: "Load and convert the object" and "Convert and save the object" are both checked. The problem is actually worse with the original unstripped DOCX document. There all formulae are replaced in the re-opened ODT with a square showing a "Object ##" text. Problem observed in: Libreoffice 3.5.4 on openSuSE 11.4 (64-bit) Libreoffice-master version 3.7.0.0.alpha0+ (Build ID: 769e2b5) on openSuSE 11.4 (32-bit) Libreoffice version 3.6.0.4 (Build ID: 360m1(Build:104)) on openSuSE 11.4 (32-bit) My full debug master build produces these lines during the export to ODT warn:legacy.osl:9892:1:/home/stephan/Software/libreoffice-master/core/starmath/source/mathmlexport.cxx:1485: Warning: failed to export a node? warn:legacy.osl:9892:1:/home/stephan/Software/libreoffice-master/core/unotools/source/config/configmgr.cxx:208: OSL_ASSERT: items_.empty() And on the reloading of the ODT warn:legacy.osl:10126:1:/home/stephan/Software/libreoffice-master/core/comphelper/source/container/embeddedobjectcontainer.cxx:419: A freshly create object should be running always!
Tried it in Portable LibreOffice 3.5.5.3 Build ID: 7122e39-92ed229-498d286-15e43b4-d70da21 on Windows XP without MS Office installed: The original unstripped DOCX document has the same problem: All formulae are replaced in the re-opened ODT with a square showing a "Object ##" text. So we can rule out a Linux specific problem with embedded objects.
It is NOT a Linux specific problem because I have the same problem on Windows 7 x64 with LO 3.6.0.4
Created attachment 66023 [details] 3 formula tests, 1-ok; 2-wrong view, cant edit; 3-some total fail Resave this docx to odt and check 2nd and 3d formula
My test on OpenSuSE 11.4 (x86) with LO version 3.6.0.4 (Build ID: 360m1(Build:104)): Imported attachment 66023 [details], then saved as odt. Result after re-opening the odt: first formula: can edit, is displayed OK second formula: cannot edit, is displayed with different font third formula: just a frame with red text "Object 6" inside, cannot edit. Same problem as my unstripped docx. Good catch, Sergey!
Confirmed in LO 3.6.1.2 (Windows 7, 32 bit) The situation is the same as described in previous comment.
On Mac OS X 10.7 with LibreOffice 3.6.2.1 (Build ID: ba822cc), this problem manifests itself in the following ways: 1) The .docx formulae, as initially imported, are "squished" horizontally, as shown in the attached screenshot. 2) Double-clicking on each of these formula boxes *appears* to fix the problem, but the behavior after a re-save is inconsistent, i.e.: * when re-saved as .docx the formulae are still squished horizontally. * when re-saved as .odt, some documents look fine (with the exception of certain characters being replaced by boxes or upside-down question marks), others are corrupted when the .odt file is reloaded, being replaced by a generic red object icon (shown in my second screenshot).
Created attachment 67567 [details] Screenshot showing the "squished" formula in imported .docx
Created attachment 67568 [details] Screenshot showing corrupted formulae after saving .docx to .odt and re-opening
@Kevin Ernst: Your squished formula in attachment 67657 looks like my second formula in comment 4. Your corrupted fomulae in attachment 67658 look like my third formula in comment 4. The upside-down question marks could be related to issue 53358. Could you check that and confirm in a comment with that bug? Thanks in advance.
In other words, my comment/screenshots add nothing of value to the bug report (except to confirm the bug exists on Mac OS X as well, FWIW). Point taken. I'm still learning. The problem with replaced characters (upside-down red question marks) is very closely related to your bug 53358, and the recommended fix would be the same. Apparently "{gt}" is legal in Word (renders as a literal string "gt"), but it's interpreted as "{<?>} gt {<?>}" in LibreOffice with an error, hence the red upside-down question mark. I suppose I'll tack the problem with "{gt}" onto #53358, as it's undoubtedly in the same neighborhood, source code-wise, at least.
@Kevin Ernst My comments should not be taken as criticism of your screenshots. Your screenshots are definitely of value, as they make the issue clearer to others. I'll discuss your {gt} problem with LO-devs and see what they thinks: Is it related enough to the "*" problem?
problem persists even in master. Could be that we fail to convert the latter OLE objects to native math objects - as you say. Lubos - did you have any ideas / code-pointers there ? :-)
Created attachment 69192 [details] File's archive (In reply to comment #12) > problem persists even in master. Could be that we fail to convert the latter > OLE objects to native math objects - as you say. > > Lubos - did you have any ideas / code-pointers there ? -- LibO_3.6.x;3.7.0_Win_x86 loses not only the formula, but the OLE-xls, OLE-ppt also – see the attachment. That is, the problem occurs if: 1. DOC file created in Microsoft Office 2003 that contains embedded objects (such as .xls, .ppt, formulas). 2. The DOC file is opened in Microsoft Office 2007/2010 and saved as a DOCX file. 3. Embedded objects are stored in formats that are native to MSO_2003. LibO_3.6.x;3.7.0_Win_x86 opens a DOCX file. -- Sorry amateur opine. There is a bug in the LibO_3.5.x. Import DOCX-file containing formulas Microsoft Office 2003, will start The Equation Editor (EQNEDT32.EXE) in the background. This error appeared after fixing bug 46716. It seems that the ability to access libraries of Microsoft’s external programs has been disabled in the LibO_3.6.x. Therefore, the some regressions were born at the same time: this and the bug 55437, bug 53070, etc (this message). The history of this error may see in bug 46716. Reference point – summer 2012, when worked on LibO_3.5.5(.4-?).
Sorry. (In reply to comment #12) > problem persists even in master. Could be that we fail to convert the latter > OLE objects to native math objects - as you say. > > Lubos - did you have any ideas / code-pointers there ? :-) Sorry, I have not seen yet the latest version ‘LibO-dev_3.6.4.0+’ when I wrote the previous post. Importing DOCX files containing Microsoft Office 2003 objects, works correctly in the ‘LibO-Dev_3.6.4.0_Win_x86 (Build ID: 2f42a6c; Time stamp: 2012-10-27_20.59.07)’.
Already [Reproducible] with "LibreOffice 3.5.7.2 rc German UI/Locale [Build-ID: 3215f89-f603614-ab984f2-7348103-1225a5b] on German WIN7 Home Premium (64bit). In original document opened with LibO formulas can be edited quite normal, and that also will be possible after having saved document as .doc (or as .docx under new name), but when having been saved as .odt the formuas no longer can be edited, also not with other LibO versions or AOOo. So it's a FILESAVE problem After FILESAVE as .odt the third formula will appear with an "Object 6" placeholder when document will be reopened, problem might be related or something completely new. LibO 3.4.5 and LibO 3.3.3 did not show formulas at all. The problem does not appear with an own.odt with simple formula "A = b over c", saved from LibO 3.6.3 as .docx (MSO2007), reopened with LibO and saved as .odt @all: Please do not hijack this report for other problems having to do "somehow" with LibO, docx, formula, but report separate bug reports. If oyu believe that the problem might be related to this one please mention this bug in a comment.
I will obsolete all attachments not necessary to reproduce this bug. Please submit new bug reports for all problems not exactly the same as this one, cited the obsolete attachments as described here <https://wiki.documentfoundation.org/QA-FAQ#How_to_use_attached_sample_documents_for_multiple_Bug_Reports> and add me to CC of those new bugs. @Michael: What do you think, who is active in these docx object issues? Miklós?
Comment on attachment 65418 [details] Example MSO 2007 document containing formulae Attachment is not required to reproduce the problem
Comment on attachment 67567 [details] Screenshot showing the "squished" formula in imported .docx different problem, attachment is not required to reproduce the original problem
Comment on attachment 67568 [details] Screenshot showing corrupted formulae after saving .docx to .odt and re-opening different problem, attachment is not required to reproduce the original problem
Comment on attachment 69192 [details] File's archive Attachment is for different problem, not required to reproduce the original problem I should have mentioned: still [Reproducible] with parallel installation of Master "LOdev 4.0.0.0.alpha0+ - ENGLISH UI / German Locale [Build ID: a2b3ee)]" {tinderbox: @6, pull time 2012-11-13 06:07:28} on German WIN7 Home Premium (64bit) with separate /4 User Profile for Master Branch
Problem still present in - LOdev 4.0.0.0.beta2 (Build-id: 4104d660979c57e1160b5135634f732918460a0) On Windows XP-SP3 - LO-Master Version 4.1.0.0.alpha0+ (Build ID: 07c80d23fadcc2334fe7c6f9ce7b5dafeb88d62) on openSUSE 12.2 (32-bit)
Hi, Maybe this can give a hint: I reproduce, but if I move the formulas to get a reverse order (test 3, test 2, test 1) before saving => all formulas are now editable after reopening. Checked on the test file (3 formula tests, 1-ok ...)and my own documents, with 3 versions of LibreOffice: - LibreOffice 3.5.7.2 Version ID : 3215f89-f603614-ab984f2-7348103-1225a5b - Version 3.6.5.2 (Build ID: 5b93205) - Version 4.0.1.0+ (Build ID: 0dadaa4521629aab3e1c16413541efb9b62d095) Vista
Test 2-formula is still not editable when saving to ODT. Because we need to clear MAB3.5 list I move this bug to the MAB3.6 list. ODT is 'our' own file format, so this belongs on the MAB list. Kind regards, Joren
Tested in MASTER: Version: 4.2.0.0.alpha0+ Build ID: c2530b02311c46529eed53ee688bf6c83ce4b86 on Ubuntu 12.04 (32-bit) Problem somehow seems to be solved!
Tested on openSuSE 12.2 (32-bit) with: Versie 4.0:build-303 -3 (Bouw-id: 400m0(Build:303)) Problem also seems to be solved in this version.
(In reply to comment #25) > Tested on openSuSE 12.2 (32-bit) with: > > Versie 4.0:build-303 -3 (Bouw-id: 400m0(Build:303)) > > Problem also seems to be solved in this version. Superb! Lets mark it as such then. I see you tested on 2 independent systems. Thanks for retesting and feedback! This one is confirmed many times, so this one is definately fixed inside the code (although we don't know how). Therefore I'll mark it as RESOLVED FIXED. Kind regards, Joren
Tested on SLED11-SP2 (32-bit) with: Version 3.6 build 515 (Build ID 360m1 (Build 515)) Problem is still present in this version.
(In reply to comment #27) > Tested on SLED11-SP2 (32-bit) with: > > Version 3.6 build 515 (Build ID 360m1 (Build 515)) > > Problem is still present in this version. Okay, Thanks! So, still present in 3.6 branch. But I don't think developers will backport the fix :-), so lets keep this one RESOLVED FIXED and just upgrade to LibreOffice 4.x or later? I hope that's okay for you :)? Kind regards, Joren
Ok for me. Lesson to be learned here: Never pay for "Enterprise" software ;-)
Hi Stephan, > Lesson to be learned here: Never pay for "Enterprise" software ;-) I'm not following this bug; but you should take up the issue with your enterprise software vendor - if you're paying for support you should have a means to report (and have fixed) L3 bugs - such as this one no doubt. If you're using SUSE/SLED - that would be calling NTS - I guess, and you'll get an update to SUSE/LibreOffice 4.0 (shortly) which may help here; not sure. Kendy may have more thoughts, HTH, Michael.