Created attachment 42604 [details] Word for Windows 2.0 .doc file containing an MSDRAW object I've attached three files both of which contain the same MSDRAW Microsoft Drawing embedded as an object. The first file (diagram_word2.doc) is a Word for Windows 2.0 .doc file. Opening this in Writer results in the object being substituted by the string "µ §". There is no bitmap representation of the drawing. The second file (diagram_word95.doc) was created by opening the previous one in Word 95, and saving it in the native file format, so it's a Word 95 (Word Document 7) .doc file. Opening this in Writer, and the document displays as expected - there's a bitmap representation of the drawing displayed. However double-clicking on the object results in a .tmp file being opened in Writer which contains 52 pages of 'Gobbledygook' text (presumably a plaintext representation of the object). From a usability point of view, this isn't the behaviour the user will be expecting. The third file (diagram_word97.doc) was created by opening the first one in Word 97, and saving it in the native file format, so it's a Word 97-2003 (Word Document 8) .doc file. Opening this file in Writer also results in a bitmap equivalent of the drawing being correctly rendered. Double-clicking on the object brings up the image properties box, which seems appropriate. What I'd expect to happen is for the object to be handled in the same way if it's contained in a Winword 2.0 or Word 95 file as it is in the Word 97-2003 file. Obviously, the total loss of the image in the first file is probably of higher importance than the slightly dodgy user experience presented in the Word95 file.
Created attachment 42605 [details] Word Document 7 .doc file containing an MSDRAW object
Created attachment 42606 [details] Word Document 8 .doc file containing an MSDRAW object
Just tried the Word7 (95) document on Ubuntu 10.10 x86 LibreOffice 3.3.0 OOO330m19 (Build:6) - double-clicking the object in the file caused Writer to crash. I've attached what I believe to be the backtrace, if that's any use?
Created attachment 42679 [details] backtrace from Ubuntu 10.10 with Word Doc 95
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Document from first attachment even MS Word 2003 and 2007 can not open (another not tested)
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
This is still an issue in the 3.5.x releases. Exactly the same behaviour as detailed in the previous comments.
It is still the same behavior in 3.6. Exactly the same.
Setting status to NEW due to last comment...
On pc Debian x86-64 with master sources updated today, I reproduced the problem. Now "Word 2" isn't proposed at all on the list of supported files (with 3.5.4.2 Debian package I installed too binfilters) So I would say, there's only the Word 95 file issue.
Created attachment 80529 [details] console + bt with symbols on master sources On pc Debian x86-64 with master sources updated today, I can still reproduce the problem with Win95 file.
Fridrich: by looking at the last bt, I noticed this: libmwaw_internal::findCentralDirectoryEnd 259 static bool findCentralDirectoryEnd(WPXInputStream *input) 260 { 261 input->seek(0, WPX_SEEK_SET); 262 try { 263 while (!input->atEOS()) 264 input->seek(1024, WPX_SEEK_CUR); 265 input->seek(-1024, WPX_SEEK_CUR); 266 while (!input->atEOS()) { 267 unsigned signature = getInt(input); 268 if (signature == CDIR_END_SIG) { 269 input->seek(-4, WPX_SEEK_CUR); 270 return true; 271 } else 272 input->seek(-3, WPX_SEEK_CUR); 273 } 274 } catch (...) { 275 return false; 276 } and the function int WPXSvInputStreamImpl::seek(long offset, WPX_SEEK_TYPE seekType) from writerperfect/source/common/WPXSvStream.cxx which returns -1 when there's a problem. Should findCentralDirectoryEnd take into account -1? Should WPXSvInputStreamImpl::seek throw exceptions? Other ideas? Remark: I also noticed a "findCentralDirectoryEnd" method in shell/source/win32/zipfile/zipfile.cxx (see http://opengrok.libreoffice.org/xref/core/shell/source/win32/zipfile/zipfile.cxx#253)
Checked with: LO 4.2.0.0.alfa0 Build ID: 2013-06-24 own debug build Windows 7 Professional SP1 64 bit (In reply to comment #0) > The first file (diagram_word2.doc) is a Word for Windows 2.0 .doc file. > Opening this in Writer results in the object being substituted by the string > "µ §". There is no bitmap representation of the drawing. No bitmap, just ﾵ ﾧ string. Works perfectly in Word 2010. > The second file (diagram_word95.doc) [...] > Document 7) .doc file. Opening this in Writer, and the document displays as > expected - there's a bitmap representation of the drawing displayed. However > double-clicking on the object results in a .tmp file being opened in Writer > which contains 52 pages of 'Gobbledygook' text Could not reproduce. Double-clicking on the object brings nothing most times, but if you continue then it brings up the frame properties box. > (Word Document 8) .doc file. Opening this file in Writer also results in a > bitmap equivalent of the drawing being correctly rendered. Double-clicking > on the object brings up the image properties box, which seems appropriate. Same result.
"Document from first attachment even MS Word 2003 and 2007 can not open" Use the FilesBeforeVersion reg key to unblock.
Miklos: Version Word 95 and Word 97 of Msdraw objects open ok (with LO master and 4.1 sources updated today), not Word 2. Do we still support Word 2? If no, it seems we might close this tracker.
At the time I posted this bug, there was an appeal for pre-95 format word docs to try and improve compatibility. If we don't support pre-95 documents, then I think we should make it clear when a document in this format is opened (with a message box along the lines of "This document is saved in an unsupported version of the DOC file format and may not appear as intended"). However seeing as the project makes a feature out of supporting all versions of VSD file formats, my personal feeling is that we should do likewise with the DOC file format.
Jaxson: about the vsd file, could you give me sources about the fact LO tries to support all VSD file formats versions? I read Visio 1 was in 1992 but Microsoft bought the soft in 2000. (see http://en.wikipedia.org/wiki/Microsoft_Visio) In comparison, Word 2 has been released in 1991. I'm not sure LO should support these old formats but I agree it should show a warning if it detects these.
Sure, from https://www.libreoffice.org/download/4-0-new-features-and-fixes/ : "LibreOffice 4.0.0 supports all existing Visio file formats from Visio 1.0 released in 1992 to Microsoft Visio 2013 released in 2012."
Indeed, you're right Jaxson! I put it back to NEW since i got no more questions.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
attachment 42604 [details] shows absolutely nothing. attachment 42605 [details] is ok, double-clicking image doesn't do anything. attachment 42606 [details] is ok, double-clicking image brings up properties. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 80ec99db4325a439a8a3f1d420d0a80f8bf9c439 TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-16_00:00:20 Locale: fi-FI (fi_FI)
About the first attachment where no graphic appears, I noticed this on console: warn:legacy.osl:3151:1:sw/source/filter/ww8/ww8par.cxx:3615: WW8: Please report this document, it may have a missing graphic (pc Debian x86-64 with master sources updated yesterday)
Just quick part of gdb session: Breakpoint 1, SwWW8ImplReader::ReadChar (this=0x2bb5450, nPosCp=32, nCpOfs=0) at /home/julien/compile-libreoffice/libreoffice/sw/source/filter/ww8/ww8par.cxx:3583 3583 bool bReadObj = IsInlineEscherHack(); (gdb) s SwWW8ImplReader::IsInlineEscherHack (this=0x2bb5450) at /home/julien/compile-libreoffice/libreoffice/sw/source/filter/ww8/ww8par.hxx:1681 1681 { return !m_aFieldStack.empty() && m_aFieldStack.back().mnFieldId == 95; }; (gdb) p m_aFieldStack.empty() $1 = false (gdb) p m_aFieldStack $2 = std::__debug::deque with 1 elements = {{msBookmarkName = "", msMarkType = "", msMarkCode = "", maParams = std::__debug::map with 0 elements, maStartPos = {maPtNode = SwNodeIndex (node 10), mnPtContent = 0}, mnFieldId = 58, mnObjLocFc = 0}} (gdb) n Just for the record, but I suppose it could be expected, forcing bReadObj to true doesn't help to show graphic of the first attachment. Hope it helps a bit.
still repro in Version: 6.1.0.2 (x64) Build ID: b3972dcf1284967612d5ee04fea9d15bcf0cc106 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: ru-RU (ru_RU); Calc: CL but, we really want to have full support for format "Word for windows 2.0" today?
Dear Jaxson Lee, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Jaxson Lee, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still repro in: Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community Build ID: bbec710bd25fc5da27636cde73fe4ab23c76904f CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: cs-CZ (cs_CZ); UI: en-US Calc: CL First version (Word for Windows 2) shows nothing. Second version (Word Document 7) shows image, double clicking it results in error box with following text: "Error activating object: General OLE error." Third version (Word Document 8) shows image, double clicking bring up properties.