Created attachment 97473 [details] Vendor document that is sent to us monthly. We have no control over it coming in a .docx format Problem description: When opening a WMF picture in a docx file (see attached file page 1) the image renders on the page but not when printed. The outline and some of the header data will be there but the numbers in the columns do not. Steps to reproduce: 1. Open attached file: Packaging Change Management Supplier Form_ACME4.docx 2. View and print page 1 to see the missing data. Steps to resolve currently: 1. Right click on the image and select "Compress Graphic" 2. In the Compress Graphic dialogue uncheck "Reduce Image Resolution" 3. Click OK and the image will convert to a bitmap that will now be printable. Current behavior: WMF not printing correctly Expected behavior: WMF being automatically handled so it prints correctly. In this case converting a single image isn't an issue but on a files with a lot of issues it won't be feasible. Operating System: Windows 7 Version: 4.2.2.1 release
Confirmed on Windows 7 in LibO 3.6 - 4.2 and 4.4a. This is a regression as it prints correctly in 3.5, likely because there is no right-click > 'Compress Graphic' option, though that option isnt there in 3.6 as well. This doesnt effect Linux.
Created attachment 100433 [details] LibO 3.5 vs 4.2 on Windows
adjusting version per comment #2 "Reduce Image Resolution" was added in this commit: commit 660e3c1b204ac709e2acdace2a67f359505a1555 Author: Tomaž Vajngerl <quikee@gmail.com> AuthorDate: Sun Jul 15 22:22:45 2012 +0200 GUI improvements for CompressGraphicDialog.
Doesn't affect Linux so no bibisect needed. Also it seems MStahl has found the bad commit.
The commit mentioned in comment 3 isn't Windows specific, so possibly more related to the Windows handling of WMFs? -> Whiteboard:notBibisectable
I confirme this bug on Windows 7 with libreoffice-4-3-7
*** Bug 75574 has been marked as a duplicate of this bug. ***
> Steps to resolve currently: > 1. Right click on the image and select "Compress Graphic" > 2. In the Compress Graphic dialogue uncheck "Reduce Image Resolution" > 3. Click OK and the image will convert to a bitmap that will now be > printable. Another temporary resolution worked for attachment 76865 [details]: 1. Right click on the image and select "Compress Graphic" 2. In the Compress Graphic dialogue click "Calculate"
This workaround is not a permanent solution, the files that are problematic contain hundreds of images and we should apply this resolution manually on each image. Does anyone have an idea on the part of code that created this regression or any track to move forward on this issue? Thank you in advance.
With how old it is - tracking down what patch created the regression is incredibly hard/time-consuming. Plus, reverting the patch likely won't even be possible at this point as it'll mess up other things. If you are thinking about fixing it yourself I suggest asking on the developer mailing list to see if they can provide code pointers - but please don't do this if you aren't going to put in a good faith effort to fix it (as tracking down code takes some time and developers are already stretched thin). Thanks!
The option to for compression was added to libreoffice at this moment, so this regression was added in this commit: commit d82a77197cab00258e1e2b370c931d69f1e24fa2 Author: Tomaž Vajngerl <quikee@gmail.com> Date: Sun Jul 1 17:43:57 2012 +0200 Can someone confirm this ? The situation is critical for this bug and the source code has changed significantly. Thanks in advance for any any track.
Any developments on that bug? I also have it on libreoffice-4-3-7 and the workaround is not acceptable as there could be a lot of images and a lot of documents.
We don't give ETAs - this bug will be fixed when a volunteer finds it interesting and wants to fix it. The other options are for you to fix it, for you to find someone to fix it, or for you to pay for a fix (through a certified developer or some third party)
*** Bug 95875 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (notBibisectable)
*** Bug 101068 has been marked as a duplicate of this bug. ***
This regression was introduced before branch 4.4, thus it can't be bibisected with the current bibisect repositories. Changing keyword 'notBibisectable' to 'preBibisect'
Looks like fixed in 5.2.1. It would be nice to note in which bug. But it caused another regression for which I'll open a fileopen bug: attachment 113502 [details] from Bug 89473 now opens with black squares instead of images. It can also be solved as in Comment 8: Right-click "Compress Graphic" and "Calculate".
(In reply to Timur from comment #18) > Looks like fixed in 5.2.1. It would be nice to note in which bug. So you tested this on windows?
(In reply to Yousuf Philips (jay) from comment #19) > So you tested this on windows? Sure, it's Windows bug all the time. If you have different result, that could be OpenGL difference, like in Bug 103833. I add my OpenGL report there.
*** Bug 99727 has been marked as a duplicate of this bug. ***
*** Bug 74686 has been marked as a duplicate of this bug. ***
(In reply to Timur from comment #18) > Looks like fixed in 5.2.1. It would be nice to note in which bug. Xisco, could you check this, please.
*** Bug 75373 has been marked as a duplicate of this bug. ***
This one seems to have been solved from 5.2.1. up to master 5.3, but then recently stopped to work again. Master tested with: TinderBox: Win-x86@42, Branch:master, Time: 2016-10-26 (works OK) Version: 5.3.0.0.alpha1+ Build ID: bbd44f8f89839b5abb4ec6c7ea195431de5b2f48 TinderBox: Win-x86@39, Branch:master, Time: 2016-11-15 (problem again) Version: 5.3.0.0.alpha1+ Build ID: 074f0ab1d76f16fe92493868e2f2de75e67792ef
Changing keyword 'preBibisect' that related to previous bug state to 'bibisectRequest' for this new change. Xisco, could you check this both, please, change in 5.2.1 and recent change.
*** Bug 80389 has been marked as a duplicate of this bug. ***
@raal, one for you?
pushing this over to bug 104252, as the loss of WMF EMF and SVM text content affects Windows builds from 4.0.5.2 -> current master is better isolated there while the "black squares" on print/export to PDF of bug 89473 and bug 103833 *** This bug has been marked as a duplicate of bug 104252 ***