Six years ago, my PR #1557 was merged. It was written mainly to improve code coverage in Xml Reader, but some changes and enhancements were made to the Reader code. I noted in that ticket: "File templates/Excel2003XMLTest.xml, used in some tests, is not
readable by a current version of Excel. I have substituted a new file
excel2003.xml to be used in its place. I have not deleted the original
in case someone in future (possibly me) wants to see what it needs to
make it usable." That time has finally arrived.
Excel could not open the file. LibreOffice could, and did a pretty decent job, but something seemed wrong with how it handled formulas. PhpSpreadsheet could not read it, because a field identified as a date/timestamp was wrong - it specified a time-of-day hour as `288`. I made a copy of the file, changed the invalid hour to something valid. It turns out that was not Excel's problem - it still could not read the file. But, for the first time that I can recall, Excel produced decent diagnostic messages! They were in a location that you can't get to through Windows Explorer, even with "hide system files" turned off. However, you could get to it through Windows Command Prompt. There were 56 problems, all involving formulas (which was probably LibreOffice's problem). The formulas were all of the form:
```
of:=[.B1]+[.C1]
```
Now, XML spreadsheets use RC format rather than A1 format for its cells. The formula above is of a style that LibreOffice uses, but Excel does not understand it. It is looking for something like:
```
ss:Formula="=RC[-6]+RC[-5]
```
Excel2003Xml doesn't understand the formula in the file, but PhpSpreadsheet does. But, before it could do so, we had to eliminate the Exception when we tried to parse the invalid date/time. So, the first order of business was to wrap the Xml Reader date conversion logic in a try/catch. This allowed PhpSpreadsheet to read the file, and then to save it as an Xlsx file. Then we could open the Xlsx file in Excel, and save it as Xml. Voilà. We have converted the unreadable Xml file to a readable one. LibreOffice can also read the new file, and the formulas are now correct. BTW, I have no idea what was intended on sheet "Report Data" cells G17:G29. They all subtract a value from an empty cell, so the result is always negative, and try to format it as a date (which Excel doesn't like for negative numbers). Whatever that problem is, there is no need to fix it at this time.
At this point, a little cleanup was still needed. The Xml file was using some strange named styles, e.g. `Medium Date`. I was able to get a list of these with the google query `excel 2003 ooxml named number formats`. However, the list came only in the AI portion of the response; I could not find a link to anything permanent. So I went with what it showed me.
The earlier PR suggested that handling UTF-16 for this format would be difficult. However, saving the now-usable UTF-8 Xml file as UTF-16 with BOM results in a file which PhpSpreadsheet (and Excel and LibreOffice) can read without any code changes.
The legacy XLS writer emitted a non-canonical CFB v3 header and malformed DIFAT metadata when exactly 109 FAT sectors were needed. It also miscounted DIFAT capacity beyond that boundary.
Use the fixed CFB v3 sector profile, write minor version 0x003E, correct DIFAT allocation, and reject oversized v3 stream layouts. Add boundary and round-trip coverage.
`simplexml_load...` can return false, and callers check for it. `dom->loadXML` can do likewise but, till now, it hasn't been checked. Only user of `dom->loadXML` is Ods Reader. Change it to throw if Xml is invalid.
Fix#744 (marked stale in 2019, but now reopened). The fix draws heavily on the work of @guillaume-ro-fr in PR #745, which was closed because of a unit test error which is no longer possible, and because it was targeted to a branch which no longer existed.
Changing a worksheet name can wind up invalidating charts. To fix this: when a worksheet name changes, inspect all the charts in the spreadsheet (the old PR changed only the current worksheet) and change worksheet references from the old name to the new one.
During testing, found and corrected some minor problems with cloning some Chart objects.
Although I have not noticed a problem with mkdocs and relatives, some markdown viewers will, under circumstances that I cannot reliably predict, not render correctly a "fenced" block (starting with 3 backticks) if it is not preceded by a blank line. "Correct" this situation wherever I was able to find it.
Use a white, rather than transparent, background for logo, making it viewable in dark mode.
A bit better emulation of dark mode in the readthedocs theme, which does not handle it "naturally".
oleibman
oleibman
^^
dependabot[bot]