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.
If wrap of image is Tight, it's a duplicate of bug 129085. *** This bug has been marked as a duplicate of bug 129085 ***
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. # first bad commit: [3a12724668cc8b45bfdf97c049397b5f914607e1] source 184a4771dad448a37f80b29bc62ad62e0a6a4bb6 previous source 3932c8184a8c93a17c0c7429d5dd9597b087e076 https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=3932c8184a8c93a17c0c7429d5dd9597b087e076..184a4771dad448a37f80b29bc62ad62e0a6a4bb6 author Gabor Kelemen <kelemen.gabor2@nisz.hu> 2019-07-14 20:21:08 +0200 committer Miklos Vajna <vmiklos@collabora.com> 2019-07-15 09:58:07 +0200 commit 184a4771dad448a37f80b29bc62ad62e0a6a4bb6 (patch) tree 735d4d65c0c2534d882437434c97d4a7605b9527 parent 3932c8184a8c93a17c0c7429d5dd9597b087e076 (diff) tdf#126310 Disable lazy loading of WMF images
(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?
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.
(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...
Half way through: $ git bisect log # bad: [62fcfdfef4790f2569838e5f3ef39ee4e33028b8] jsdialog: single activation property for treeview # good: [184a4771dad448a37f80b29bc62ad62e0a6a4bb6] tdf#126310 Disable lazy loading of WMF images git bisect start 'HEAD' '184a4771dad448a37f80b29bc62ad62e0a6a4bb6' # bad: [882b768419f8f6f9cc1d8c56534c063f572b483e] CppUnittest: ooxmlexport12: assert pages where possible git bisect bad 882b768419f8f6f9cc1d8c56534c063f572b483e # bad: [0fb2b9b23ac3d082251217b3478917b387fe162c] Add comment about confusion in SwCommentRuler::CreateJsonNotification() git bisect bad 0fb2b9b23ac3d082251217b3478917b387fe162c # bad: [6d46ccc6b52c45d3d64a1c66f616defd12147bc5] jsdialogs: send toolitems git bisect bad 6d46ccc6b52c45d3d64a1c66f616defd12147bc5 # bad: [2379f36bd809c3cf3be71315a85946e273023a8c] tdf#88205 Adapt uses of css::uno::Sequence to use initializer_list ctor git bisect bad 2379f36bd809c3cf3be71315a85946e273023a8c # good: [d458adeed0c34fae26fe7f3d6ecc9b75b431922f] Simplify Sequence iterations in sd git bisect good d458adeed0c34fae26fe7f3d6ecc9b75b431922f
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?
(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
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.
(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
(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
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?
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
(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.
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
Created attachment 170321 [details] Screenshot showing version I am testing with
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
(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
(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
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 ***