https://bz.apache.org/bugzilla/show_bug.cgi?id=69691
Bug ID: 69691
Summary: Why add rgb attibute automatically when getting
foreground color (getFillForegroundXSSFColor) from an
XSSFCellStyle? That causes problem.
Product: POI
Version: 5.4.1-FINAL
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: XSSF
Assignee: dev@poi.apache.org
Reporter: zhuxia...@126.com
Target Milestone: ---
I'm trying to generate an XLSX file containing exported data using an XLSX file
as a style template. However, I encountered a problem when copying the style of
the table header row: the fill color of the cells in the generated file looks
different from that in the template file.
I decompressed both the template file and the generated file and observed the
xl/styles.xml files of the two. Indeed, there are differences.
The styles.xml in the template file is like this:
<fgColor theme="2" tint="-0.0999786370433668"/>
And the styles.xml in the generated file is like this:
<fgColor theme="2" tint="-0.0999786370433668" rgb="E7E6E6"/>
As you can see, the fgColor in the styles.xml of the generated file has an
additional rgb="E7E6E6" attribute. This difference has led to the following
issues:
* When I open the file with Microsoft Office, the cell color I see is #D0CECE.
* When I open the file with Kingsoft WPS Office (https://www.wps.com/), the
cell color I see is #E7E6E6.
That is to say, when the three attributes theme, tint, and rgb exist
simultaneously:
* Microsoft Office only uses the theme and tint attributes and ignores the rgb
attribute.
* Kingsoft WPS Office only uses the rgb attribute and ignores the theme and
tint attributes.
Then I referred to the Open XML specification document ECMA-376. In the
description of fgColor, it doesn't mention which attribute should take
precedence when the above three attributes exist simultaneously. So, in my
opinion, both Microsoft and Kingsoft are following ECMA-376, but they handle
the details differently.
I traced the Java code and found the key point here, the
getFillForegroundXSSFColor() method in the
org.apache.poi.xssf.usermodel.XSSFCellStyle class:
public XSSFColor getFillForegroundXSSFColor() {
// bug 56295: handle missing applyFill attribute as "true"
because Excel does as well
if(_cellXf.isSetApplyFill() && !_cellXf.getApplyFill()) return
null;
int fillIndex = (int)_cellXf.getFillId();
XSSFCellFill fg = _stylesSource.getFillAt(fillIndex);
XSSFColor fillForegroundColor = fg.getFillForegroundColor();
if (fillForegroundColor != null && _theme != null) {
_theme.inheritFromThemeAsRequired(fillForegroundColor);
}
return fillForegroundColor;
}
In the above code, the inheritFromThemeAsRequired() method in the
org.apache.poi.xssf.model.ThemesTable class is called. This method reads the
rgb value of the corresponding theme color from the theme1.xml file (in this
case, it's #E7E6E6) when the theme attribute is set in fgColor, and then adds
the rgb attribute value to fgColor.
public void inheritFromThemeAsRequired(XSSFColor color) {
if(color == null) {
// Nothing for us to do
return;
}
if(! color.getCTColor().isSetTheme()) {
// No theme set, nothing to do
return;
}
// Get the theme colour
XSSFColor themeColor = getThemeColor(color.getTheme());
// Set the raw colour, not the adjusted one
// Do a raw set, no adjusting at the XSSFColor layer either
color.getCTColor().setRgb(themeColor.getCTColor().getRgb());
// All done
}
The same problem also exists in the getFillBackgroundXSSFColor() method of the
XSSFCellStyle class.
I don't understand why this is done? Why perform a setYYY() action in a
getXXX() method? This doesn't seem to conform to the usual design principles.
And indeed, this has caused problems.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org
