Created attachment 126939 [details] The .doc file in question I have a .doc file which contains an image (some sort of WMF, if I am not mistaken). Instead of this image, only a purplish rectangle is shown by LibreOffice 5.2.0.4.
Created attachment 126940 [details] File as rendered by MS Office
Created attachment 126941 [details] The file as rendered by LO 5.2.0.4
There are two parts to this issue: 1. Rectangle is displayed instead of WMF. Reproduced in v4.4.0.3, looks more or less okay (see 2.) in v4.3.0.4 / Windows 7. => regression 2. Dotted pattern is not shown in the last column. This was never correct (the whole document does not open correctly in v3.3, and does in v3.5, but the patterns are not shown). There might be duplicate reports on either of these, but it's quite difficult to track them down.
I believe Chris Sherlock did some work on some of the other EMF bugs, he might have an idea.
Purple rectangle regression introduced in range 4011b74eb7650a0eeb99d3acebb9ef60b0fcaab9..274b628a2b523eb45e297352a85f0177c6e747f0
# bad: [cf6ea17155fabb2a120ba07c150735591ac861d7] source-hash-3f94c9e9ddfd807b449f3bb9b232cf2041fa12d2 # good: [fc71ac001f16209654d15ef8c1c4018aa55769f5] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e git bisect start 'latest' 'oldest' # bad: [8cf60cc706948588e2f33a6d98b7c55d454e362a] source-hash-f340f0454627939f1830826fb5cc53a90e6c62a4 git bisect bad 8cf60cc706948588e2f33a6d98b7c55d454e362a # good: [d9885f526fc7a09cc8f9f8ee643af1b966be24bb] source-hash-d1465c64c6f64ad8dd25e40cdc69649b24b305ea git bisect good d9885f526fc7a09cc8f9f8ee643af1b966be24bb # bad: [c779cf7967f4d14c5e649a5c696b07279d550efd] source-hash-e9c5022580f14c0ca97503f8b3cc56b530fff174 git bisect bad c779cf7967f4d14c5e649a5c696b07279d550efd # good: [030e0477638f9d9110ad62f88fd4b881521e0541] source-hash-1a6e47e3fda10e6d220b67d766ec6fbdfd852b80 git bisect good 030e0477638f9d9110ad62f88fd4b881521e0541 # bad: [c9e7f255b30a0410226b2074702aeba9b49dce13] source-hash-2d5a7c36ee9ae7ff39d8415f81fb911ff822548e git bisect bad c9e7f255b30a0410226b2074702aeba9b49dce13 # good: [d0dbfc8071785ec97868d0a98dec934d9eb81e5c] source-hash-24b6add3774f5f0807c907d5a233ba8ac11116f4 git bisect good d0dbfc8071785ec97868d0a98dec934d9eb81e5c # bad: [eeedb01370e2ca815d6ca73731471c8dd8c7aceb] source-hash-7f15d2612d450dd430a1288052bc408f3bb1fcd9 git bisect bad eeedb01370e2ca815d6ca73731471c8dd8c7aceb # good: [fc35228eadbc20de2c2f495e025cb290c1a0f03d] source-hash-83291976786c9bdf2839c902999d6d4090a5165f git bisect good fc35228eadbc20de2c2f495e025cb290c1a0f03d # bad: [d861d5b48f23343069137d4c967452b967a5b997] source-hash-2b8528a2745bec7909bfe2265d6110a9964eef47 git bisect bad d861d5b48f23343069137d4c967452b967a5b997 # good: [de1324367457e565722f7caca68763dc984e73c1] source-hash-46cea34638b371570073c0e86f79969753c543ed git bisect good de1324367457e565722f7caca68763dc984e73c1 # good: [eb40699cbbe85b112be4af03294e3b998a84db83] source-hash-d7374d4812316a79916956f03c8bd4a281fdbdec git bisect good eb40699cbbe85b112be4af03294e3b998a84db83 # skip: [defa73f7cca3f65d36e472bf91665c57640009d6] source-hash-8d3fc64066b157d2e24df57635000f121915793a git bisect skip defa73f7cca3f65d36e472bf91665c57640009d6 # bad: [37f77f77319e96379ad439deebe8f78453afb79b] source-hash-2d226f4c0b3f95bfdfe7bdcd3fd0ab87a806f4c3 git bisect bad 37f77f77319e96379ad439deebe8f78453afb79b # good: [10ccf925651718665cb365d492352ef0bfd496f1] source-hash-f19b91445546223cb3eacaec2925e51171cb0c85 git bisect good 10ccf925651718665cb365d492352ef0bfd496f1 # only skipped commits left to test # possible first bad commit: [37f77f77319e96379ad439deebe8f78453afb79b] source-hash-2d226f4c0b3f95bfdfe7bdcd3fd0ab87a806f4c3 # possible first bad commit: [defa73f7cca3f65d36e472bf91665c57640009d6] source-hash-8d3fc64066b157d2e24df57635000f121915793a
Since both of the commits are related to Michael Stahl, CC-ing him. Michael, please take a look. The commits don't look much related, but the bibisection/bisection clearly points there. Commits: "SchLayoutTabPage: that ctor wants a pointer" https://cgit.freedesktop.org/libreoffice/core/commit/?id=2d226f4c0b3f95bfdfe7bdcd3fd0ab87a806f4c3 "Repository.mk: cluster the mobile-only stuff together" https://cgit.freedesktop.org/libreoffice/core/commit/?id=8d3fc64066b157d2e24df57635000f121915793a
reading comment #7 it must be caused by one of these then: commit 6ca69fc429c45890f23e622b3591b81074d3d9ba Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> AuthorDate: Sat Jul 19 22:12:04 2014 +0200 bnc#881024 test font size at world transform Change-Id: If9b09b69ccd890e45d963422ccedb711585f6434 commit a34e2e08b6976613253a6caa737dbc191b56e372 Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> AuthorDate: Sat Jul 19 21:57:19 2014 +0200 emf+: recognise some more object types Change-Id: I33fec62e4bc38eeaf014eeb1210db2904af033f6 commit f97c5397f0784ab6e4dd3b8f59bcffd21f13d1af Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> AuthorDate: Sat Jul 19 21:52:09 2014 +0200 emf+: emulate hatch with color blend Change-Id: I2ac8f790c79c269d4c1fa650e703c3645c567ca4 commit cd3bffed33db9e847b4db99cc1220aa6f25f65ec Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> AuthorDate: Sat Jul 19 21:50:27 2014 +0200 xmlwriter: set indent and always write utf8 xml document Change-Id: I1477833e696edbac2dc375329e7b26a7105d1593 commit 501f6b050b8309f54e2842a26f6a3d95a859ffb7 Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> AuthorDate: Sat Jul 19 21:48:46 2014 +0200 Support color related MTF actions in mtfxmldump Change-Id: I5deac7f096866a8f149acfd0d11bbc0963238e88 commit 816f4be79c3847fac8d31bf0b63180e1468c7109 Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> AuthorDate: Fri Jul 18 13:36:59 2014 +0200 bnc#881024 Handle 0 font height just like outdev & drawinglayer Change-Id: I80055e4101873e0ddd408ac1f0ee9c75cc3bf6b3 commit 8f705df1221c3f92d8cde68bdf726a7c3ce8fe1b Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> AuthorDate: Fri Jul 18 13:36:13 2014 +0200 bnc#881024 Don't world transform font size in WMF/EMF import Change-Id: Ia865b84ee2b159ff7251ab5a769a2b635dd2a1ea commit 88d1d90fb785093bee448353d2978e86bb953b2f Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> AuthorDate: Fri Jul 18 10:19:16 2014 +0200 Also add xmlwriter's "content" method to the header file Change-Id: Ic3e13e89480e3b18f84c3a8fd1a88627bd465d6a commit cef094efd7641dc3b6c1984fd701cd133d44067f Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> AuthorDate: Fri Jul 18 10:15:10 2014 +0200 emf+: Log type name instead of the type number Change-Id: I5c4f7c5713a559815bd46328907673d114fee011 commit 317f154de7cf26a88e82008c895dbb0a840d5646 Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> AuthorDate: Fri Jul 18 10:09:14 2014 +0200 Extend metafile to xml dump testing tool with more MFT actions Change-Id: I819de476c6a615b8cf27a6a26d41a6e9ac25ef85
Created attachment 127501 [details] .doc file with inserted .emf image I have the same problem with attached file.
(In reply to Ákos from comment #9) > Created attachment 127501 [details] > .doc file with inserted .emf image > > I have the same problem with attached file. I realize, that my file isn't the same bug. Is a regression between LO 3.5.7.2 and 3.6.0.4. I open a new bug for it:
Adding Cc: to Tomaž Vajngerl
Reproduced in LibreOfficeDev 5.3.0.0.alpha1 f4ca1573fcf445164c068c1046ab5d084e1b005f
Investigating the problem lead to the following results: The whole EMF picture is covered by a purple rectangle. This rectangle should be transparent and just surround the picture with black lines. The drawing actions are created in the vcl module. The color (purple) of the previously drawn rectangle (the small right ones in the key) is an EMF+ comment. This comment is not handled in vcl, but later in cppcanvas. Now the problem occurs: This later created color of the previously draws rectangles is not reset. This makes the last rectangle purple, too. An additional call of "updateFillStyle()" after each EMF+ comment actually solves the problem, but produces unnecessary actions in most cases. Now I'm stuck with new ideas. The missing pattern is just not implemented. The patterns are EMF+ brush actions, which are simply simulated by increasing the brightness of the color.
Hello Patrick. Do you know where I could find missing pattern which needs to be implemented?
Hi Bartosz! The missing hatch style (=pattern) implementation is found in cppcanvas/source/mtfrenderer/emfplus.cxx Line 335 etc. The EMF+ Documentation https://msdn.microsoft.com/en-us/library/cc230724.aspx (keyword: "hatchstyle") does not tell you how the patterns should look exactly, unfortunately. I hope this helps a little :) Regards, Patrick
Hi Patrick. Unfortunately I cannot notice any mentioned issues which was described. Could you please create some screenshot, and mark the difference between MS Office and LibreOffice 5.4alpha? It will help resolving that bug.
Hi Bartosz, I just opened the .doc file with the latest 5.4alpha build (Build-ID 666901bc82fab69f9a80b564f97b5456d0ef684e) from 05/16. The last EMF picture still looks exactly the same as the render from LO 5.2.0.4: There is just a pink rectangle shown. If you apply my suggestion https://gerrit.libreoffice.org/#/c/34274/ you will see the actual EMF image. My patch causes wrong information in most cases, therefore it is not accepted by reviewers.
With the new EMF+ Renderer the purple rectangle bug is fixed in current master! The 4 charts are now completely visible. Missing patterns are still not correctly implemented. They are currently replaced by a little brighter color.
** 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
The bug is still present. The emf-plus renderer rewrite resolved the bug that the last image was not shown at all. Situation now is a missing pattern in the last picture. Currently, LO "emulates" the pattern by shifting the color a bit into gray. Since I cannot find any detailed specification about the patterns to be drawn, I cannot implement this feature. Code needs to be implemented in drawinglayer/source/tools/emfphelperdata.cxx:548 pp (it will be ported to "emfio" module in the future, I have this still on my TODO list)
Created attachment 144479 [details] Image with wrong pattern extracted from .doc file.
I know this might seem odd, but this is sort of working. The reason that this is a purplish background is because we are actually blending the colours to create the hatch. The hatch being used in the EMF is HatchStyle70Percent. According to the EMF+ specs, in actual fact this is "HatchStyle70Percent: Specifies a 70-percent hatch, which is the ratio of foreground color to background color equal to 70:100." Nevertheless, I wouldn't consider this fully fixed yet, because in fact we haven't implemented any hatches other than the blending hatches. The code in question will need to be implemented in EmfPlusHelperData::EMFPPlusFillPolygon(). The best way of implementing it would be as a drawinglayer 2D primitive.
Created attachment 156727 [details] Pattern selection in LibreOffice Writer The patterns are fully supported by LibreOffice (see attached screenshot), so the implementation could be reused. The only question how to access to it, to be able to display it properly.
I have a partial solution - doesn't deal with the blending issue (that will be for later when I work out how to create hatch primitives!). But I have fixed the non-hatching or horizontal, vertical, forward diagnoal, backward diagonal, large grid and diagonal cross. Still needs polish, but submitting early for review.
Oh... forgot that gerrit was down. Will submit this when it is back.
See https://gerrit.libreoffice.org/c/core/+/85669 for partial implementation of hatch fills.
Dear Chris Sherlock, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.
Information how to create HatchPrimitive is here: https://docs.libreoffice.org/drawinglayer.html
Dear Oliver Sander, 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
Cannot reproduce with Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 905e7c1105536c9757fa2c2faf670738aab02595 CPU threads: 8; OS: macOS 15.0; UI render: Skia/Metal; VCL: osx Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded