Description: I generated reports from the OS genealogy software "Gramps" and notices that cropped images would appear wrongly when using the ODF exported and viewing them on screen. To my surprise, when exporting the ODF document to PDF, things would look differently again. I cannot say if the on-screen display is wrong or the LibreOffice PDF export, but certainly there must not be any difference. Steps to Reproduce: (Optional) You can generate the attached test document as following: 1. Install Gramps 4.2.6 (latest stable at time of writing) 2. In a new test family tree, create a person. 3. To the gallery of this person add the following three images (in this order) and crop each of them to the traffic sign: - E12599 - Testbild.JPG - An out-of-camera image claiming to have 72 dpi. Unfortunately the image library used by Gramps is not able to determine this image's resolution correctly, thus applying 96 dpi, which results in wrong crop on screen. - E12599 - Testbild (96dpi).JPG - Same image with metadata set to 96 dpi in Faststone Image Viewer. (96 dpi is the Gramps fallback resolution.) - E12599 - Testbild (72dpi recoded).JPG. A copy of the original image, saved without metadata by re-compressing it. Gramps correctly recognizes the 72 dpi when converting the crop from pixels to inches. 4. In Gramps, export the person as "Reports -> Text reports -> Individual Complete" and chose the "OpenDocument Text" exporter. With the created (or attached) test document, do the following: 5. Open the document in writer. Notice that the first image of the gallery is distorted (the out-of-camera JPG), the second and third are not. 6. Export this document to PDF (from LO) with following settings (not sure they are relevant, but anyway): 92% JPG quality, no image resolution reduction, PDF/A-1a 7. Open the PDF in Acrobat Reader DC. Actual Results: In PDF export the first cropped image is correct and the second is distorted - the opposite of what was the case on screen. It seems to me there are two effects involved: - A problem in Gramps ODF export due to the inability to read out the first image's correct resolution of 72 dpi. (At least this is my interpretation. See Gramps bug https://gramps-project.org/bugs/view.php?id=10339) - A problem in LibreOffice PDF exporter which seeminlgy cancels out the first issue, but creates a new issue with the second image (the one having 96 dpi). Expected Results: The PDF should have looked like the document in LibreOffice itself (on screen). Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 5.2.1.2 Build-ID: 31dd62db80d4e60af04904455ec9c9219178d620 CPU-Threads: 4; BS-Version: Windows 6.1; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 138811 [details] Image 1: Out of camera JPG (72 dpi)
Created attachment 138812 [details] Image 2: Same image, but metadata set to 96 dpi
Created attachment 138813 [details] Image 3: Recoded copy without EXIF metadata (72 dpi)
Created attachment 138814 [details] Report created by Gramps 4.2.6 using ODF exporter
Created attachment 138815 [details] Same report, converted to PDF in LibreOffice 5.2
Can you create an ODT with the same problem purely inside LibreOffice? Otherwise this is pretty much not our bug.
(In reply to Buovjaga from comment #6) I don't think it's this easy. The question is not if the document was created inside LO or not, the question is imho rather whether this document in question is valid in respect to the OpenDocument format. If it is valid it should be read correctly no matter what its source is. Besides, I was easily able to create a document in LibreOffice, which also shows a difference between display and PDF export. Your bug, clearly.
Created attachment 139439 [details] Document created within LO, containing all three previously attached images, each cropped to the sign. PDF export of it is incorrect.
(In reply to Matthias Basler from comment #8) > Created attachment 139439 [details] > Document created within LO, containing all three previously attached images, > each cropped to the sign. PDF export of it is incorrect. Thanks, I repro. In 3.6 it is fine. Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: 73c757ff71b6bf14206adf13a65213c79928a592 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Built on January 30th 2018 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
This now works in master! Version: 6.2.0.0.alpha0+ (x64) Build ID: a8f8cf72b2b9e912dc4a5aebef55d9b2c0969462 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-30_15:31:15 Locale: fi-FI (fi_FI); Calc: group threaded
I tried to read the Gramps report in LibreOffice 6.04, but after scrolling to the second page, Writer crashed. I tried it twice, it happened both times. I submitted the crash report.
> This now works in master! > Version: 6.2.0.0.alpha0+ (x64) Are there any chances the responsible bug fix gets backported to the 6.1 or 6.0 branch? (I spent literally hours working around this bug today on the current LO 6.0.5.) P.S. Is "WORKSFORME" really the right solution here? It did not work on the version it was reported for but obviously was fixed since. (I did not yet test 6.2 alpha myself.)
I re-tested both attached documents in LO6.1.0 beta2 and the released LO 6.0.5 on Win64 and both worked for me there too with respect to PDF export. (So ignore my above question about backporting ...) What still does not work is the correct import of such documents (containing cropped OOC photos) created from Gramps. Obviously this is a separate issue which should be tackled in a separate ticket.