Bug Hunting Session
Bug 64717 - When registering the png file with alpha information to the toolbar, it was discolored.
Summary: When registering the png file with alpha information to the toolbar, it was d...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected)
3.5.0 Beta0
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
Whiteboard: bibisected40older
Keywords: regression
Depends on:
Reported: 2013-05-17 14:56 UTC by Miday
Modified: 2015-02-28 04:30 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
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.
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) );
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


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

    $ 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.

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.
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 (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.

Windows XP LibreOffice

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
I appreciate your debugging.

Thank you very much!!

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