Created attachment 87908 [details] Example WMF This is new as compared to LibreOffice 3.6: When creating filles rectangles in Draw, exporting them as WMF, and importing them in Writer, the filled areas are not filled. Did not see this in LibreOffice 3. I'll attach an example. I found the problem with Windows/XP (32-bit)...
When double-clicking the WMF file in Windows, the filled areas are displayed, so I guess it's a bug in Writer, and not in Draw.
Bug is not reproducible, when EMF_PLUS_DISABLE environment variable is set, therefore it is a bug in EMF+ handling.
Is this a dupe of Bug 39327? Or just related to EMF+.
** 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 (5.0.4 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 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-12-20
Areas are still not filled in v5.2.0.4 (Windows 7 and Linux). Adding regression-related keywords, as it's correct in v3.5.0.3, incorrect in v3.6.0.4.
It's looks like SetPageTransform record is not using Pixels as an unit.
Bartosz, are you working on this one?
The areas are not filled in the oldest commit in Linux 43all repo. I tried advancing to the 3.5.0 release period, going forward with git log --reverse --pretty=%H latest | grep -A 1 $(git rev-parse HEAD) | tail -n1 | xargs git checkout ..with grep -A having various steps such as 10. The areas were never filled in the 3.5.0 commits.
Dear Ulrich Windl, 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
Created attachment 152497 [details] Comparing the presentation of the example image in LibreOffice 6.1 with Inkscape 0.91 Still present in 6.1 at least.
The same in Version: 6.3.3.2 (x64). No fill. Build ID: a64200df03143b798afd1ec74a12ab50359878ed CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: ro-RO (ro_RO); UI-Language: en-US Calc: threaded
I have a feeling I may have fixed this recently: https://git.libreoffice.org/core/commit/e356b371373ed6d047efac9913bc69cb2bfa0105 Needs to be tested.
(In reply to Chris Sherlock from comment #12) > I have a feeling I may have fixed this recently: > > https://git.libreoffice.org/core/commit/ > e356b371373ed6d047efac9913bc69cb2bfa0105 > > Needs to be tested. The issue is still reproducible in Version: 6.5.0.0.alpha0+ Build ID: fb1eac64df88baae9f211d052793773686c0e180 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 thus, the mentioned commit doesn't fix it
Created attachment 158573 [details] convert wmf in irfanview to emf file workaround save wmf as emf in irfanview or other convertors emf import is ok like in inkscape. workaround solution for programmers in LO convert wmf in emf with internal tool and libs and than import emf in LO
import emf successful in LO 6.4.1.2 x64 in win 10-64
not resolved in 7.0.0beta2x64 in win 10x64 emf is ok but fonts are not clear
No visible work done in the past year. Removing assignment statuses.
Created attachment 172012 [details] WMF file with removed 'ESCAPE' records
Created attachment 172013 [details] EMF file reconstructed from ESCAPPE records of the WMF file
Created attachment 172014 [details] EMF file reconstructed from ESCAPPE records of the WMF file with EMF+ records removed
Created attachment 172015 [details] WMF recuced to headers/eof and ESCAPE records
Original file is a WMF with 6 ESCAPE records at the start of the file. Those ESCAPE records embed EMF content into WMF. The EMF itself has bunch of EMF+ records and according to the EmfPlusHeader in the first of them it's supposed to be "EMF/EMF+ dual" file, hence content should be the same in EMF and EMF+ records. For the analysis the following files were created from original (#0) file: - #1 "pure WMF" with all ESCAPE records removed - #2 EMF/EMF+ extracted from ESCAPE records - #3 "pure EMF" with EMF+ records removed from #2 - #4 WMF with ESCAPE records only Observed behavior of MS Paint and PowerPoint (mac): #0 -- all colors are presented #1 -- all colors are presented #2 -- all colors are missed #3 -- all colors are presented #4 -- empty picture Conclusions part A: - there is something wrong with EMF+ part inside of EMF inside of WMF - MS Paint and PowerPoint (mac) ignore EMF/EMF+ part of the WMF file (no rendering of "ESCAPE only" #4 file, no problem with original #0 file) Observed behavior of LO 7.2 master (May 11, 2021): #0 -- all colors are missed #1 -- all colors are presented #2 -- all colors are missed #3 -- all colors are presented except those at the bottom #4 -- all colors are missed Conclusions part B: - LO tries to use (presumably superior) EMF and (presumably superior) EMF+ in it, which leads to missing colors in #0, #2 and drawing colorless image in #4 - there is another unidentified bug that prevents LO from rendering some colors for #3 ("pure EMF") file Suggestions: - validate behavior with those files in other MS implementations (MSO on win etc) - change LO to ignore EMF/EMF+ in WMF files - investigate the smaller problem with #3
Created attachment 172016 [details] Screenshot of "not-so-pure EMF" rendered by LO 7.2
Created attachment 172020 [details] Screenshot of "pure EMF" rendered by LO 7.2 My bad... There is no problem with "pure EMF" in LO 7.2 -- I was looking into partially cleared sample.
Created attachment 172021 [details] EMF sample with few first EMF+ records removed MS Paint/PowerPoint seems to ignore EMF+ records if EmfPlusHeader is missed, LO uses these records.
Comment on attachment 172016 [details] Screenshot of "not-so-pure EMF" rendered by LO 7.2 EmfPlusHeader is missed. There are some 'GetDC' and "FillPolygon' EMF+ records which seem to negatively impact rendering in LO.
Created attachment 172068 [details] Updated example WMF I noticed that a somewhat newer export of the same file (dated "Freitag, 25. Oktober 2013, 20:39:42", can't remember how it had been created) opens correctly in LO Draw 7.0.4.2 (and almost correctly in GIMP 2.10.24 and Microsoft Paint (all Windows 10).
updated WMF also ok in 7.1.3.2 win64 workaround WMF to EMF in Irfanview is also ok. original WMF also in 7.1.3.2 with the same limitations as before.
updated WMF is also ok in 7.2.0.2 win64 workaround WMF to EMF in Irfanview is also ok. original WMF also in 7.2.0.2 with the same limitations as before.
Valet, if EmfPlusHeader is missed, should we also be ignoring the EMF+ records due to presumed corruption?
Version: 7.3.4.2 (x64) / LibreOffice Community Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL same like in 7.2.0.2 updated WMF is also ok in 7.3.4.2 win64 workaround WMF to EMF in Irfanview is also ok. original WMF also in 7.3.4.2 with the same limitations as before.