LibreOffice writes the link of a cell that is not plain text (a number,
a boolean, a date, a formula) as style:hyperlink and loext:hyperlink in
the style:table-cell-properties of the cell's automatic style, which is
how it saves a Xlsx file with such links as Ods. The reader looked only
for text:a, so those links were lost.
The reader now maps each cell style to its link and uses it when the
cell has no text:a. A cell with no style of its own takes the default
cell style of its column, as LibreOffice does for A1 in the test file.
The Ods Writer wrote text:a only for string cells, so a link on a
number, boolean, date or formula cell was lost. The Ods Reader looked
for text:a only in string cells, so it would not have read one back.
All cell types now go through one helper that writes the displayed text,
wrapped in text:a when the cell has a hyperlink. The helper asks
hasHyperlink() first, since getHyperlink() would add an empty one. The
Reader takes text:a from the paragraphs of any cell type.
The Ods Writer turned sheet://Sheet2!A1 into #Sheet2!A1, keeping the
Excel separator, while ODF and LibreOffice write #Sheet2.A1. The Ods
Reader only swapped the prefix, so a link written by LibreOffice became
sheet://Sheet2.A1, and a later save to Xlsx wrote location="Sheet2.A1",
which does not resolve.
The Writer now writes a dot after the sheet name, quoted or not. The
Reader turns that dot back into "!" when a cell address follows it, and
still accepts "!", which older releases wrote and which LibreOffice keeps
when the address after it also parses as R1C1 (#'My Sheet'!C3). A named
range, with no sheet, stays as it is.
The Ods Writer wrote no svg:desc for an image, so the description given
with setDescription() was lost, and LibreOffice exported the image to a
tagged PDF as a figure without alternative text. The Reader read no
svg:desc either, including the one LibreOffice writes itself.
The Writer now writes the description as svg:desc on the frame, and
the Reader reads it back.
Cell::getHyperlink() creates and stores an empty Hyperlink when the cell
has none. The Ods Writer called it on every string cell, and the Csv
Writer with preferHyperlinkToLabel on every cell through getCell(),
which also created the empty cells in between. Saving a workbook
therefore changed it: after a save to Ods, every string cell had a
hyperlink with an empty URL, and a later save to Xlsx threw "Invalid
parameters passed." on them.
Both Writers now ask hyperlinkExists() first, and the Csv Writer no
longer goes through getCell().
Special handling in javascript and css for any image whose `alt` value starts with `Logo`, rather than targeting one specific value.
Remove 2 no-longer relevant statements from `extra.css`.
Add css member for `mkdocs` theme.
Add link to PhpSpreadsheet site to the bottom line of each page for `readthedocs` and `mkdocs` themes. In theory, these links should already exist, and they do locally, but not, for some reason, when run on readthedocs.io. This link is different from the `Edit on Github` link at the top, which is a kind of interesting feature.
Add a bookmarklet on the main page for toggling images to dark mode, which would probably be the preference for users employing dark mode. Images are usually left unchanged in dark mode, but almost all our images are screenshots, and dark mode might be appropriate for them.
PHPStan level 10 rejects (string) $value. VALUE() already converted
the argument with StringHelper::convertToString() before this check.
Co-authored-by: Cursor <cursoragent@cursor.com>
BIFFWriter defines two properties, `_data` and `_datasize` as public. There is no reason for them to be public, and no reason for the leading underscore. Change them to protected, and change their names.
`extra.css` specifies a background color for `td` and `th`. I believe it is used only for the `readthedocs` theme, and I do not see why it is needed there; it slightly interferes with dark mode. Comment it out rather than deleting it, just in case a need is established for it.
Color the top bar for `zensical`.
`mkdocs` theme has a weird problem described in its yml file. There is a workaround, but I'm not comitted to it, so make it available but don't use it yet.
Remove the leading underscore in a `Calculation` method. PR #4713 eliminated all use of this method in the test suite, but there are still a handful of uses in source. It is not quite equivalent to `calculateFormula`, so it needs to be retained, and needs to be `public` (possibly `internal` but I'm not ready to go there yet). However, the leading underscore is misleading, so drop it. Since it is public, avoid a breaking change by retaining the old name as essentially an alias of the new.
The configuration file for phpcs includes an option to not flag leading underscores in method names. This is the only method for which that option is needed, so it is being removed.
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.
Dmytro Kulyk
oleibman
Jonathan Goode
youzixu
Samuel Weirich