Bug 119180 - FILEOPEN DOCX with embeddings: Image is blurred
Summary: FILEOPEN DOCX with embeddings: Image is blurred
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Armin Le Grand
URL:
Whiteboard: target:6.3.0 target:6.2.0.2
Keywords: bibisected, bisected, regression
: 119529 (view as bug list)
Depends on:
Blocks: DOCX-Images DOCX-OLE-Objects
  Show dependency treegraph
 
Reported: 2018-08-09 17:22 UTC by Xisco Faulí
Modified: 2018-12-21 22:07 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
comparison MSO 2010 and LibreOffice 6.2 (442.30 KB, image/png)
2018-08-09 17:22 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2018-08-09 17:22:08 UTC
Created attachment 144067 [details]
comparison MSO 2010 and LibreOffice 6.2

Steps to reproduce:
1. Open attachment 49313 [details] from bug 39384

-> Observed behaviour: The images are blurred and the text can't be read. See comparison

Reproduced in

Version: 6.2.0.0.alpha0+
Build ID: c86a47a9d3debbc7e8ee6247f573e7f98c611f19
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded

[Bug found by office-interoperability-tools]
Comment 1 Xisco Faulí 2018-08-09 17:23:10 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=cbc992e7370ab006ea7c0f8520896845f79f7749

author	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-07-19 19:26:14 +0200
committer	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-07-20 20:29:11 +0200
commit cbc992e7370ab006ea7c0f8520896845f79f7749 (patch)
tree 71000129a35f40d680279134efae7fac1c4e6a52
parent 133da6ed83b278b9e6059c5c1a3d49f9f402792e (diff)
tdf#118662 Cleanup old hack with cloned SdrCaptionObj

Bisected with: bibisect-linux64-6.2

Adding Cc: to Armin Le Grand
Comment 2 Xisco Faulí 2018-08-09 17:41:13 UTC
attachment 53915 [details] from bug 33590 is also affected by this commit....
Comment 3 Xisco Faulí 2018-08-09 17:42:36 UTC
and attachment 95137 [details] from bug 75557
Comment 4 Xisco Faulí 2018-08-09 17:44:08 UTC
and attachment 100957 [details] from bug 79969
Comment 5 Xisco Faulí 2018-08-27 08:38:08 UTC
*** Bug 119529 has been marked as a duplicate of this bug. ***
Comment 6 Timur 2018-08-27 11:21:07 UTC
and attachment 144474 [details] from Bug 119529
Comment 7 Timur 2018-12-06 13:09:49 UTC
Repro 6.3+. DOCX is 2007 but regardless, same is if saved in newer MSO. 
attachment 4931 image is PNG, with binary object oleObject1.bin inside DOCX. 
attachment 144474 [details] image is EMF. Also with oleObject1.bin.
attachment 53915 [details] image is WMF. oleObject1.bin.
attachment 95137 [details] image is EMF. oleObject1.bin.
attachment 100957 [details] image is EMF. With embedding Microsoft_Excel_Binary_Worksheet1.xlsb.
Comment 8 Xisco Faulí 2018-12-20 11:20:37 UTC
Also reproduced with attachment 124792 [details] from bug 99631
Comment 9 Armin Le Grand 2018-12-20 14:48:56 UTC
Could reproduce. Looks as if I was to ambitioned/nice in SvxShape::GetBitmap by also changing the way the Bitmap gets constructed.

It's UNO API and thus results have to be in 100th_mm - theoretically. So I first tried to adapt the else-part that creates a Bitmap by scaling the basegfx::B2DRange aRange from the MapTwip when Writer is running to Map100thMM, theoretically correct. But does not scale the Primitives involved...

Note: This may also be necessary for the if-part where a Metafile is created...
Comment 10 Armin Le Grand 2018-12-20 15:21:42 UTC
Made this work for the common case ('else' part). Also added a shortcut if the object in question already is a SdrGrafObj, has a Bitmap graphic and that is requested. NOT for Metafile (see comments there). Always better to use the original graphic - using convertPrimitive2DSequenceToBitmapEx may (and as we saw does) scale the result. This is okay if not a SdrGrafObj/Bitmap already.

Looks good, preparing to commit solution...
Comment 11 Armin Le Grand 2018-12-20 15:34:56 UTC
Solution on 'https://gerrit.libreoffice.org/#/c/65505/'...
Comment 12 Armin Le Grand 2018-12-20 19:25:50 UTC
Okay, should be fine
Comment 13 Commit Notification 2018-12-20 19:26:20 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/df57d50e00820d59b2b7104b6e59883405d0f183%5E%21

tdf#119180 Use 100th_mm in UNO API implementation

It will be available in 6.3.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 14 Xisco Faulí 2018-12-21 09:34:55 UTC
Verified in

Version: 6.3.0.0.alpha0+
Build ID: 7d63c700c36afd27850346e42b92768f084f5d4d
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

@Armin, thanks for fixing this!!

Cherry-picked to 6-2: https://gerrit.libreoffice.org/#/c/65523/
Comment 15 Commit Notification 2018-12-21 22:07:16 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/e42e3f3f28691de2ed8132564066bc3007eac651%5E%21

tdf#119180 Use 100th_mm in UNO API implementation

It will be available in 6.2.0.2.

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.