Bug 129085 - From version 6.1.x, some JPG images in Writer not printed
Summary: From version 6.1.x, some JPG images in Writer not printed
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Windows (All)
: high critical
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
: 132364 (view as bug list)
Depends on:
Blocks: Print
  Show dependency treegraph
Reported: 2019-11-28 18:54 UTC by Martin Schoenmakers
Modified: 2020-05-18 07:21 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

The problematic document with the 4 images. (156.50 KB, application/msword)
2019-11-28 19:04 UTC, Martin Schoenmakers
The resulting print (pdf made via Print - Microsoft Print to PDF (213.80 KB, application/pdf)
2019-11-28 19:06 UTC, Martin Schoenmakers
Test pdf (76.32 KB, application/pdf)
2019-11-28 19:19 UTC, Julien Nabet

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Schoenmakers 2019-11-28 18:54:37 UTC
I have ~100 invoices with 4 images (logos etc). Up until version, these print perfectly OK. 
Now upgraded to version 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, 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 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.
Comment 1 Martin Schoenmakers 2019-11-28 19:04:28 UTC
Created attachment 156171 [details]
The problematic document with the 4 images.
Comment 2 Martin Schoenmakers 2019-11-28 19:06:09 UTC
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.
Comment 3 Julien Nabet 2019-11-28 19:19:47 UTC
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
Comment 4 Julien Nabet 2019-11-28 19:21:34 UTC Comment hidden (obsolete)
Comment 5 Martin Schoenmakers 2019-11-30 10:10:16 UTC Comment hidden (obsolete)
Comment 6 Julien Nabet 2019-11-30 11:17:17 UTC Comment hidden (obsolete)
Comment 7 Dieter 2019-12-02 07:11:25 UTC
Martin, which printer do you use? Have you checked, that the printer driver is actual?
Comment 8 Timur 2019-12-02 08:06:23 UTC
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.
Comment 9 Martin Schoenmakers 2019-12-02 08:23:25 UTC
(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.
Comment 10 Telesto 2020-01-10 22:12:30 UTC
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)

Comment 11 Telesto 2020-01-10 22:13:13 UTC
Adding CC to: Armin Le Grand
Comment 12 Timur 2020-05-18 07:20:48 UTC
*** Bug 132364 has been marked as a duplicate of this bug. ***