* Expand Chart Support for schemeClr and prstClr
Fix#2219. Address some, but not all, issues mentioned in #2863.
For Pie Charts, fill color is stored in XML as part of dPt node, which had been ignored by Reader/Xlsx/Chart. Add support for it, including when specified as schemeClr or prstClr rather than srgbClr. Add support for prstClr in other cases where schemeClr is supported.
* Update Change Log
Add this PR.
No doubt some developers will complain that it should be the other way round, that datatpe should be modified to match the specified value; but then they should be using setValue() instead; the use of setValueExplicit() is explicit.
* Namespacing Part 3 - Charts
Charts still need some work, but they are now in good enough shape that the code that reads them can handle namespacing properly. Rather than a set of static routines, Reader/Xlsx/Chart needs to be changed to a regular object, with the relevant namespaces passed in the constructor. I am still looking for a test spreadsheet with non-standard namespacing for a full-blown test, but, in the meantime, the existing tests and samples will suffice. When I find a test case, I will certainly add it.
The resulting code is actually simpler than it had been because of the elimination of the need for a NamespacesMeta variable in all the function signatures. Because of that, enough errors disappeared from Phpstan that I decided to just finish that job - its baseline file now dips below 5,000 lines.
* Update Change Log
Need to document many chart changes.
* Fix reading of files in the root of a zip
Xlsx.php relies in dirname($filename) for path generation. When path is a bare filename (i.e. files in the root of the zip file), dirname($filename) returns a relative path to the current directory ("."). This is ok for filesystems, but not when accesing contents in a zip file.
Xlsx documents with files in the root of the zip container are not common, but legit. I've found it to happen in files generated by Google Campaign Manager 360.
* Update Xlsx.php
* Update Xlsx.php
* Update CHANGELOG.md
* Add files via upload
* Create XlsxRootZipFilesTest.php
* Update XlsxRootZipFilesTest.php
* Add files via upload
* Delete rootZipFiles.xlsx
* Update XlsxRootZipFilesTest.php
* Update Xlsx.php
It gets awkward when the defined name is for an actual range rather than for an individual named cell; because we need to manipulate the stack when that happens.
The code is ugly, and this is a rather simplistic approach, but it works as long as the named range is a cell, a cell range, or even a "chained" range - it won't work if we have union or intersection operators in the defined range - but it does provide formula support that never existed before.
Current implementation for all methods that take a single cell reference argument:
- `setCellValue()`
- `setCellValueExplicit()`
- `getCell()`
- `cellExists()`
- `setBreak()`
- `freezePane()`
- `getComment()`
Also introducing a CellRange object to work with similar cases for methods that accept a cell range rather than simply a cell address; and RowRange/ColumnRange objects for those cases.
Still need to apply to methods that accept a cell range or single cell:
- `mergeCells()`
- `unmergeCells()`
- `protectCells()`
- `unprotectCells()`
- `setAutoFilter()`
Then there's a few special cases that accept row and column ranges, not simply cell ranges; or a series of cell ranges.
The code could stil do with some cleaning up, and better optimisation for memory usage; but all tests are passing... that's for full multi-level sorting (including direction), and allowing for correct sorting of sting/numeric datatypes.
- Update existing ranges, expanding if necessary, rather than trying to clone for each individual cell
- Update conditions, so that cell references and formulae are maintained correctly
Note that absolute as well as relative cell references should be updated in conditions
oleibman
Mark Baker
MarkBaker
andres1gb
mjan4175