Bug 56808 - particular OLE + PNG Picture contents not displayed, only white area
Summary: particular OLE + PNG Picture contents not displayed, only white area
Status: RESOLVED DUPLICATE of bug 55044
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
4.0.0.0.alpha0+ Master
Hardware: x86 (IA32) Windows (All)
: medium critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
: 58140 (view as bug list)
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2012-11-06 14:22 UTC by Pedro
Modified: 2012-12-21 18:54 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
OLE picture contained in an ODT document (16.34 KB, application/vnd.oasis.opendocument.text)
2012-11-06 14:22 UTC, Pedro
Details
screenshot in 3.6.3.2 - this is expected (88.88 KB, image/png)
2012-11-11 17:14 UTC, Korrawit Pruegsanusak
Details
extracted wmf (29.82 KB, image/x-wmf)
2012-11-23 14:32 UTC, Caolán McNamara
Details
PNG file from an ODT document (2.17 KB, image/png)
2012-12-07 12:22 UTC, s-joyemusequna
Details
11 out of 30 pictures are not visible, but they are embedded in the file (671.48 KB, application/vnd.oasis.opendocument.text)
2012-12-07 12:41 UTC, s-joyemusequna
Details
Some more pictures (535.88 KB, application/zip)
2012-12-11 14:11 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pedro 2012-11-06 14:22:16 UTC
Created attachment 69627 [details]
OLE picture contained in an ODT document

An OLE picture (not a bitmap image) in an ODT file does not display correctly under LO 3.7 alpha. This is a regression from 3.6

The version used was Version 3.7.0.0.alpha0+ (Build ID: 1b61693)
from http://dev-builds.libreoffice.org/daily/Win-x86@6/master/
master~2012-11-04_23.17.14_LibO-Dev_3.7.0.0.alpha0_Win_x86_install_en-US

See attached document for an example.
Comment 1 Korrawit Pruegsanusak 2012-11-11 17:12:51 UTC
Confirmed on Win7 64bit, with build from W2008R2@16-minimal_build, pull time 2012-11-09 00:53:19, core: 70ec826eeb8f0b311095869e23be1db95fc9d109. Document showed white page, blank OLE objects.

NOT reproduced with official 3.6.3.2 on same system. The OLE objects showed as in attachment => regression confirmed
Comment 2 Korrawit Pruegsanusak 2012-11-11 17:14:25 UTC
Created attachment 69906 [details]
screenshot in 3.6.3.2 - this is expected
Comment 3 Korrawit Pruegsanusak 2012-11-11 17:58:06 UTC
regression introduced between pull time 2012-06-27 04:02:20 (core: 3f135598fd508e70f31f36cd8a8d7a61ccf4ff79) and 2012-07-15 01:33:34 (core: 146b507f9f52daa7378aaeddf6725b9ab129af61)
Comment 4 Caolán McNamara 2012-11-23 14:12:23 UTC
works under Linux, fails under windows
Comment 5 Caolán McNamara 2012-11-23 14:32:26 UTC
Created attachment 70478 [details]
extracted wmf

With the attached extracted wmf:
a) in draw, insert picture from file works fine
b) in writer, insert picture from file reproduces the problem
Comment 6 Caolán McNamara 2012-11-23 15:48:24 UTC
The oldest windows bibisect commit id in git clone git://gandalf.documentfoundation.org/bibisect_windows is 5dbbe223c8586bd653685d27c664aa8395632e4a and that's busted. Presumably e74c007e25d05e49d94a94d9b024076faa02c8d0 (the last commit to master before the 3-6 branchpoint) is the other bound of the regression area
Comment 7 Korrawit Pruegsanusak 2012-11-30 21:38:26 UTC
Caolan, thanks for testing and info. :-)

Anyway, it seems my comment 3 isn't understandable. I meant that: these two commits in comment 3 are already the upper and lower bounds.
Comment 8 s-joyemusequna 2012-12-07 12:22:54 UTC
Created attachment 71124 [details]
PNG file from an ODT document

Same problem as in Comment 5, but the file is a PNG. I think, it is probably the same bug.

With the attached extracted PNG:
a) in draw, insert picture from file works fine
b) in writer, insert picture from file reproduces the problem
Comment 9 s-joyemusequna 2012-12-07 12:41:56 UTC
Created attachment 71125 [details]
11 out of 30 pictures are not visible, but they are embedded in the file

In this file, 11 pictures out of 30 are not displayed (1 picture on page 17: part of upper left corner is displayed). I have *many* files with this problem (i.e. missing pictures). If I print the file, everything is OK. If saved as PDF, everything is OK. Page preview is *not* OK, the pictures are invisible. When I right-click the invisible picture (Picture.../[Picture]), the picture is displayed in the dialog.

