Fix#4673. Our password hasher can handle different algorithms, but the workbook password (for maintaining the structure of the workbook, not for encrypting the entire workbook) currently supports only the single algorithm that was in place many years ago. Expand it, and Xlsx Reader and Writer, to be able to use, say, SHA-512, which is what Excel itself uses.
The revisions password needs to be expanded in the same way as the workbook password. It is used for file sharing, but MS has deprecated it because it feels that modern technologies introduce better ways to accomplish what it was needed for. You'll need to look pretty hard to even find it in Excel - it's not, for example, on any of the ribbons. Nevertheless, the solution here is pretty much identical to the solution for the workbook password, so I am fixing it at the same time.
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.
oleibman
dependabot[bot]