By default, when an Xlsx spreadsheet is read, its calculation engine is set to `RETURN_ARRAY_AS_VALUE` for array formulas. The user does have the option to change this. However, the presence of certain metadata in the file indicates that it was saved as if `RETURN_ARRAY_AS_ARRAY` was in use. This PR tests for the metadata, and, if present, sets `...ARRAY` rather than `...VALUE`. This eliminates the need for any extra action on the user's part.
Fix#4260. A number of Security Advisories related to libxml_options were opened. In the end, we disabled the ability to specify any libxml_options. However, some users were adversely affected because they needed LIBXML_PARSEHUGE for some of their files. Having finally obtained access to a file demonstrating this problem, we can restore this ability.
- The operation is potentially dangerous, a vector for memory leaks and out-of-memory errors. It is not recommended unless absolutely needed.
- It will not be permitted as a global (static) property with the ability to adversely affect other users on the same server.
- It will instead be implemented as an instance property of Xlsx Reader (default to false), with a setter. I do not see a use case for a getter.
- People will need to set this property individually for each file which they think needs it.
- This change will be backported to all supported releases.
- The sheer size and processing time for the file involved makes it impractical to add a formal test case. It has, nevertheless, been tested satisfactorily.
In our unit tests, we can test the Worksheet Xml which PhpSpreadsheet will generate without having to actually write the spreadsheet to and read it from disk. This refactoring allows us to do the same for Styles, as demonstrated in the new StylesWriterTest.
See discussion #4502. I am not sure of what needs to be involved here. This is especially so because Excel also offers AutoColor, but its dark mode looks significantly different than LibreOffice's.
So here's what I've come up with thus far.
- Add boolean autoColor with setter and getter to Font.
- If autoColor is true, ODS writer and XLSX Writer will record it in the xml, and will not write a font color. It is possible that both can co-exist; I'm just not sure how they are supposed to interact if that is the case.
- It makes most sense to me if the spreadsheet's default font specifies autoColor, but PhpSpreadsheet will not insist on that.
- Xlsx Reader will process autoColor. Like most other styles, Ods Reader is not yet set up to handle it.
- LibreOffice Calc should follow the autoColor declarations when it reads either an Xlsx or Ods spreadsheet created by PhpSpreadsheet.
Fix#2760. Maybe. I have no real way of confirming. I am not sure why it might be needed, but a comment in the issue suggests that it helps. I have asked the submitter and another participant in the discussion to let me know if it helps before moving forward.
A while back, Microsoft introduced changes to the default theme colors and fonts. We are adding support for this new theme so that users can use it easily on new spreadsheets if they wish. (It is already supported when using the Xlsx Reader to load an appropriate file.) The old theme was described by constants COLOR_SCHEME_2013_PLUS_NAME and COLOR_SCHEME_2013_PLUS; these are deprecated in favor of COLOR_SCHEME_2013_2022_NAME and COLOR_SCHEME_2013_2022. The new theme is described by constants COLOR_SCHEME_2023_PLUS_NAME and COLOR_SCHEME_2023_PLUS. PhpSpreadsheet's default theme remains COLOR_SCHEME_2007_2010, to avoid breaking changes.
A third optional parameter `$spreadsheet` is added to setThemeColorName. If specified, the default font names for the theme will be applied to the default style for the spreadsheet. You can thus use the new theme with its relatively new default `Aptos Narrow` font. IMHO, that isn't necessarily a good choice, but it is available. MS stores the new font in a different location than other system fonts, and that can lead to portability problems, e.g. if your spreadsheet uses Aptos and you export it to Html, browsers will not be able to find the font and a substitute font will be used.
TOCOL and TOROW were introduced to Excel in 2024, and will now be supported by PhpSpreadsheet. The documentation says that, under certain circumstances, "blanks" will be ignored. This seems demonstrably wrong. In the right circumstance, Excel will ignore nulls, not blanks. Further, when it decides to not ignore the nulls, it changes them to 0, which also seems insufficiently documented. PhpSpreadsheet will behave as Excel does.
I discovered some minor problems and some missing test conditions for the TRANSPOSE function while testing these. Those are now fixed.
Fix#4485. VSTACK and HSTACK were introduced to Excel in 2024, and will now be supported by PhpSpreadsheet. Special thanks to @SlowFox71, who posted some code to implement VSTACK in the linked issue. I didn't have to change much between that version and the one in this ticket.
Excel has at least one idiosyncrasy with these functions. If you try to stack 2 tables with, say, `=VSTACK(TABLE1, TABLE2)`, Excel will silently change it to `=VSTACK(TABLE1[], TABLE2[])` and all will be well. This would be difficult for PhpSpreadsheet to do. The problem is that, when Excel reads the formula without the square brackets, it calculates it as a `#NAME?` error. This is baffling, and all the more so because you can "correct" it by editing the formula *without changing anything*, hit enter, and the formula will magically work again. So, if you plan to stack tables using PhpSpreadsheet, you're probably best off using the square brackets.
Its first parameter is typed as `array`. Like all Excel spreadsheet functions, it should be `mixed` to avoid TypeErrors. If an argument other than an array is supplied, Excel will return VALUE, and now PhpSpreadsheet will do so as well. This had not been unit-tested. In fact, all the unit tests take place outside of spreadsheet context. New tests in spreadsheet context are added.
Fix#1154, which went stale over 5 years ago, and is now reopened. RichText elements can be a Run, which sets its own style, or a TextElement, which doesn't. As the issue states, TextElement handling is inconsistent. This PR forces it to inherit the style of the cell. As implemented, this will change it to a Run when it is read in, but there should be no practical difference as far as the end-user is concerned. There is no change as far as Run is concerned. The user suggested 3 options - TextElement and Run both inherit for any unspecified style elements, TextElement inherits and Run does not, neither inherits. Option 2 makes most sense to me. Option 1 may not even be possible (we can't tell if, say, the user explicityl set Italic to false, or if that was just the default choice).
Tests are added for all of Xlsx, Xls, and Html. Html reading of RichText elements is not well-supported. The tests are fairly difficult to understand. A new sample is added to demonstrate this change.
oleibman
dependabot[bot]