https://bz.apache.org/bugzilla/show_bug.cgi?id=61004
--- Comment #4 from Javen O'Neal <[email protected]> --- (In reply to Nick Burch from comment #1) > It looks to me like we're using java.awt.Color just as a friendly way to > store and retrieve RGB values, as well as looking up some pre-defined colour > values. > > I think it might be fairly quick to replace that with a custom RGB class, > but I'll defer to others to check/confirm/etc This regression was the result of completely rewriting the HSSFColor class from a bunch of singleton subclasses of HSSFColor to instances of HSSFColor that are stored in an enum. This was a much needed change. This also hopefully puts us in a little better position to differentiate between predefined colors, indexed colors, and custom colors. Using java.awt.Color is a natural way to store the rgb triplet, and will accommodate future code consolidation with XSSFColor, which also supports alpha transparency and transformations (HSB, brighter, darker). If someone cares to author a patch for HSSFColor without java.awt.Color, using either int and o.a.p.util.BitFields, 3 shorts, or a short[3] to store the rbg, I'd be willing to review it, though please keep the XSSFColor merge in mind. -- 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]
