https://issues.apache.org/bugzilla/show_bug.cgi?id=51236
Yoann Rodière <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW CC| |[email protected] --- Comment #18 from Yoann Rodière <[email protected]> --- 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: [email protected] For additional commands, e-mail: [email protected]
