Bug 138515 - picture (wmf) not printed nor exported
Summary: picture (wmf) not printed nor exported
Status: RESOLVED DUPLICATE of bug 129085
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.0.0.beta1+
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: EMF-WMF
  Show dependency treegraph
 
Reported: 2020-11-26 19:38 UTC by Dominik Kopp
Modified: 2021-03-11 13:10 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
document with an unprintable picture. (43.55 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-11-26 19:38 UTC, Dominik Kopp
Details
Switched EMF to PNG (17.29 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-03-07 09:57 UTC, Luke Deller
Details
Screenshot showing issue with tdf138515-png.docx (296.42 KB, image/png)
2021-03-07 22:58 UTC, Luke Deller
Details
Screenshot showing version I am testing with (865.10 KB, image/png)
2021-03-07 22:59 UTC, Luke Deller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dominik Kopp 2020-11-26 19:38:53 UTC
Created attachment 167600 [details]
document with an unprintable picture.

I received I quite small docx which contains only a picture (wmf-format).
It's shown the document and in the print preview, but it's neither shown in the print dialog nor printed at all.

Even pdf export doesn't work (=empty page).

=> printing impossible.
Comment 1 Timur 2020-11-27 06:59:07 UTC
If wrap of image is Tight, it's a duplicate of bug 129085.

*** This bug has been marked as a duplicate of bug 129085 ***
Comment 2 Timur 2021-02-26 15:38:55 UTC Comment hidden (obsolete)
Comment 3 Gabor Kelemen (allotropia) 2021-03-01 07:15:17 UTC
(In reply to Timur from comment #2)
> This bug is not a duplicate of bug 126310, version don't fit. Wrong with LO
> 6.4 but OK with 6.1.6.
> I bibisected with 6.4 in Linux.

Interesting. That seems to be the point where this started to me as well.

I tried to locally revert that patch, and that did not made the images from the attachment of bug #126310 disappear, but did not made the image in this one appear either.

But extracting the image from the archive and opening it in Draw works fine, so there must be something funny in the docx import for sure.

@Miklos could you please advise if it makes sense to revert that bibisected patch?
Comment 4 Miklos Vajna 2021-03-01 08:42:51 UTC
Disabling lazy-loading was just a workaround, so if the original problem is not-reintroduced by the revert, then it sounds like a good direction.
Comment 5 Xisco Faulí 2021-03-04 15:08:48 UTC
(In reply to Gabor Kelemen from comment #3)
> (In reply to Timur from comment #2)
> > This bug is not a duplicate of bug 126310, version don't fit. Wrong with LO
> > 6.4 but OK with 6.1.6.
> > I bibisected with 6.4 in Linux.
> 
> Interesting. That seems to be the point where this started to me as well.
> 
> I tried to locally revert that patch, and that did not made the images from
> the attachment of bug #126310 disappear, but did not made the image in this
> one appear either.
> 
> But extracting the image from the archive and opening it in Draw works fine,
> so there must be something funny in the docx import for sure.
> 
> @Miklos could you please advise if it makes sense to revert that bibisected
> patch?

I'll try to bisect it the slow way. git bisect good/bad, build without 184a4771dad448a37f80b29bc62ad62e0a6a4bb6, and check, it might take a few days...
Comment 6 Xisco Faulí 2021-03-05 10:01:39 UTC Comment hidden (obsolete)
Comment 7 Timur 2021-03-05 10:33:21 UTC Comment hidden (obsolete)
Comment 8 Xisco Faulí 2021-03-05 10:36:56 UTC
(In reply to Timur from comment #7)
> Xisco, please explain what you're doing, for the sake of my bibisect
> understanding. 
> I got commit and wrote previous and change source commit. 
> What else needs to be done? 
> If good/bad is a slow way (I always do like that), what is the faster way to
> bibisect?

As explained in comment 3, the issue is not fixed if the bisected commit < 184a4771dad448a37f80b29bc62ad62e0a6a4bb6 > is reverting. Thus, we need to bisect it reverting 184a4771dad448a37f80b29bc62ad62e0a6a4bb6 on every step. The process is slow because you need to build LibreOffice on every step
Comment 9 Xisco Faulí 2021-03-05 17:27:32 UTC
Finally I found the real culprit.
Regression introduced by:

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

author	Luke Deller <luke@deller.id.au>	2019-08-07 00:22:12 +1000
committer	Miklos Vajna <vmiklos@collabora.com>	2019-08-07 16:43:21 +0200
commit 6369cab9b1e16275c8700692bb717aec3c42d346 (patch)
tree 86d3edc226c7bd4d5f92270d2f6e5df0349a725f
parent 75903a0298218f89a199a5ac151ee0166f4469d7 (diff)
tdf#126708 Fix EMF image size in CLI .doc export

Adding Cc: to Luke Deller

Note, 184a4771dad448a37f80b29bc62ad62e0a6a4bb6 has to be reverted first.
Comment 10 Xisco Faulí 2021-03-05 17:28:38 UTC Comment hidden (obsolete)
Comment 11 Xisco Faulí 2021-03-05 19:11:58 UTC
(In reply to Xisco Faulí from comment #10)
> (In reply to Miklos Vajna from comment #4)
> > Disabling lazy-loading was just a workaround, so if the original problem is
> > not-reintroduced by the revert, then it sounds like a good direction.
> 
> I will revert it in master. Meanwhile, I'll build libreoffice-7-0 and
> libreoffice-7-1 without the commit in place to see whether it's safe to
> backport the revert

I build libreoffice-7-0 < a4bdd833a252ed4d942e4478fc820f9f2ee725fe > with the revert on top and bug 126310 is not reintroduced, so it would be safe to backport the revert to previous versions in case we would need to
Comment 12 Luke Deller 2021-03-07 09:57:16 UTC
Created attachment 170292 [details]
Switched EMF to PNG

Hi Xisco!  I think the commit you found is not the root of the problem.

Unzipping the reporter's document, there is a file named word/media/image1.wmf which is an EMF file despite the name.

I have replaced this file with a PNG image of the same size, and adjusted the references to the filename in XML, to produce another sample document which I am attaching now: tdf138515-png.docx

This file exhibits the same problem, and is not fixed by reverting the commits that you identified.

Note that the effect of reverting 6369cab9b1e16275c8700692bb717aec3c42d346 will be that LO will be unable to detect the size of lazy-loaded EMF images before they are fully loaded.  Similar detection is already in place for other image formats such as PNG, which is why this new example using PNG is unaffected by the reversion.

Do you think next steps could be to run bibisection on the new sample document?
Comment 13 Xisco Faulí 2021-03-07 20:29:46 UTC Comment hidden (obsolete)
Comment 14 Xisco Faulí 2021-03-07 20:34:00 UTC
(In reply to Xisco Faulí from comment #13)
> Hi Luke,
> Did you also revert 184a4771dad448a37f80b29bc62ad62e0a6a4bb6 as explained in
> comment 9 ?
> The problem with your file is also fixed if
> 184a4771dad448a37f80b29bc62ad62e0a6a4bb6 and your patch <
> 6369cab9b1e16275c8700692bb717aec3c42d346 > are reverted
 184a4771dad448a37f80b29bc62ad62e0a6a4bb6 has been reverted in master < https://cgit.freedesktop.org/libreoffice/core/commit/?id=1238ca8d100c107656b707ed3a6b662f0a1867fb > please try again your test in comment 12 with a build containing that commit.
Comment 15 Luke Deller 2021-03-07 22:58:30 UTC
Created attachment 170320 [details]
Screenshot showing issue with tdf138515-png.docx

Screenshot showing issue still present with tdf138515-png.docx even after 184a4771dad448a37f80b29bc62ad62e0a6a4bb6 and 6369cab9b1e16275c8700692bb717aec3c42d346 are reverted
Comment 16 Luke Deller 2021-03-07 22:59:47 UTC
Created attachment 170321 [details]
Screenshot showing version I am testing with
Comment 17 Xisco Faulí 2021-03-08 09:25:35 UTC Comment hidden (obsolete)
Comment 18 Xisco Faulí 2021-03-08 09:36:49 UTC
(In reply to Xisco Faulí from comment #17)
> Hi Luke,
> I think we are mixing things up here. OTOH, yes, I see your problem in the
> print preview, which was introduced by
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=362c1cf2bd580f6dc8bf27bdcd79174111bc1b5c ( this can be reported in
> anothe issue ) but if your document is exported to PDF, the PNG image is
> displayed in the PDF. This bug is about the EMF file not displayed in the
> PDF file. For that, open attachment 167600 [details] and export it to PDF,
> the image is not there. Then, revert both commits (
> 184a4771dad448a37f80b29bc62ad62e0a6a4bb6 and
> 6369cab9b1e16275c8700692bb717aec3c42d346 ) and retry, the image is in the PDF

Oh, so you are right, reverting 362c1cf2bd580f6dc8bf27bdcd79174111bc1b5c fixes both issues.

Regression introduced by:

author	Armin Le Grand <Armin.Le.Grand@me.com>	2019-04-02 17:59:40 +0200
committer	Armin Le Grand <Armin.Le.Grand@me.com>	2019-04-02 21:03:07 +0200
commit 362c1cf2bd580f6dc8bf27bdcd79174111bc1b5c (patch)
tree 3fae3016fd6960121f40c2391f252e2a94377e21
parent 958442c89237eece4ff2467a7800bca6b0be9fe7 (diff)
tdf#124272 use ClipRegion's geometry if not a rectangle

Bisected with: bibisect-linux64-6.3

Adding Cc: to Armin Le Grand
Comment 19 Gabor Kelemen (allotropia) 2021-03-11 07:38:26 UTC
(In reply to Xisco Faulí from comment #18)

> Regression introduced by:
> tdf#124272 use ClipRegion's geometry if not a rectangle

Then this is a duplicate of bug #129085.

Timur was right in comment #1 after all :).

Also: turning off the Image - Wrap - Contour option makes the image appear in the Print dialogs preview similarly to the
- attachment #156171 [details] of bug #129085.
- attachment #152689 [details] of bug #126313 (this bibisected the problem even further)
- attachment #168376 [details] of bug #139124
Comment 20 Xisco Faulí 2021-03-11 13:10:34 UTC
This is fixed with https://gerrit.libreoffice.org/c/core/+/112340.
Closing as duplicate of bug 129085

*** This bug has been marked as a duplicate of bug 129085 ***