- use String.replace instead of String.replaceAll for literal values
- use constants from base class
- deprecated various references to constants of org.apache.poi.ss.usermodel.FontFormatting - to be replaced by o.a.p.s.u.Font in POI 5.0.0
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1875859 13f79535-47bb-0310-9956-ffa450edef68
Bug 61882 - Some paths can create an XSSFColor instance with a null CTColor reference
Protect against this in the future by introducing a factory method to create XSSFColor instances from a CTColor instance and the associated workbook style indexed color map.
If the CTColor instance is null, the factory returns null. All callers already are prepared for a null instance, but many had their own null check on the CTColor object. This centralizes that.
This also further forces the requirement for the indexed color map. Any time a color is created, the workbook or styleTable is available in the same context, so passing this is extra parameter is trivial and allows XSSFColor to properly reference custom/themed indexed colors.
Did not remove any methods yet, only deprecated them. Changed the signature to one internal test-only constructor.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1817796 13f79535-47bb-0310-9956-ffa450edef68
Bug 60898 - XSSFColor's getARGB() method returns a wrong color value when a workbook has a custom indexed color
teach XSSFColor and most things that create instances about indexed colors.
Null is a valid value for IndexedColorMap instances - the existing built-in default colors are used.
Whenever a workbook style is accessible in the call hierarchy its color mappings are passed down now.
Thanks for the unit test in the issue, it now passes.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1796359 13f79535-47bb-0310-9956-ffa450edef68