Bug 53274 - XSSFColor.getRgbWithTint() return white color for black and vice versa
Summary: XSSFColor.getRgbWithTint() return white color for black and vice versa
Status: RESOLVED DUPLICATE of bug 51236
Alias: None
Product: POI
Classification: Unclassified
Component: XSSF (show other bugs)
Version: 3.8-FINAL
Hardware: PC All
: P2 major (vote)
Target Milestone: ---
Assignee: POI Developers List
Depends on:
Blocks: 52079
  Show dependency tree
Reported: 2012-05-22 16:38 UTC by andrei
Modified: 2016-06-17 08:06 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description andrei 2012-05-22 16:38:18 UTC
ctColor.getRgb() returns the white instead of black and the black instead of white. In getRgb() this issue is fixed.


public byte[] getRgbWithTint() {
        byte[] rgb = getRgb();
        double tint = ctColor.getTint();
        if (rgb != null && tint != 0) {
            for (int i = 0; i < rgb.length; i++){
                rgb[i] = applyTint(rgb[i] & 0xFF, tint);
        return rgb;
Comment 1 Nick Burch 2015-08-26 11:40:28 UTC
I added quite a lot of colour related unit testing as part of the Conditional Formatting work. It's mostly in org.apache.poi.xssf.model.TestThemesTable. That didn't show any issues with theme or non-theme xssf colours and white/black swapping

Could someone perhaps review that, along with re-trying this bug on 3.13 beta 2 / snapshot, and report what you need to do to reproduce this issue on trunk (assuming it isn't already fixed?)
Comment 2 Javen O'Neal 2016-06-17 08:06:20 UTC
This looks like it was fixed in r1126696 based on the commit message
> make the xssf colour black/white 3 rgb fix apply for set as well as get
and the changes
>    public void setRgb(byte[] rgb) {
> -    ctColor.setRgb(rgb);
> +    // Correct it and save
> +    ctColor.setRgb(correctRGB(rgb));
>    }

*** This bug has been marked as a duplicate of bug 51236 ***