Coveralls recommends using an "official integration" of their product with Github. Also, allow the upload to fail without causing the whole coverage step to fail - there have been some recent problems which they are still working on. I may allow the step to fail once they are done with their changes.
Intl is only a "suggested" extension. A lot of the NumberFormat Wizard code depends on it. That's insufficient reason to make it required, but the suggestion text now mentions this dependency explicitly. Also clean up the Wizard documentation to reflect some changes since PhpSpreadsheet 1.28.
Fix#4647. Xls file is corrupt - PhpSpreadsheet tries to extract a substring using array notation, but the index is out of bounds. Php treats this as a warning situation, so continues to process, leading to an onslaught of warning messages. We could change to use the `substr` function rather than array notation, but that seems inappropriate - it would be better to throw an exception and have the user fix the file. In the file posted with the issue, opening it with Excel, and responding yes when it asks if it's okay to clean up the corruption, yields a usable file. Unfortunately, that file weighs in at 28MB, much too large for our test suite. So, no new unit tests accompany this change, but it has been tested.
Tests are added to `getUint2d`, which seems to be the source of the problem in the sample file, and, for good measure, `getInt2d` and `getInt4d`. There may be other sources of similar corruption, but we'll stick with what's in front of our nose.
Fix#4584. As discussed there, MS has implemented this situation in a way that I frankly do not understand. Marking a row with a wrapped cell to *not* use the default row height seems to affect every other populated row. Very odd. Nevertheless, adding a new `customFormat` boolean property to RowDimension seems to be a way to resolve this problem. Note that the Xml generated by Excel already outputs a `customFormat` attribute when a style is applied to a row. This PR just adds that property for when it is needed for rowHeight. It need not, and should not, be set by the application when a style is applied to the row; PhpSpreadsheet will take care of that on its own.
Although the problem was raised for Xlsx format (I think), I investigated other relevant output formats as well. Html tends to do its own cell wrapping. I think the results after this change match the results before.
Xls already handled the output side of this situation without difficulty. A change was needed on the input side, and is included as part of this PR.
Ods did not handle default row height at all. As with other style properties, it is difficult to handle this on the input side, and this PR does nothing to improve that situation. However, we are, at least, able to provide some relief on the output side. Not complete relief - in order to apply the default size to unpopulated rows, we'd need to at least populate them with the `table:number-rows-repeated` attribute, and that has often been a source of problems, so I'm not willing to go there yet. This PR just ensures that all populated rows will have the correct height.
Fix#4626. Previous changes had increased the precision of floating point numbers when cast to string, making for greater accuracy after save and load operations, without affecting the values displayed by Excel. Although the results of the cast are now more accurate computationally, they can appear unexpected to humans. A new boolean parameter `lessFloatPrecision` (defaulting to false) is added to `StringHelper::convertToString`, to `NumberFormat::toFormattedString` and `NumberFormat\Formatter::toFormattedString`, and to the entire `Worksheet::toArray` family of functions. When the new parameter is set to true, the result can be less surprising to humans. It should not, however, be used in subsequent computations.
In the case of the NumberFormat functions, the new parameter will be considered only when the NumberFormat for the cell in question is `General` or equivalent. Setting an actual numeric format for the cell is probably a better solution than using the new parameter.
Php8.5 *may* deprecate the use of `__wakeup` (it is planned, but not yet implemented, and it is convtroversial). We use it only twice. In the first instance, it just throws an exception to prevent a security exploit. This can be trivially replaced with `__unserialize`.
The other instance is merely to initialize a Worksheet instance variable. Converting this use to `__unserialize` is *not* trivial (one of the reasons for the controversy). However, I see no useful purpose for that variable. Since it has no use, there is no real need for `__wakeup`, so we will just remove the routine altogether, and deprecate the variable's getter (there is no setter).
A similar instance variable in Spreadsheet also serves no useful purpose, so we will deprecate its getter as well (again no setter).
oleibman