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
Technically this is bug 34454. Apparently solved for GTK3, but still an issue on Windows
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
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.
I bisected this to bug 125281. Xisco,you are fresh with images and lazy-loading, please see.
(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
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
(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
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.
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.
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.
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.
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.
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.
Created attachment 176638 [details] Screenshot: The inserted EMF can be made visible using the crop tool At first, it seemed that the embedded EMF file is not loaded at all, but the EMF file itself can be loaded separately without problem; So this observation looked contradictory. Now, using the crop tool one can see that the inserted EMF file can become visible by extending the visible area. It can be deduced that the dimensions and/or the position of the EMF is wrongly calculated, which is in accordance to the changes in the commit found by the bibisect.
Created attachment 189446 [details] DOC file re-saved with the latest MS Word Although the behavior of LO can be improved to also handle problematic files, I think there is something wrong with the DOC file itself. The image is not loaded in the latest MS Office, but the output contains the correct image. On the other hand, when re-saving the file to .doc in MS Word, the resulting file is opened and displayed correctly in LibreOffice.