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.
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.
Regression does appear in oldest version of bibisect-4.0.tar.xz
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.
I'm sorry > When outdev2.cxx of sauce was corrected by LO3.5, color was normal in three > kinds of sizes. sauce -> source
(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.
(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.
Marking version as being introduced 3.5 beta or before as per comment 2.
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