Bug 56808

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

Created attachment 69906 [details]
screenshot in 3.6.3.2 - this is expected

regression introduced between pull time 2012-06-27 04:02:20 (core: 3f135598fd508e70f31f36cd8a8d7a61ccf4ff79) and 2012-07-15 01:33:34 (core: 146b507f9f52daa7378aaeddf6725b9ab129af61)

works under Linux, fails under windows

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

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

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.

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

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.

*** Bug 58140 has been marked as a duplicate of this bug. ***

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?

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.

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 :)

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.

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 );
> +            }
>          }
>      }
>  }

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 ***