PhpSpreadsheet treats CODE and UNICODE as equivalent, likewise for CHAR and UNICHAR. They are, in fact, different. CODE and CHAR deal only with single-byte character sets (Windows-1252 or MacRoman), while UNICODE and UNICHAR deal with all of Unicode. This PR separates them. The existing unit test for CODE was, in many cases, applicable to UNICODE (for which there was no separate test). The tests are corrected for CODE, new tests are added, and a separate test for UNICODE is added. CHAR was mostly okay, new tests are added, and a separate test for UNICHAR is added.
Ran into a surprising hitch when Php8.5 failed unit tests despite nightly succeeding. Duplicated problem locally, and fixed it with a Phpunit upgrade. Hopefully that will work on Github as well.
In PR #4716, @RobinvanderVliet points out that Cell::setValueExplicit and Worksheet::setCellValueExplicit are strangely inconsistent, where the latter requires you to specify a DataType but the former does not. The fix in that PR is to make the latter offer a default DataType rather than requiring the parameter. While that does eliminate inconsistency, I think it does so in the wrong direction - the solution should be to eliminate the optionality in the former - an implicit value for setValueExplicit just doesn't make sense. We can't do that without a breaking change, which this is not. However, we can update the doc-block and change log to indicate our intention to make that change in the next breaking release.
They aren't quite interchangeable. Both are used in the test suite, with no indication of why one or the other. I think we'd be best off being consistent. Based on the names, I think `_calculateFormulaValue` was intended as a private, or at least internal, method, so favor `calculateFormula`. I do not intend to rename or re-categorize `_calculateFormulaValue`, just remove its usage when it isn't clearly warranted.
Fix#3941. Html and Pdf Writers will show PrintArea if specified rather than the entire sheet. Html Writer, which needs to handle both screen and print views, will use PrintArea through CSS; PDF, which needs to handle only print view, will use it by not including rows and columns which are not in the PrintArea. The support is limited because:
- PrintArea can consist of several different ranges. The writers will use the PrintArea only if it consists of a single range.
- Html use will be effective only if `useInlineCSS` is set to `false`, which is its default value.
- Other aspects of page setup, e.g. horizontal centered, remain unsupported, with or without PrintArea.
Html Writer will also set a `data-printarea` attribute on the `table` declaration for a worksheet when appropriate. Html Reader will recognize and process that attribute. This usage does not require that the PrintArea consist of a single range.
zhukoff74
oleibman
Robin van der Vliet