Bug 33613 - FILEOPEN: MSDraw OLE object not displaying (Word 2 .doc import)
Summary: FILEOPEN: MSDraw OLE object not displaying (Word 2 .doc import)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace
Depends on:
Blocks: DOC-Objects
  Show dependency treegraph
 
Reported: 2011-01-27 11:07 UTC by Jaxson Lee
Modified: 2024-05-29 03:14 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Word for Windows 2.0 .doc file containing an MSDRAW object (10.50 KB, application/msword)
2011-01-27 11:07 UTC, Jaxson Lee
Details
Word Document 7 .doc file containing an MSDRAW object (18.00 KB, application/msword)
2011-01-27 11:08 UTC, Jaxson Lee
Details
Word Document 8 .doc file containing an MSDRAW object (26.00 KB, application/msword)
2011-01-27 11:08 UTC, Jaxson Lee
Details
backtrace from Ubuntu 10.10 with Word Doc 95 (13.80 KB, text/plain)
2011-01-28 16:54 UTC, Jaxson Lee
Details
console + bt with symbols on master sources (8.92 KB, text/plain)
2013-06-08 13:52 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaxson Lee 2011-01-27 11:07:21 UTC
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.
Comment 1 Jaxson Lee 2011-01-27 11:08:10 UTC
Created attachment 42605 [details]
Word Document 7 .doc file containing an MSDRAW object
Comment 2 Jaxson Lee 2011-01-27 11:08:51 UTC
Created attachment 42606 [details]
Word Document 8 .doc file containing an MSDRAW object
Comment 3 Jaxson Lee 2011-01-28 16:53:57 UTC
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?
Comment 4 Jaxson Lee 2011-01-28 16:54:51 UTC
Created attachment 42679 [details]
backtrace from Ubuntu 10.10 with Word Doc 95
Comment 5 Björn Michaelsen 2011-12-23 11:50:29 UTC Comment hidden (obsolete)
Comment 6 sasha.libreoffice 2012-02-23 04:15:56 UTC
Document from first attachment even MS Word 2003 and 2007 can not open (another not tested)
Comment 7 Florian Reisinger 2012-08-14 14:02:39 UTC Comment hidden (obsolete)
Comment 8 Florian Reisinger 2012-08-14 14:03:35 UTC Comment hidden (obsolete)
Comment 9 Florian Reisinger 2012-08-14 14:08:10 UTC Comment hidden (obsolete)
Comment 10 Florian Reisinger 2012-08-14 14:10:15 UTC Comment hidden (obsolete)
Comment 11 Jaxson Lee 2012-08-15 19:20:27 UTC
This is still an issue in the 3.5.x releases. Exactly the same behaviour as detailed in the previous comments.
Comment 12 Andreas Lartz 2012-08-28 19:07:25 UTC
It is still the same behavior in 3.6. Exactly the same.
Comment 13 Florian Reisinger 2012-08-29 08:50:04 UTC
Setting status to NEW due to last comment...
Comment 14 Julien Nabet 2012-09-22 23:06:31 UTC
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.
Comment 15 Julien Nabet 2013-06-08 13:52:41 UTC
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.
Comment 16 Julien Nabet 2013-06-08 14:10:11 UTC
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)
Comment 17 bfoman (inactive) 2013-07-26 12:40:05 UTC
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.
Comment 18 Yuhong Bao 2013-09-04 23:49:00 UTC
"Document from first attachment even MS Word 2003 and 2007 can not open"
Use the FilesBeforeVersion reg key to unblock.
Comment 19 Julien Nabet 2013-10-19 23:26:56 UTC
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.
Comment 20 Jaxson Lee 2013-10-20 15:03:14 UTC
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.
Comment 21 Julien Nabet 2013-10-20 15:13:51 UTC
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.
Comment 22 Jaxson Lee 2013-10-20 17:18:48 UTC
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."
Comment 23 Julien Nabet 2013-10-23 20:35:45 UTC
Indeed, you're right Jaxson!
I put it back to NEW since i got no more questions.
Comment 24 QA Administrators 2015-04-19 03:21:20 UTC Comment hidden (obsolete)
Comment 25 Buovjaga 2015-06-16 09:50:20 UTC
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)
Comment 26 Julien Nabet 2015-06-16 18:57:55 UTC
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)
Comment 27 Julien Nabet 2015-06-16 19:05:45 UTC
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.
Comment 28 Roman Kuznetsov 2018-07-24 18:21:58 UTC
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?
Comment 29 QA Administrators 2019-07-30 03:14:54 UTC Comment hidden (obsolete)
Comment 30 QA Administrators 2021-07-30 06:22:17 UTC Comment hidden (obsolete)
Comment 31 Jan Švanda 2022-05-29 03:56:44 UTC
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.
Comment 32 QA Administrators 2024-05-29 03:14:50 UTC
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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug