Bug 141049 - Empty frame instead of image (WMF/EMF) on file-open DOC (OK if resaved in MSO as DOC/X)
Summary: Empty frame instead of image (WMF/EMF) on file-open DOC (OK if resaved in MSO...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.8.2 release
Hardware: All All
: medium normal
Assignee: Hossein
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: EMF-WMF
  Show dependency treegraph
 
Reported: 2021-03-15 13:37 UTC by Telesto
Modified: 2021-12-01 21:28 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
.doc file with 1 emf file inside it that should be visible, but it is not (36.00 KB, application/msword)
2021-10-13 01:08 UTC, Hossein
Details
Good PDF output for attachment 175701 from LibreOffice 6.2.0.1 (44.17 KB, application/pdf)
2021-10-13 01:13 UTC, Hossein
Details
Bad PDF output for attachment 175701 from LibreOffice 7.3 Dev (15.72 KB, application/pdf)
2021-10-13 01:15 UTC, Hossein
Details
EMF file inside attachment 175701 (107.21 KB, image/emf)
2021-10-13 01:18 UTC, Hossein
Details
PDF output for attachment 175701 from MS Word (64.71 KB, application/pdf)
2021-10-13 01:21 UTC, Hossein
Details
Screenshot: The inserted EMF can be made visible using the crop tool (197.91 KB, image/png)
2021-12-01 20:25 UTC, Hossein
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2021-03-15 13:37:31 UTC
Description:
Empty frame instead of image on file-open DOC

Steps to Reproduce:
1. Open attachment 43525 [details] from bug 34454
2. Check Figures 4 (page 5) and 8 (page 8) 

Actual Results:
Empty frame

Expected Results:
Image


Reproducible: Always


User Profile Reset: No



Additional Info:
Found in
Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: dc3b64dcbfb0a49c0be65bd8d73ed4e6d3828a21
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

and in
4.4.7.2

and in
4.1

and in
Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89)

fine in
3.5.7.2
Comment 1 Telesto 2021-03-15 13:41:52 UTC
Technically this is bug 34454. Apparently solved for GTK3, but still an issue on Windows
Comment 2 Roman Kuznetsov 2021-03-15 15:36:59 UTC
confirm in

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 9d8accf03984a64a4105826e55b221962628eb93
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: CL
Comment 3 Timur 2021-03-16 07:45:26 UTC
Further triage shows:
This was ok in 6.2 oldest but regressed again in 6.2 master. 
Same in Windows and Linux. 
Images are ok if DOC is resaved in MSO as DOC or DOCX. 
So this is the same issue as original bug 34454, where UI test was missing.
Comment 4 Timur 2021-03-16 08:02:57 UTC
I bisected this to bug 125281.
Xisco,you are fresh with images and lazy-loading, please see.
Comment 5 Hossein 2021-10-12 22:13:15 UTC
(In reply to Telesto from comment #1)
> Technically this is bug 34454. Apparently solved for GTK3, but still an
> issue on Windows
This is not OK in Gtk3, as far as I have tested. The bug was reproducible in these platforms:

LibreOffice 7.2 (Windows / Linux)

Version: 7.2.0.4 / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 7.2.0.4 / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 8; OS: Linux 5.11; UI render: Skia/Vulkan; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 7.2.0.4 / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 7.2.0.4 / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: qt5 (qfont+xcb)
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 7.2.0.4 / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: kf5 (cairo+xcb)
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 7.2.1.2 (x64) / LibreOffice Community
Build ID: 87b77fad49947c1441b67c559c339af8f3517e22
CPU threads: 32; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: en-US (en_DE); UI: en-US
Calc: threaded

------------------

LibreOffice 7.3 Dev (Windows / Linux)

Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 9a0335e7d2e43e46959bda16daf3fbf5944a1d9a
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 9a0335e7d2e43e46959bda16daf3fbf5944a1d9a
CPU threads: 8; OS: Linux 5.11; UI render: Skia/Vulkan; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 9a0335e7d2e43e46959bda16daf3fbf5944a1d9a
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 9a0335e7d2e43e46959bda16daf3fbf5944a1d9a
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: qt5 (qfont+xcb)
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 9a0335e7d2e43e46959bda16daf3fbf5944a1d9a
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: qt6 (qfont+xcb)
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 9a0335e7d2e43e46959bda16daf3fbf5944a1d9a
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: kf5 (cairo+xcb)
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 9a0335e7d2e43e46959bda16daf3fbf5944a1d9a
CPU threads: 32; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: en-US (en_DE); UI: en-US
Calc: threaded
Comment 6 Hossein 2021-10-13 00:34:15 UTC
It works fine with official builds for 6.2:

https://downloadarchive.documentfoundation.org/libreoffice/old/6.2.0.1/deb/x86_64/

Version: 6.2.0.1
Build ID: 0412ee99e862f384c1106d0841a950c4cfaa9df1
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 7 Hossein 2021-10-13 00:57:41 UTC
(In reply to Timur from comment #4)
> I bisected this to bug 125281.
> Xisco,you are fresh with images and lazy-loading, please see.
This is correct.
My bibisect also lead to the fix for bug 125281:

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

commit     69b62cfcbd364d7f62142149c2f690104b217ca1
author	   Miklos Vajna <vmiklos@collabora.com>	Mon May 27 21:24:42 2019 +0200
tdf#125281 DOC import: fix size of lazy-loaded metafiles
Metafiles may have an external header, so once graphic data is read, we
need to set the size explicitly. Otherwise the width of the EMF image in
the bugdoc will be too small.

The script used for the automated bibisect (https://lwn.net/Articles/317154/) was:
(tdf141049.doc is one of the figures that is not shown in the example (attachment 43525 [details] from bug 34454). The blank output is <20k, but the correct output is > 40k. Checking the size to be > 40k is used to determine if the commit is good or bad. 

./instdir/program/soffice --headless --convert-to pdf tdf141049.doc
file=tdf141049.pdf
minsize=40000
size=$(wc -c <"$file")
if [ $size -ge $minsize ]; then
    exit 0
else
    exit 1
fi
Comment 8 Hossein 2021-10-13 01:08:20 UTC
Created attachment 175701 [details]
.doc file with 1 emf file inside it that should be visible, but it is not

This file is one of the figures that is not shown in the attachment 43525 [details] from bug 34454.
This .doc file contains 1 emf file inside that should be visible, but it is not.
Comment 9 Hossein 2021-10-13 01:13:01 UTC
Created attachment 175702 [details]
Good PDF output for attachment 175701 [details] from LibreOffice 6.2.0.1

This is the good PDF output for attachment 175701 [details] from LibreOffice 6.2.0.1. The EMF file inside .doc file is rendered correctly, and the PDF file size is around 45k.
Comment 10 Hossein 2021-10-13 01:15:09 UTC
Created attachment 175703 [details]
Bad PDF output for attachment 175701 [details] from LibreOffice 7.3 Dev

This is the bad PDF output for attachment 175701 [details] from LibreOffice 7.3 Dev. The EMF file inside .doc file is not rendered, the output is almost blank, and the PDF file size is around 15k.
Comment 11 Hossein 2021-10-13 01:18:01 UTC
Created attachment 175704 [details]
EMF file inside attachment 175701 [details]

This is the EMF file inside .doc file in attachment 175701 [details], which is itself opened and rendered correctly in LibreOffice Draw 6.2, 7.2 and Dev 7.3.
Comment 12 Hossein 2021-10-13 01:21:01 UTC
Created attachment 175705 [details]
PDF output for attachment 175701 [details] from MS Word

This is the PDF output for attachment 175701 [details] from MS Word.
Comment 13 Hossein 2021-12-01 20:25:52 UTC
Created attachment 176638 [details]
Screenshot: The inserted EMF can be made visible using the crop tool

At first, it seemed that the embedded WMF file is not loaded at all, but the WMF file itself can be loaded separately without problem; So this observation looked contradictory.
Now, using the crop tool one can see that the inserted WMF file can become visible by extending the visible area. It can be deduced that the dimensions and/or the position of the WMF is wrongly calculated, which is in accordance to the changes in the commit found by the bibisect.