(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).
Created attachment 52631 [details] The doc file to test
Created attachment 52632 [details] The odt file after converting
Created attachment 52633 [details] The pdf file after converting This issue is important for usability of LO.
Created attachment 52894 [details] screenshot of OpenOffice
Created attachment 52895 [details] screenshot of LO
Same issue with LO 3.4.4-RC1
.
reproducible with LO 3.6.4.3. (Win7 Home, 64bit) in Word 2007 everything looks fine
*** Bug 61058 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > *** Bug 61058 has been marked as a duplicate of this bug. *** Hi, I think that it is an error : Bug 61058 is not a duplicate of this bug. (confusion with 42122). This comment is for archives.
Same bug with LO 4.2.5.2, Build ID: 61cb170a04bb1f12e77c884eab9192be736ec5f5.
This bug is still existing in LO 4.3.1.2.
(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.
(In reply to Timur from comment #13) Hi, I had not seen what you wrote about 3.4 or 3.5 releases. So do not get too hasty conclusions. Perhaps, now it is another bug. It is a regression against OO from which LO comes. I think that you should not edit the summary thus. But you are right with your workaround : Double-click on the object that opens itself in another window. Then copy-paste this new object instead of the original object. Save on disk. With LO 4.4 on Debian Linux, the reopen of this new file works fine. So you are right : the bug is concerning NOW (with LO 4.3.4) the loading code. Perhaps, this will give ideas to developers.
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_
(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
Created attachment 113618 [details] The doc file to test - screenshot preview in LO 3.5.7.2 and 3.6.0.4
(In reply to Rpnpif from comment #14) > It is a regression against OO from which LO comes. I think that you should > not edit the summary thus. Regression against OO means that bug doesn't exist in OO and exists in the first version after that, LO 3.3.0. It's not the case here. Version is where bug started to appear. According to "The doc file to test - screenshot preview in LO 3.5.7.2 and 3.6.0.4" I change version to 3.6.0.4.
@Timur : The policy of this bugs site says that the version must be "The earliest version of the software in which the bug can be reproduced." https://bugs.documentfoundation.org/page.cgi?id=fields.html#version So I remove your change. Regards.
This issue that was now minor by the workaround, is reproducible in LO 5.0.1.1.
Migrating Whiteboard tags to Keywords: (preBibisect) [NinjaEdit]
This issue is still present in Version 5.1.0.1.
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 ? Best regards. JBF
(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.
(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
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.
** 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 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
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+
Created attachment 144472 [details] The doc file to test - screenshot preview in MSO and LO 6.0.6
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.
Created attachment 155672 [details] WMF file with issue This is the WMF file that is having the issue with the missing arrows.
Created attachment 155673 [details] SAL_LOG set to +INFO.drawinglayer Opening the WMF file with drawinglayer INFO statements logged.
@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?
The initial patch (without rotation) is available at: https://gerrit.libreoffice.org/#/c/82564/
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.
We really need to implement the object here: https://opengrok.libreoffice.org/xref/core/drawinglayer/source/tools/emfphelperdata.cxx?r=314f15bf#232
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.
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.
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)");
Testing https://gerrit.libreoffice.org/#/c/82564/5
Created attachment 155923 [details] Arrow rotation issue
Almost, but the arrow needs to be rotated.
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
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.
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.
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!
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.