Tested with Version 4.0.0.0.alpha1+ (Build ID: ac4d26e3fc2728ee80f33a485540d50b48927dd), 2012.12.03 under Windows XP and Vista 64. 

It works with LibO 3.6.3.

I think, this is a blocker under Windows.
Comment 10 Rainer Bielefeld Retired 2012-12-11 14:07:12 UTC
*** Bug 58140 has been marked as a duplicate of this bug. ***
Comment 11 Rainer Bielefeld Retired 2012-12-11 14:10:05 UTC
All effects in "Bug 58140 - VIEWING: particular .png pictures shown as empty area"
are identical, but with WMF from this bug the effect that the visible picture in Calc becomes invisible in Writer can not be reproduced.

I wonder whether those pictures / objects have had that problem from the beginning or whether it started with the integration into the Writer document in an oder version?
Comment 12 Rainer Bielefeld Retired 2012-12-11 14:11:51 UTC
Created attachment 71339 [details]
Some more pictures

I extracted these pictures from sample.docx of "ug 58140 - VIEWING: particular .png pictures shown as empty area". Pictures with names ending with "NOT.png" show the bug.
Comment 13 Korrawit Pruegsanusak 2012-12-15 00:11:30 UTC
Bisected, and the first bad commit is:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c0ce7ca4884f7f6d1016bd1dbcc22066cb4a7797

> commit c0ce7ca4884f7f6d1016bd1dbcc22066cb4a7797
> Author: Tomaž Vajngerl <quikee@gmail.com>
> Date:   Sat Jul 7 13:07:03 2012 +0200
> 
>     Prescale image with Bitmap::Scale to improve quality.

To build on Windows at 1/ this commit or 2/ its parent commit, you should do
    git cherry-pick 41c1ecbf0a95a6a18d45ff35c18cd5a516019de0
for fixing broken build first.

CC'ing author: Tomaž, could you please have a look at this? Thanks :)
Comment 14 Korrawit Pruegsanusak 2012-12-15 00:19:25 UTC
Checked with c0ce7ca4884f7f6d1016bd1dbcc22066cb4a7797 (first bad commit), on Windows 7 x64, I can confirm that the first bad commit breaks the followings, comparing with the commit's parent:

* attachment 69627 [details] (comment 0)
* attachment 70478 [details] (breaks behaviour described in comment 5)
* attachment 71124 [details] (breaks behaviour described in comment 8)
* attachment 71334 [details] (from bug 58140 that is a duplicate of this bug)

For attachment 71125 [details] from comment 9, it crashed libo in both first bad commit and its parent, so I can't check if the first bad commit breaks it.

For attachment 71339 [details] from comment 12, I didn't check it.
Comment 15 Korrawit Pruegsanusak 2012-12-15 00:24:57 UTC
Looking at the first bad commit, the only significant change (excluding sal_Bool to bool) is:

> @@ -717,13 +701,24 @@ void OutputDevice::ImplDrawBitmap( const Point& rDestPt, const Size& rDestSize,
>              }
>  
>              if ( aPosAry.mnSrcWidth && aPosAry.mnSrcHeight && aPosAry.mnDestWidth && aPosAry.mnDestHeight )
> +            {
> +                const double nScaleX = aPosAry.mnDestWidth  / static_cast<double>( aPosAry.mnSrcWidth );
> +                const double nScaleY = aPosAry.mnDestHeight / static_cast<double>( aPosAry.mnSrcHeight );
> +                // If subsampling, use Bitmap::Scale for subsampling for better quality.
> +                if ( meOutDevType != OUTDEV_PRINTER &&
> +                    nAction == META_BMPSCALE_ACTION &&
> +                    (nScaleX < 1.0 || nScaleY < 1.0) )
> +                {
> +                    aBmp.Scale ( nScaleX, nScaleY );
> +                    aPosAry.mnSrcWidth = aPosAry.mnDestWidth;
> +                    aPosAry.mnSrcHeight = aPosAry.mnDestHeight;
> +                }
>                  mpGraphics->DrawBitmap( &aPosAry, *aBmp.ImplGetImpBitmap()->ImplGetSalBitmap(), this );
> +            }
>          }
>      }
>  }
Comment 16 Michael Stahl (CIB) 2012-12-21 18:54:15 UTC
hmm... this is weird... cannot reproduce this problem on Linux,
only on Windows, even though i can reproduce bug 55044 on Linux.

but the fix for 55044 apparently fixes this one on Windows too.

Korrawit, actually the bug is in these so-called "insignificant"
sal_Bool changes, as i was surprised to find out after noticing
that scale codepath is not actually executed :)

*** This bug has been marked as a duplicate of bug 55044 ***