[Bug 51236] Font color set incorrectly for black and white color using RGB values

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=51236

Yoann Rodière <yo...@openwide.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW
                 CC|                            |yoann.rodiere@openwide.fr

--- Comment #18 from Yoann Rodière <yo...@openwide.fr> ---
Hello,

It seems the bug is still present in 3.10-Final. I'm experiencing it in one of
my projects.

It's going to be quite long, so here's a summary of the following: there are
some issues with the previous patch, mainly because it wasn't focusing on the
proper class, which could trigger problems with other types of colors
(background, borders). I think the fix should be located in some class related
to the font (XSSFFont) or to the XML tag (a new CTFontColorImpl class) instead.

-- Long (but more reasoned) version
Since it's been a while, it may be for the best to start all over again:

There is a "bug" (or at least inconsistency) in Microsoft Excel, which
interprets font colors strangely: for colors without alpha component, the black
and white are switched.

A fix has been commited (by  Nick Burch, if I'm correct). This fix works fine
when using the setter/getter for the RGB value. Unfortunately, only XSSF#setRgb
and #getRbg methods have been fixed, and not the constructors ; which means
that when you write "new XSSFColor(Color.WHITE)", the fix will be ineffective.
That's one thing, and it explains that Jim Talbut reported that the fix didn"t
work: Jim was using the XSSFColor constructor, which wasn't fixed.
Another thing is, this fix directly switches black and white for ALL colors of
ANY purpose. It will switch, for instance, black and white for background
colors, or border colors. This is a real problem, since background colors and
border colors are not affected by the bug in Microsoft Excel. So all in all,
we'll have correct font colors, but incorrect background colors and border
colors.

That's why I think that the fix in XSSFColor should at least be moved to
XSSFFont#setColor(XSSFColor) and XSSFFont#getXSSFColor. However, it might be a
bit hard to do it in such a way that clients never see the "buggy"
(Excel-translated) color...
Maybe it would be even more appropriate to have a CTFontColorImpl extend
CTColorImpl and implement the fix. Indeed, it seems the XML color tags do not
have the same meaning when dealing with borders/backgrounds as when dealing
with fonts, so maybe it would make sense to define two different Java
representations of the XML elements. Besides, the color switching only really
matters when reading/writing the file, not when manipulating data. Of course, I
don't know much about the internals of POI, and it might not be feasible...

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org