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.
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 ->
Pictures other than 256tr.png are satisfactory.
256tr.png will become white.
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.
pAlphaW->SetPixel( nY, nX, Color(255L-nResAlpha, 255L-nResAlpha, 255L-nResAlpha) );
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
built and running on ubuntu natty (11.04) 32-bit sith gnome classic
$ 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.
In 26 pixels, color was normal. It will be because it is not resizing.
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.
> 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 184.108.40.206 (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.
Windows XP LibreOffice 220.127.116.11
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 18.104.22.168.
I appreciate your debugging.
Thank you very much!!
Ubuntu 14.04 LTS 32bit/64bit
LibreOffice 22.214.171.124 & Langpack_ja 32bit/64bit