[Libreoffice-bugs] [Bug 107682] Repeated images replace correct ones in exported PDF ( with default rendering only)

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=107682

Marco Cecchetti <mrcekets at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmiklos at collabora.co.uk

--- Comment #12 from Marco Cecchetti <mrcekets at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20170529/8fe99f74/attachment.html>