Download it now!
Bug 42112 - EMF+ Fileopen: Embedded grouped diagram from particular DOC still doesn't preview arrows correctly (diagram opens fine if extracted from MSO)
Summary: EMF+ Fileopen: Embedded grouped diagram from particular DOC still doesn't pre...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
3.4.3 release
Hardware: All All
: medium normal
Assignee: Bartosz
URL:
Whiteboard: target:6.5.0 target:6.3.4 target:6.4.0.1
Keywords: preBibisect, regression
Depends on:
Blocks: EMF-WMF DOC-Shapes
  Show dependency treegraph
 
Reported: 2011-10-22 07:25 UTC by Rpnpif
Modified: 2019-11-21 14:29 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
The doc file to test (73.00 KB, application/msword)
2011-10-22 07:27 UTC, Rpnpif
Details
The odt file after converting (32.03 KB, application/vnd.oasis.opendocument.text)
2011-10-22 07:28 UTC, Rpnpif
Details
The pdf file after converting (67.08 KB, application/pdf)
2011-10-22 07:29 UTC, Rpnpif
Details
screenshot of OpenOffice (13.96 KB, image/png)
2011-10-29 09:57 UTC, Rpnpif
Details
screenshot of LO (9.58 KB, image/png)
2011-10-29 09:57 UTC, Rpnpif
Details
The doc file to test - screenshot preview in LO 3.5.7.2 and 3.6.0.4 (64.40 KB, image/jpeg)
2015-02-23 09:53 UTC, Timur
Details
Embedded DOC from "The doc file to test" saved in MSO (29.00 KB, application/vnd.ms-word)
2017-08-25 18:01 UTC, Timur
Details
The doc file to test - screenshot preview in MSO and LO 6.0.6 (90.81 KB, image/jpeg)
2018-08-27 07:54 UTC, Timur
Details
WMF file with issue (33.82 KB, image/wmf)
2019-11-10 10:30 UTC, Chris Sherlock
Details
SAL_LOG set to +INFO.drawinglayer (228.69 KB, text/plain)
2019-11-10 11:34 UTC, Chris Sherlock
Details
Arrow rotation issue (280.62 KB, image/png)
2019-11-18 17:26 UTC, Chris Sherlock
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rpnpif 2011-10-22 07:25:38 UTC
(All Linux, probably same with MS Windows). All releases of LO.

1. Load the Doc-et-graphique.doc (see attachment) in LO (all releases).
   The graphic draw is partially invisible.
2. Save as Doc-et-graphique.odt.
3. Reload Doc-et-graphique.odt. The graphic draw is still partially invisible.
4. Load Doc-et-graphique.doc in OpenOffice 3.2.1 or 3.3. All is fine. Graphic draw is full visible.
5. Load Doc-et-graphique.odt, created by LO, in OpenOffice. All is still fine.
6. With LO, export Doc-et-graphique.pdf. Graphic draw is wrong with same lacks (in Evince).
Comment 1 Rpnpif 2011-10-22 07:27:17 UTC
Created attachment 52631 [details]
The doc file to test
Comment 2 Rpnpif 2011-10-22 07:28:19 UTC
Created attachment 52632 [details]
The odt file after converting
Comment 3 Rpnpif 2011-10-22 07:29:51 UTC
Created attachment 52633 [details]
The pdf file after converting

