Bug 64717

Summary: When registering the png file with alpha information to the toolbar, it was discolored.
Product: LibreOffice Reporter: Miday <Miday>
Component: LibreOfficeAssignee: Not Assigned <libreoffice-bugs>
Status: RESOLVED WORKSFORME    
Severity: normal CC: dent.ace, lo_bugs
Priority: medium Keywords: regression
Version: 3.5.0 Beta0   
Hardware: Other   
OS: Linux (All)   
Whiteboard: bibisected40older
Crash report or crash signature: Regression By:

Description Miday 2013-05-17 14:56:10 UTC 
LibreOffice 4.0.3/3.6.6/3.5.7    calc/write
ubuntu 12.04 32bit

This problem occurs by Linux.
It does not occur in Windows.

The size of the following picture is 16*16 pixels.
http://www.ne.jp/asahi/soft/miday/Calc_Moji/pngdata.zip
256tr.png    True color with alpha information   A background is transparent.
256wh.png    True color                          A background is white.
8tr.png      Index color                         A background is transparent.
8wh.png      Index color                         A background is white.

By Calc/Write, the following operations are carried out and it registers as an icon of a toolbar.

menu View -> Toolbars -> Customize -> 
Toolbars -> Commands -> Modify -> Change Icon -> 
Import

Pictures other than 256tr.png are satisfactory.
256tr.png will become white.
http://www.ne.jp/asahi/soft/miday/Calc_Moji/errorIcon.png

The alpha information on the original range of 16*16 is not right.

At 256tr.png, one pixel is "RGBA" and is 32 bits. 
"A" is alpha information and is 0 - 255.
  0 is un-transparent.
  255 is transparent.
This alpha information is reversed in 16*16.

For example, in LO3.5, if the following line is changed, it will be repaired.
File
 vcl/source/gdi/outdev2.cxx
Method
 OutputDevice::ImplBlendWithAlpha

Original
            pAlphaW->SetPixel( nY, nX, Color(255L-nResAlpha, 255L-nResAlpha, 255L-nResAlpha) );
After correction
            pAlphaW->SetPixel( nY, nX, Color(nResAlpha, nResAlpha, nResAlpha) );

nY and nX are 0 - 15.

But since it thinks that Windows will be influenced if this is corrected, I think that it is not right.
I am not investigating any source other than LO3.5.
I am not investigating the source of Windows/Mac, either.
Comment 1 Terrence Enger 2013-05-21 20:39:26 UTC 
I have seen the user-visible part of the bug in master commit 6faa622,
pulled 2013-04-19, configured with

    --enable-option-checking=fatal
    --enable-dbgutil
    --enable-crashdump
    --without-system-postgresql
    --without-myspell-dicts
    --without-help
    --with-extra-buildid

built and running on ubuntu natty (11.04) 32-bit sith gnome classic
desktop

    $ uname -a
    Linux cougar-natty 2.6.38-16-generic #67-Ubuntu SMP Thu Sep 6 18:00:43 UTC 2012 i686 athlon i386 GNU/Linux

    $ gcc --version
    gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2

    Copyright (C) 2010 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    $ java -version
    java version "1.6.0_24"
    OpenJDK Runtime Environment (IcedTea6 1.11.5) (6b24-1.11.5-0ubuntu1~11.04.1)
    OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)


For comparison, I do not see this problem with LibreOffice 3.3.4, as
delivered with ubuntu-natty; so am setting keyword regression.  I
shall try to localize the the regression further.
Comment 2 Terrence Enger 2013-05-22 03:02:25 UTC 
Regression does appear in oldest version of bibisect-4.0.tar.xz
Comment 3 Miday 2013-05-23 13:25:56 UTC 
I investigated further.

Color was normal at LibreOffice 3.3.4.
In LibreOffice 3.4.4, it became white.

No less than 32 pixels are the same phenomenon.
http://www.ne.jp/asahi/soft/miday/Calc_Moji/32pngdata.zip

In 26 pixels, color was normal. It will be because it is not resizing.
http://www.ne.jp/asahi/soft/miday/Calc_Moji/26pngdata.zip

When outdev2.cxx of sauce was corrected by LO3.5, color was normal in three kinds of sizes.
32 pixels : nY and nX are 0 - 25.
26 pixels : It does not pass.
Comment 4 Miday 2013-05-23 13:31:19 UTC 
I'm sorry

> When outdev2.cxx of sauce was corrected by LO3.5, color was normal in three
> kinds of sizes.

sauce -> source
Comment 5 Terrence Enger 2013-05-24 00:29:39 UTC 
(In reply to comment #3)
> In 26 pixels, color was normal. It will be because it is not resizing.

I tried LibreOfficePortable version 4.0.2.2 (4c82dcd) running on
WinXP, and--as Miday said--256tr.png rendered nicely on the toolbar.
However I noticed along the way that the Change Icon dialog says that
the preferred size for an image is 16 by 16 pixels.  Perhaps it is the
lack of scaling which makes the image render correctly, and execution
on Windows is merely coincidental.  

On the other hand, files 8tr.png and 8wh.png render nicely on both
platforms; so it is not the case that scaling always fails when there
are transparent pixels.
Comment 6 Miday 2013-05-25 07:55:26 UTC 
(In reply to comment #5)
It is a 8-pixel picture smaller than 16-pixels.
http://www.ne.jp/asahi/soft/miday/Calc_Moji/8pngdata.zip

Windows XP LibreOffice 3.5.4.2

A 8/26/32-pixel picture is normal.
I think that the resizing processing by Windows is satisfactory.
Comment 7 Björn Michaelsen 2013-06-26 12:04:37 UTC 
Marking version as being introduced 3.5 beta or before as per comment 2.
Comment 8 Miday 2015-02-28 04:30:52 UTC 
This bug is not included in LibreOffice 4.4.0.3.
I appreciate your debugging.

Thank you very much!!

Ubuntu 14.04 LTS  32bit/64bit
LibreOffice 4.4.0.3 & Langpack_ja  32bit/64bit