Bug 107682 - Repeated images replace correct ones in exported PDF (with default rendering only)
Summary: Repeated images replace correct ones in exported PDF (with default rendering ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.2.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: target:5.5.0 target:5.3.4 target:5.4.0.1
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2017-05-07 14:07 UTC by Adam
Modified: 2017-06-19 18:31 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
ODT file with 4 images (203.84 KB, application/vnd.oasis.opendocument.text)
2017-05-07 14:09 UTC, Adam
Details
exported PDF (1.15 MB, application/pdf)
2017-05-07 14:12 UTC, Adam
Details
shot1: ODT document open in Writer (216.82 KB, image/png)
2017-05-07 14:13 UTC, Adam
Details
shot2: options selected for export to PDF (basically none) (59.22 KB, image/png)
2017-05-07 14:14 UTC, Adam
Details
shot3: the exported PDF (235.98 KB, image/png)
2017-05-07 14:15 UTC, Adam
Details
shot4: LO version (49.43 KB, image/png)
2017-05-07 14:15 UTC, Adam
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam 2017-05-07 14:07:39 UTC
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
Comment 1 Adam 2017-05-07 14:09:23 UTC
Created attachment 133126 [details]
ODT file with 4 images
Comment 2 Adam 2017-05-07 14:12:37 UTC
Created attachment 133127 [details]
exported PDF
Comment 3 Adam 2017-05-07 14:13:40 UTC
Created attachment 133128 [details]
shot1: ODT document open in Writer
Comment 4 Adam 2017-05-07 14:14:27 UTC
Created attachment 133129 [details]
shot2: options selected for export to PDF (basically none)
Comment 5 Adam 2017-05-07 14:15:03 UTC
Created attachment 133130 [details]
shot3: the exported PDF
Comment 6 Adam 2017-05-07 14:15:37 UTC
Created attachment 133131 [details]
shot4: LO version
Comment 7 Jean-Baptiste Faure 2017-05-07 16:45:21 UTC
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
Comment 8 Adam 2017-05-07 20:43:38 UTC
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
Comment 9 Jacques Guilleron 2017-05-08 14:37:12 UTC
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.
Comment 10 raal 2017-05-13 16:13:41 UTC
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 sha: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
Comment 11 Aron Budea 2017-05-26 00:32:22 UTC
Note that the bug only occurs with default rendering, and not if OpenGL is enabled.
Comment 12 Marco Cecchetti 2017-05-29 20:17:04 UTC
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.
Comment 13 Commit Notification 2017-05-30 16:08:30 UTC
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.
Comment 14 Commit Notification 2017-05-30 16:09:52 UTC
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.
Comment 15 Commit Notification 2017-05-30 16:10:07 UTC
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.
Comment 16 Marco Cecchetti 2017-06-19 18:31:32 UTC
No issue has been reported about my patch in 2 weeks. So I think that's fine to close this bug.