Description: Writer exports the attached ODT document to PDF replacing images with copies of some first images in the document. When I spotted the problem first, the generated PDF contained only the first inserted image and its copies. In the attached example both images from page 1 get copied to page 2, replacing the correct images. Attached files: ODT and exported PDF + 4 screenshots. Screenshots show: shot1 - the ODT open in Writer shot2 - options selected for export to PDF (basically none) shot3 - the exported PDF shot4 - information about my installed LibreOffice Steps to Reproduce: 1. Open the attached ODT. 2. Export PDF. Actual Results: PDF with incorrect images Expected Results: PDF with correct images Reproducible: Always User Profile Reset: No Additional Info: The images have been generated in Octave under Linux, exported as EPS files. Then these EPSes were inserted into ODT document open in Writer, and the option "compress" has been used to convert them into raster images. The exported PDF looks the same in PDF XChange Viewer, Acrobat Reader (both under Windows) and Okular (under Linux). User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
Created attachment 133126 [details] ODT file with 4 images
Created attachment 133127 [details] exported PDF
Created attachment 133128 [details] shot1: ODT document open in Writer
Created attachment 133129 [details] shot2: options selected for export to PDF (basically none)
Created attachment 133130 [details] shot3: the exported PDF
Created attachment 133131 [details] shot4: LO version
Not reproducible for me with LibreOffice 5.3.4.0.0+ built at home under Ubuntu 16.04 x86-64. Version: 5.3.4.0.0+ Build ID: 2e20df6eb9fe206b89d5eecbf88eea54d0719268 Threads CPU : 4; Version de l'OS :Linux 4.4; UI Render : par défaut; VCL : gtk3; Moteur de mise en page : nouveau; Ubuntu_16.04_x86-64 Locale : fr-FR (fr_FR.UTF-8); Calc: single Best regards. JBF
More checks: Linux (Debian) LibreOffice 5.2.6 works correctly Linux (Debian) LibreOffice 5.0.1 works correctly a second computer with Windows, LibreOffice 5.3.2, the problem appears
I reproduce only when I use "Lossless compression" with LO 5.3.2.2 Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1 Threads CPU : 2; Version de l'OS :Windows 6.1; UI Render : par défaut; Moteur de mise en page : nouveau; Locale : fr-FR (fr_FR); Calc: CL and LO 5.4.0.0.alpha1+ Build ID: 0025fc13d805751f8eeb14febbdd0033e0a6d91e CPU threads: 2; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@39, Branch:master, Time: 2017-05-04_05:21:32 Locale: fr-FR (fr_FR); Calc: CL This feature has changed between LO 5.0.2.1 Build ID: 9a18d52abbdfbdc2ac9acebec2b92e7859eb73b7 Locale : fr-FR (fr_FR) and LO 5.0.1.2 Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale : fr-FR (fr_FR), which export 4 images. under Windows 7 Home.
This seems to have begun at the below commit. Adding Cc: to Marco Cecchetti; Could you possibly take a look at this one? Thanks 15dea7253f57cac001cf1a730b8ed748dda1107a is the first bad commit commit 15dea7253f57cac001cf1a730b8ed748dda1107a Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Tue Sep 1 22:21:05 2015 -0700 source ebb0dc14547e698d7b53005178063da72d48f075 author Marco Cecchetti <marco.cecchetti@collabora.com> 2015-08-26 11:50:57 (GMT) committer Michael Meeks <michael.meeks@collabora.com> 2015-09-01 15:28:45 (GMT) commit ebb0dc14547e698d7b53005178063da72d48f075 (patch) tree 8cf95d717f32672dc8e6ecf9f6b743227ada889f parent 7cc4cdc5ef6dff279e072af725c2d7fc1e5da0e8 (diff) Added support for computing 64-bit checksum of bitmap in OpenGL
Note that the bug only occurs with default rendering, and not if OpenGL is enabled.
A patch is available on gerrit: master: https://gerrit.libreoffice.org/#/c/38165/ Some notes for who is interested in the whole story: The debbugging session performed didn't point out anything interesting, moreover the debug log performed in BitmapEx.GetChecksum showed different checksums for each one of the 4 bitmaps, and since in the checksum computation is included the alpha channel too, it masked the fact that ImpBitmap::GetChecksum returned 0. Fortunately Aron noticed that by copying the removed code (old implementation) in Bitmap::GetChecksum when nRet == 0, the exported PDF was correct and that the checksum was 0 with the new implementation and != 0 with the old one. After a bit of investigation I found out that the difference was due to the buffer acquire methods: in Bitmap::Checksum (old implementation) Bitmap::AcquireReadAccess is used to get the bitmap buffer: indeed this method relies on SalBitmap::AcquireBuffer (which is used in the new implementation) but in case the buffer acquisition fails, instead of giving up, it tries to update the imp bitmap instance embedded in the bitmap (see BitmapInfoAccess::ImplCreate). The solution is to perform this further attemp in Bitmap::Checksum when the value returned by ImpBitmap::GetChecksum is 0.
Marco Cecchetti committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6a01c2d4cab8c3f1a4ba61e7c4e049771612127e tdf#107682 - Repeated images replace correct ones in exported PDF It will be available in 5.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Marco Cecchetti committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=83bd801268203a28a47bafd17307c13fbc41e983&h=libreoffice-5-3 tdf#107682 - Repeated images replace correct ones in exported PDF It will be available in 5.3.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Marco Cecchetti committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=23ee2d252e4e026657e9b52e5c9132ca201ac43e&h=libreoffice-5-4 tdf#107682 - Repeated images replace correct ones in exported PDF It will be available in 5.4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
No issue has been reported about my patch in 2 weeks. So I think that's fine to close this bug.