Description: I have ~100 invoices with 4 images (logos etc). Up until version 6.1.1.2, these print perfectly OK. Now upgraded to version 6.3.3.2: one image prints, 3 images do not print (in all of those documents that earlier printed fine). I tested this on Win7(64) and Win10(64), and also tested version 6.2.8. Exporting to a PDF does show the images as expected. This is a workaround: printing the PDF works fine. Steps to Reproduce: I have also tried de-installing that new 6.3.3.2, removing all stuff in ...\Roaming\..., still same result. I have also tried changing Settings-LibreOffice-View-Use OpenGL to not checked, still same. De-installing the new version and then installing the old 6.1.1.2 completely solves the problem. Actual Results: Topmost logo is printed, 3 images at the bottom do not print. Expected Results: Print all 4 images. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: The user profile can not be the cause, as I tested this also on a PC with no former installation of LibreOffice.
Created attachment 156171 [details] The problematic document with the 4 images.
Created attachment 156172 [details] The resulting print (pdf made via Print - Microsoft Print to PDF The paper-prints look the same as this PDF: 3 bottom images missing.
Created attachment 156173 [details] Test pdf On pc Debian testing x86-64 with master sources updated today, I don't reproduce this. I attached pdf example where the 3 logos are present at the end. Idem with LO Debian package 6.3.3.2
Perhaps Windows only bug. For the test, could you: - follow advice from https://wiki.documentfoundation.org/QA/FirstSteps - give a try at a daily build from master sources (future 6.5.0): https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/current/ ?
(In reply to Julien Nabet from comment #4) > Perhaps Windows only bug. > > For the test, could you: > - follow advice from https://wiki.documentfoundation.org/QA/FirstSteps I believe I have tried all those steps, as described above. > - give a try at a daily build from master sources (future 6.5.0): > https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/current/ Done that: installed v.6.5.0.0.alpha0_Win_x64.msi, and print with LibreOfficeDev Writer. Result: same problem.
(In reply to Martin Schoenmakers from comment #5) > (In reply to Julien Nabet from comment #4) > > Perhaps Windows only bug. > > > > For the test, could you: > > - follow advice from https://wiki.documentfoundation.org/QA/FirstSteps > I believe I have tried all those steps, as described above. Indeed! Sorry for this > > - give a try at a daily build from master sources (future 6.5.0): > > https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/current/ > Done that: installed v.6.5.0.0.alpha0_Win_x64.msi, > and print with LibreOfficeDev Writer. > Result: same problem. Thank you for your feedback. I don't have more questions so put back to UNCONFIRMED. For the rest, I must recognize I'm stuck.
Martin, which printer do you use? Have you checked, that the printer driver is actual?
Reproduced in Windows, LO 6.1.6, 6.2.8 and 6.5+ with Print to PDF. No repro for me in 6.0 and for reporter in 6.1.1 so regression. Looks like some backport to 6.1 went awry. Print Preview and preview in Print are fine in 6.5+ (but preview in Print is wrong in 6.1.6). Export to PDF is also fine.
(In reply to Dieter Praas from comment #7) > Martin, which printer do you use? Have you checked, that the printer driver > is actual? I use a HP Officejet Pro 276. (I just went from Win7 to Win10, so it has a brand new driver.) But 99% sure this is not relevant: when printing to PDF via "Microsoft print to PDF", then there is the same problem, same as Timur sees in Comment 8.
Bisected to 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 By error the ClipRegion's geometry was replaced by it's BoundRect expanded to PixelBounds. If the ClipRegion is not a rectangle, this will create wrong results. To do both - extend to PixelBounds and have the original geometry included - use the PolyPolygon topology as needed (see comment in code for details) https://cgit.freedesktop.org/libreoffice/core/commit/?id=362c1cf2bd580f6dc8bf27bdcd79174111bc1b5c
Adding CC to: Armin Le Grand
*** Bug 132364 has been marked as a duplicate of this bug. ***
*** Bug 128358 has been marked as a duplicate of this bug. ***
Bug 128358 was bibisected to commit c2ae30b19d8145271f1189c9757d59d43de391c7 from the same bug 124272
Xisco, I think this one is for ESC, to see if someone can be pointed to this bug or regression commits reverted.
*** Bug 138115 has been marked as a duplicate of this bug. ***
Main bug 129085 has DOC attachment 156171 [details] where JPG images with Tight wrap are not printed (they are exported). Same for MSO-created DOCX. Marked duplicate bug 128358 has ODT attachment 155308 [details] with wrap Parallel + Contour header PNG image not printed (they are exported). Prints OK if Wrap changed to None or Optimal, Before, After. Duplicate bug 132364 has DOCX attachment 159873 [details] (regardless it's 2007, same if resaved) that prints none of Tight wrap JPG images and doesn't PDF export some (where caption starts with 'Becher'). Noted that images, which have got style "fr1" will be printed, but all images, which have got style "fr2", "fr3" and "fr4" will not print. Also NOK with Wrap change in LO. OK with wrap change in MSO. Bug 138115 has DOCX attachment 167171 [details] with Tight wrap PNG images seen in LO with wrap Parallel + Contour, images not printed nor exported to PDF. Also NOK with wrap change in LO. OK with wrap change in MSO. Based on all this, I change the title from "JPG images" to "images with specific wrap" (thanks to bug 138115). Print and Export are not always the same, but we should keep all here. Print bug already seen in File-Print preview (not in Print Preview). Repro 7.1+. Also in Linux so All OS.
*** Bug 137056 has been marked as a duplicate of this bug. ***
*** Bug 138515 has been marked as a duplicate of this bug. ***
*** Bug 139639 has been marked as a duplicate of this bug. ***
*** Bug 140426 has been marked as a duplicate of this bug. ***
Hi Armin, I noticed you are back here after a long time. I hope you're well and fine. I see you're working on some other bugs but please note this one is critical,when Print nor Export don't work. I asked before for a revert, nor knowing about that fix, but it seems much less problematic than this one.
Hi Timur, reverting would re-introduce tdf#114076, also bad. The code is correct, but a complex PolyPolygon as used here may lead to problems in print(?) output... Is there a simplified bugdoc with just one image or so...?
Created attachment 169960 [details] Coverpage - Image left corner not printed properly
Loaded doc, - Print Preview -> OK - Export PDF -> OK - PrintToFile (also PDF, but using printer) -> OK Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 7ba76115b0e3baefae0ede66848f4340c7c7401b CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Could not reproduce, what do I need to do..?
Same using Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 3836c43963af1c99bcb9f9ab20f745d29b8c80fc CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL
Armin, if you prefer a single image file with no other text, please see ODT attachment 169775 [details] (dupl. bug 140426). Comment 24 attachment is another issue, not this bug. Print bug already seen in File-Print preview (not in Print Preview)! Main bug 129085 has DOC attachment 156171 [details] where 3 bottom JPG images with Tight wrap are not printed (they are exported). Same for MSO-created DOCX. Marked duplicate bug 128358 has ODT attachment 155308 [details] with wrap Parallel + Contour header PNG image not printed (they are exported). Prints OK if Wrap changed to None or Optimal, Before, After. Duplicate bug 132364 has 17-images DOCX attachment 159873 [details] (regardless it's 2007, same if resaved) that prints *none* of Tight wrap JPG images and doesn't PDF export some (where caption starts with 'Becher'). Noted that images, which have got style "fr1" will be printed, but all images, which have got style "fr2", "fr3" and "fr4" will not print. Also NOK with Wrap change in LO. OK with wrap change in MSO. Bug 138115 has DOCX attachment 167171 [details] with 2 Tight wrap PNG images seen in LO with wrap Parallel + Contour, images not printed nor exported to PDF. Also NOK with wrap change in LO. OK with wrap change in MSO. Duplicate bug 139639 has ODT attachment 168908 [details] with JPG image and some text, image not printed nor exported to PDF. Duplicate bug 140426 has ODT attachment 169775 [details] with a single PNG image and no text.
Hi Timur - thanks a lot, I *did* mix up print/Preview with the Preview in the Print-Dialog. Indeed, there it *is* missing. Can now reproduce using 'attachment 169775 [details]' in Print dialog preview *and* missing in Print_to_file -> PDF, too. Will take a look...
(In reply to Armin Le Grand from comment #28) > Hi Timur - thanks a lot, I *did* mix up print/Preview with the Preview in > the Print-Dialog. Indeed, there it *is* missing. > Can now reproduce using 'attachment 169775 [details]' in Print dialog > preview *and* missing in Print_to_file -> PDF, too. Will take a look... Hi Timur, Armin, This should fix this issue < https://gerrit.libreoffice.org/c/core/+/112340 > since the commit introducing this issue would be reverted...
(In reply to Xisco Faulí from comment #29) > (In reply to Armin Le Grand from comment #28) > > Hi Timur - thanks a lot, I *did* mix up print/Preview with the Preview in > > the Print-Dialog. Indeed, there it *is* missing. > > Can now reproduce using 'attachment 169775 [details]' in Print dialog > > preview *and* missing in Print_to_file -> PDF, too. Will take a look... > > Hi Timur, Armin, > This should fix this issue < https://gerrit.libreoffice.org/c/core/+/112340 > > since the commit introducing this issue would be reverted... I've also added a unittest in https://gerrit.libreoffice.org/c/core/+/112342
*** Bug 139124 has been marked as a duplicate of this bug. ***
*** Bug 126313 has been marked as a duplicate of this bug. ***
Xisco, congrats and thanks for test. I wish it was sooner, per Comment 15. Really visible, will you be able to backport to 7.0?
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f4f6ec04544059910ab5ec47817fad2287dd3f5a tdf#129085: vcl_pdfexport: Add unittest It will be available in 7.2.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.
The commit causing this issue has been reverted in https://cgit.freedesktop.org/libreoffice/core/commit/?id=2e334998f4a821ea05ce25dc6346b556bcb1347b Please, test it with a daily build.
I tested duplicates, ok. I see backport to 7.1 waiting for review. Julien, if you see this, can you put +1? Hoping for backport to 7.0
(In reply to Timur from comment #37) > I tested duplicates, ok. I see backport to 7.1 waiting for review. > Julien, if you see this, can you put +1? > Hoping for backport to 7.0 Backport for 7.1 already merged, see https://gerrit.libreoffice.org/c/core/+/112398
(In reply to Julien Nabet from comment #38) > (In reply to Timur from comment #37) > > I tested duplicates, ok. I see backport to 7.1 waiting for review. > > Julien, if you see this, can you put +1? > > Hoping for backport to 7.0 > > Backport for 7.1 already merged, see > https://gerrit.libreoffice.org/c/core/+/112398 For backport 7.0, I put Armin and Caolán in cc since they had already approved 7.1 backport. Anyway at worst, there's only 7.0.6 remaining for 7.0 branch according to https://wiki.documentfoundation.org/ReleasePlan/7.0
thanks Julien for all. When I asked, I saw it waiting for a few days, and this is the last period to backport to 7.0. I guess there are folks like me, who use Still.Last for work so it's important to have this in 7.0.6. I encountered this bug few times, was annoying.