Download it now!
Bug 117059 - PDF created show wrong images (OK with print to PDF)
Summary: PDF created show wrong images (OK with print to PDF)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
5.4.5.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, regression
: 117156 (view as bug list)
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2018-04-17 08:58 UTC by Olivier Marti
Modified: 2019-01-14 12:34 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Original Impress, and resulting PDF (1.06 MB, application/zip)
2018-04-17 09:00 UTC, Olivier Marti
Details
How it looks in LibreOffice 5.4 (deleted)
2018-04-18 16:02 UTC, Xisco Faulí
Details
How it looks in LibreOffice 5.2 (145.21 KB, application/pdf)
2018-04-18 16:03 UTC, Xisco Faulí
Details
How it looks in LibreOffice 6.1 master (603.47 KB, application/pdf)
2018-04-18 16:04 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Marti 2018-04-17 08:58:25 UTC
Description:
A simple Impress document with one page. PNG images inserted shows wrongly when saved in PDF

Steps to Reproduce:
1. Mac screen capture in PNG format
2. Crop images with Preview
3. Insert in LibreOffice Impress
4. Crop images
5. Export in PDF

Actual Results:  
The PDF shows a part of the image which does not appear in the Impress file.

Expected Results:
LibreOffice and PDF should show the same


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:


User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1 Safari/605.1.15
Comment 1 Olivier Marti 2018-04-17 09:00:31 UTC
Created attachment 141419 [details]
Original Impress, and resulting PDF
Comment 2 V Stuart Foote 2018-04-17 16:13:38 UTC
Confirmed on Windows 10 Ent 64-bit en-US with
Version: 6.0.3.1 (x64)
Build ID: 62abb169b0efa1520d7bee1f586865354060b989
CPU threads: 8; OS: Windows 10.0; UI render: default; 
Locale: en-US (en_US); Calc: group

The Impress ODP has both PNG and PDF images embedded. When printing via gs the PNG are used. On export to PDF, the embedded PDF are used--but get mangled.

Extracting the embedded PDF, they all view (Adobe Reader) as expected. The PDF Producer is listed as: MAC OS X 10.12.6 Quartz PDF Context.

But on editing (Acrobat), each chart is a crop out from a larger part of a PDF that is still intact in the ODF.

I'd lean toward =>NOB bcz the Quartz generated PDF is corrupt and needs to be cleaned before use. But I'm not sure if we are expecting more robust handling when inserting cropped PDF and how we guard for the cropping extents.

@Miklos?
Comment 3 Miklos Vajna 2018-04-18 07:09:04 UTC
`pdfcrop` from tex is something I tested in the past, that was working fine within LO. How do you know that generated PDF is corrupt, do you have the validation result from https://www.pdf-online.com/osa/validate.aspx or some other PDF validator?
Comment 4 V Stuart Foote 2018-04-18 13:11:02 UTC
(In reply to Miklos Vajna from comment #3)
> `pdfcrop` from tex is something I tested in the past, that was working fine
> within LO. How do you know that generated PDF is corrupt, do you have the
> validation result from https://www.pdf-online.com/osa/validate.aspx or some
> other PDF validator?

No, sorry I was not clear. Corrupt in the sense that when exported back to PDF the cropping window for each embedded PDF image has the correct dimension, but is misplaced from its original.  So is that an internal of the OS X cropping to PDF (and maybe NOB), or something we need to adjust in LO's PDF export filter to correct location of the cropped element?

Guess when I get a moment I'll check if after restoring the full PDFs, i.e. reversing the cropping, I can use a different PDF editor to crop out each chart and then recompose the Impress slide. And then export it from LibreOffice as PDF to see if there is a better result.
Comment 5 Xisco Faulí 2018-04-18 16:02:51 UTC Comment hidden (obsolete)
Comment 6 Xisco Faulí 2018-04-18 16:03:31 UTC
Created attachment 141467 [details]
How it looks in LibreOffice 5.2
Comment 7 Xisco Faulí 2018-04-18 16:04:07 UTC
Created attachment 141468 [details]
How it looks in LibreOffice 6.1 master
Comment 8 Xisco Faulí 2018-04-18 16:14:18 UTC Comment hidden (obsolete)
Comment 9 Xisco Faulí 2018-04-18 16:15:56 UTC
Before https://cgit.freedesktop.org/libreoffice/core/commit/?id=1ec8557d86d53c9df5afd5607a953ec72c33702f, it was exported as displayed in attachment 141467 [details], then the export is broken for some commits, and finally it works again after https://cgit.freedesktop.org/libreoffice/core/commit/?id=242a9b634213acf03cabc373928555dc81afc672, when the output is already incorrect
Comment 10 V Stuart Foote 2018-04-23 02:43:36 UTC
*** Bug 117156 has been marked as a duplicate of this bug. ***
Comment 11 Timur 2019-01-14 11:21:48 UTC
Repro 6.3+.