This issue is important for usability of LO.
Comment 4 Rpnpif 2011-10-29 09:57:17 UTC Comment hidden (obsolete)
Comment 5 Rpnpif 2011-10-29 09:57:57 UTC
Created attachment 52895 [details]
screenshot of LO
Comment 6 Rpnpif 2011-10-29 09:58:52 UTC
Same issue with LO 3.4.4-RC1
Comment 7 Cor Nouws 2011-10-31 04:40:05 UTC Comment hidden (no-value)
Comment 8 A (Andy) 2013-01-20 12:59:05 UTC Comment hidden (obsolete)
Comment 9 Urmas 2013-02-19 18:25:07 UTC Comment hidden (no-value)
Comment 10 Rpnpif 2013-03-24 18:35:19 UTC Comment hidden (no-value)
Comment 11 Rpnpif 2014-06-21 09:35:06 UTC Comment hidden (obsolete)
Comment 12 Rpnpif 2014-09-01 04:55:24 UTC Comment hidden (obsolete)
Comment 13 Timur 2014-12-09 16:35:38 UTC
(In reply to Rpnpif from comment #6)
> Same issue with LO 3.4.4-RC1

Reproduced in Windows, but not with that version. Testing in Win 7 x64:
- Document opens fine in OO and in LO 3.4 and also fine in 3.5.
- Starting from 3.6.0 up to now (4.3.4 and 4.4.0 beta) preview is wrong and  shapes are not visible.

So it's not "regression against OO" and I delete that from the title, but Regression keyword remains. MS Word says "Microsoft Word Picture" for this object, so I change that in title also.

Double click on object opens it fine but in another Writer window. There, it can be edited, but it can't be closed and have object updated in the original Writer document, as it should and as Word does. This should be another bug, if not already reported.
Comment 14 Rpnpif 2014-12-10 10:53:38 UTC Comment hidden (obsolete)
Comment 15 retired 2015-01-05 20:28:05 UTC
Arrows and thin line still missing.
OS X 10.10.1 LO 4.5 Version: 4.5.0.0.alpha0+
Build ID: 2d59c0c940ac61240992502256c966b2cb4f9daa
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-01-04_01:16:22
Locale: de_
Comment 16 Jean-Baptiste Faure 2015-02-21 22:27:49 UTC
(In reply to Timur from comment #13)
> [...]
> Double click on object opens it fine but in another Writer window. There, it
> can be edited, but it can't be closed and have object updated in the
> original Writer document, as it should and as Word does. This should be
> another bug, if not already reported.

You can then copy&paste the graphics from a Writer window to the other. Then saving, closing, reopening works fine.

Tested with LibreOffice 4.4.2.0.0+ built at home under Ubuntu 14.10 x86-64.

Best regards. JBF
Comment 17 Timur 2015-02-23 09:53:12 UTC
Created attachment 113618 [details]
The doc file to test - screenshot preview in LO 3.5.7.2 and 3.6.0.4
Comment 18 Timur 2015-02-23 10:00:09 UTC Comment hidden (obsolete)
Comment 19 Rpnpif 2015-02-23 18:27:43 UTC Comment hidden (no-value)
Comment 20 Rpnpif 2015-09-04 15:59:01 UTC Comment hidden (obsolete)
Comment 21 Robinson Tryon (qubit) 2015-12-14 05:40:06 UTC Comment hidden (obsolete)
Comment 22 Rpnpif 2015-12-27 11:28:38 UTC Comment hidden (obsolete)
Comment 23 Jean-Baptiste Faure 2016-04-15 04:38:48 UTC Comment hidden (obsolete)
Comment 24 Rpnpif 2016-04-15 08:36:32 UTC Comment hidden (obsolete)
Comment 25 Jean-Baptiste Faure 2016-04-15 09:03:05 UTC
(In reply to Rpnpif from comment #24)
> (In reply to Jean-Baptiste Faure from comment #23)
> > How the original bugdoc
> > (https://bugs.documentfoundation.org/attachment.cgi?id=52631) has been
> > created? By using MSWord (which version) or by using LO or OOo ?
> 
> It is an old file created by MSWord 97, perhaps modified by Openoffice 3.x.

So, we don't know if the bug is an import bug in LO or an export bug in OOo.
I think that a progress in fixing this bug is possible only if we are able to decide between both possibilities. If the file has been modified by OOo before being imported by LO, I think we can close this bug report as WontFix because we can't repair OOo. The workaround from comment #14 shows that the file itself can be repaired.

If the file has not been modified by a MS-Office program, it is another story.

Best regards. JBF
Comment 26 Timur 2017-08-25 18:01:34 UTC
Created attachment 135799 [details]
Embedded DOC from "The doc file to test" saved in MSO

I guess it's oversight to mark this as EMF-WMF, because it's not. 
It's embedded grouped diagram that opens fine in another Writer window where it can be edited. And embedded looks like a key to me because that document itself loads fine in LO. 
Now with LO 6.0+ it can also be closed and have object updated in the original Writer document.
Normally it's important whether it's created in Word or modified in OO, but it's not so relevant because Word opens it fine.
Comment 27 QA Administrators 2018-08-26 02:39:28 UTC Comment hidden (obsolete)
Comment 28 Timur 2018-08-27 07:53:22 UTC
This bug started as fileopen issue of .DOC file not properly visible.
It previews fine from LO 6.0 (tested 6.0.6 and 6.2+) so I'll close as WFM.

There are other issues with this file that I'll report separately:
- diagram could be edited from 6.0 but it was wrong on open and save
- master 6.2+ opens embedded diagram read-only so cannot edit it
- DOCX opened fine in 6.1 but is blurry on fileopen in master 6.2+
Comment 29 Timur 2018-08-27 07:54:06 UTC
Created attachment 144472 [details]
The doc file to test - screenshot preview in MSO and LO 6.0.6
Comment 30 Timur 2018-08-27 11:23:36 UTC
In addition to other issues, DOC still doesn't preview arrows correctly. 
We may open another bug, but let's keep this one for that.
Comment 31 Chris Sherlock 2019-11-10 10:30:02 UTC
Created attachment 155672 [details]
WMF file with issue

This is the WMF file that is having the issue with the missing arrows.
Comment 32 Chris Sherlock 2019-11-10 11:34:05 UTC
Created attachment 155673 [details]
SAL_LOG set to +INFO.drawinglayer

Opening the WMF file with drawinglayer INFO statements logged.
Comment 33 Bartosz 2019-11-12 21:23:53 UTC
@Chris Sherlock
Thanks Chris for your attachment. It is very useful as it seems that it is an EMF/EMF+ issue. I will try to investigate this issue and prepare the fix.
Did you tried latest version of LibreOffice?
Comment 34 Bartosz 2019-11-13 21:29:48 UTC
The initial patch (without rotation) is available at:
https://gerrit.libreoffice.org/#/c/82564/
Comment 35 Chris Sherlock 2019-11-17 19:08:46 UTC
The arrows aren't working because we don't yet support EmfPlusCustomLineCap objects. 

To fix this, we must first:

1. Create an EMFPCustomLineCap object and read it in via EmfPlusHelperData::processObjectRecord (in drawinglayer/source/tools/emfphelperdata.cxx)

2. Implement the custom arrows, etc in the line processing.
Comment 36 Chris Sherlock 2019-11-17 19:10:52 UTC
We really need to implement the object here:

https://opengrok.libreoffice.org/xref/core/drawinglayer/source/tools/emfphelperdata.cxx?r=314f15bf#232
Comment 37 Chris Sherlock 2019-11-17 21:54:54 UTC
Argh! We do implement this, just wrongly. 

EMFPCustomLineCap should actually be a container that points to an object that either points to an EmfPlusCustomLineCapData object, or an EmfPlusCustomLineCapArrowData.

Currently the class EMFPCustomLineCap is actually a partially implemented EmfPlusCustomLineCapData.

It should be easy enough to rename EMFPCustomLineCap to EMFPCustomLineCapData and derive it from BaseEMFPCustomLineCapData, then create a new class EmfPlusCustomLineCapArrowData. We will need to read the EMFPCustomLineCap into the object table.

However, looking more closely, it actually appears we will also need to extend EMFPPath as it is not capturing the PenID.
Comment 38 Chris Sherlock 2019-11-17 23:08:44 UTC
OK, ignore all that. I misread the spec. It turns out that it's contained in OptionalData of the pen object, and in fact this is being done anyway.
Comment 39 Chris Sherlock 2019-11-17 23:11:16 UTC
So... apologies for the bug spam, but it turns out this might be a lot easier than I though. It actually turns out that custom line caps with arrows are not implemented.

See EMFPCustomLineCap::Read()

116          else if (type == EmfPlusCustomLineCapDataTypeAdjustableArrow)
117          {
118              // TODO only reads the data, does not use them [I've had
119              // no test document to be able to implement it]
120  
121              sal_Int32 width, height, middleInset, fillState, lineStartCap;
122              sal_Int32 lineEndCap, lineJoin, widthScale;
123              float fillHotSpotX, fillHotSpotY, lineHotSpotX, lineHotSpotY;
124  
125              s.ReadInt32(width).ReadInt32(height).ReadInt32(middleInset).ReadInt32(fillState).ReadInt32(lineStartCap)
126                  .ReadInt32(lineEndCap).ReadInt32(lineJoin).ReadFloat(miterLimit).ReadInt32(widthScale)
127                  .ReadFloat(fillHotSpotX).ReadFloat(fillHotSpotY).ReadFloat(lineHotSpotX).ReadFloat(lineHotSpotY);
128  
129              SAL_INFO("drawinglayer", "EMF+\t\tTODO - actually read EmfPlusCustomLineCapArrowData object (section 2.2.2.12)");
Comment 40 Chris Sherlock 2019-11-18 03:11:12 UTC
Testing https://gerrit.libreoffice.org/#/c/82564/5
Comment 41 Chris Sherlock 2019-11-18 17:26:34 UTC
Created attachment 155923 [details]
Arrow rotation issue
Comment 42 Chris Sherlock 2019-11-18 17:27:12 UTC
Almost, but the arrow needs to be rotated.
Comment 43 Chris Sherlock 2019-11-19 08:58:58 UTC
OK, my trig is a bit rusty but I've submitted a patch to gerrit on top of the great work of Bartosz (I've had his authorship righted by an admin, sorry about that!):

https://gerrit.libreoffice.org/#/c/82564/4..7/drawinglayer/source/tools/emfphelperdata.cxx
Comment 44 Commit Notification 2019-11-20 08:58:06 UTC
Bartosz Kosiorek committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/d15518584a3197e4b8318d0176352a0584f42167

tdf#42112 Add support for Custom Line Cap

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 45 Commit Notification 2019-11-20 22:17:38 UTC
Bartosz Kosiorek committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/26c6e23155b151c3f05f3cfdde2bd842aef05306

tdf#42112 Add support for Custom Line Cap

It will be available in 6.3.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 46 Xisco Faulí 2019-11-21 14:16:32 UTC
Verified in

Version: 6.5.0.0.alpha0+
Build ID: 60b1a93a990a9978a30dee929526faf8db629a7f
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

@Bartosz, @Chris Sherlock, thanks for fixing this long standing issue!
Comment 47 Commit Notification 2019-11-21 14:29:04 UTC
Bartosz Kosiorek committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/da4b6848bbe30a19c0aa3913d260c7d5c2f1f94f

tdf#42112 Add support for Custom Line Cap

It will be available in 6.4.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.