Bug 61085

Summary: StylesTable doesn't include table styles
Product: POI Reporter: Greg Woolsey <gwoolsey>
Component: XSSFAssignee: POI Developers List <dev>
Status: RESOLVED FIXED    
Severity: enhancement    
Priority: P2    
Version: 3.17-dev   
Target Milestone: ---   
Hardware: All   
OS: All   

Description Greg Woolsey 2017-05-10 22:24:14 UTC
The OOXML styles.xml includes a <tableStyles> collection defining custom styles for data tables and pivot tables.  The StylesTable class should know about them.

Further, it should know about the built-in styles defined in the OOXML spec Annex G.

The XML definitions of these can be found here:

http://www.ecma-international.org/news/TC45_current_work/OfficeOpenXML-SpreadsheetMLStyles.zip

These are not in the same format as styles.xml, unfortunately, but recognizable as similar.

Table styles are referenced by name, not index as other style elements, but refer to <dxf> elements in the same collection as other types of styles, like conditional formatting rules, by the same indexes.

It is quite possible, even likely that a single workbook will have <dxf> elements for both conditional formats and tables, and possibly even share some between them if they are identical in definition (don't have proof of this, but the spec indicates it could happen).

StylesTable should have name based getter functionality, and the new TableStyle or whatever class should know about the list of possible style dxfs.  These are referenced by type name, and have a well-defined application hierarchy in the spec.

The resulting API should make it easy to navigate table styles by name, and then the styles of an element by both type and cell within a table, finding the ordered set of styles to process for a given cell given its table position and the table style configuration (boolean properties for things like whether or not to use alternating row styles).
Comment 1 Greg Woolsey 2017-05-10 22:47:09 UTC
My plan here is to implement built-in table/pivot styles loosely following the pattern used for PresetGeometries:

* include the XML as a resource in the build/source control
* parse it and initialize definition objects lazily in a static/singleton

I'm adding some interfaces to the ss package, and implementing classes to simplify access to the underlying structures, which are a bit convoluted (of course), and share some similarities to things like conditional formatting rule style definitions - both use <dxf> objects in the same <dxfs> collection to define style info.  

My client app will want to generate style info for both and possibly combine them, i.e. when a cell in a table is also conditionally formatted, so a common API for similar/same structures will be helpful.
Comment 2 Greg Woolsey 2017-05-12 00:23:14 UTC
Huh.  Unit test was failing, it turns out the canonical presetTableStyles.xml from ECMA has a typo - a trailing space in a name attribute, making string comparisons fail.

Correcting the value in the copy that will end up in POI.
Comment 3 Greg Woolsey 2017-05-20 03:18:04 UTC
Wow.  So the standards document uses 1 based indexing for dxfId in the <tableStyleElement> element, but Excel uses 0 based indexing.  Built-in style parsing needs to be different than custom/user style parsing.