Jpgraph does not use namespaces. Neither do the Samples members of this project. As a result, Scrutinizer complains about 13 cases of `use PhpOffice\PhpSpreadsheet\Chart\Legend;`, since this theoretically could cause the use of two different Legend classes in the empty namespace. It suggests using a class alias for Legend, which this PR does in every applicable case. It is a regrettable problem, but it is easy to fix.
For a recent change, I removed some errors from Phpstan baseline and instead added annotations in the source members. I did this work incrementally, and was surprised when php-cs-fixer required a change from `// @phpstan-ignore-next-line` to `/** @phpstan-ignore-next-line */`. No problem thinks I, and continue to modify several members using the new convention until php-cs-fixer required a change from `/** @phpstan-ignore-next-line */` to `// @phpstan-ignore-next-line`??? I did as directed, and continued to be surprised for the rest of that ticket.
Having had time to research, the problem is due to two options in the php-cs-fixer config file `'comment_to_phpdoc' => true` and `'phpdoc_to_comment' => true`. It seems that php-cs-fixer is treating these annotations the same as doc-blocks, expecting `/**` before a `structural element`, and `//` otherwise. For the statements where I had questions, it expects `/**` before a statement which you might be able to precede with `/** @var`, and `//` where you would not be able to precede it with `/** @var`. However, in this case, what it is doing is forcing what appear to be inconsistencies between otherwise identical statements, whereas php-cs-fixer is supposed to be supporting consistent syntax throughout the project. This PR changes both options to false, allowing (but not requiring) a consistent syntax for these examples. It contains an example of a change from each format to the other, changes which php-cs-fixer would previously have flagged.
An added bonus for this change is that Scrutinizer annotations can now be added to the code; these were often rejected by php-cs-fixer. These should, of course, be used very conservatively, but there are cases where Scrutinizer's analysis is either faulty or not helpful. This PR takes advantage of the change by adding annotations to eliminate the two existing problems which Scrutinizer classifies as 'Security', problems for which there is no sensible way to satisfy Scrutinizer's complaint.
No executable code is changed by this PR.
Some work on refactoring the ReferenceHelper to extract the logic for updating cell references. This is a preliminary step toward allowing updates to absolute cell references, required to update Conditional Formatting rules.
And a bugfix when deleting cells that contain hyperlinks (the hperlinks weren't being deleted, so were being "inherited" by whatever cell moved to that address).
Plus some additional unit tests for the ReferenceHelper.
And a bugfix when deleting cells that contain hyperlinks (the hperlinks weren't being deleted, so were being "inherited" by whatever cell moved to that address)
The code is ugly as sin; but it works... I'll do some refactoring and cleaning later (once I've had some sleep, because I'm stupidly still working on this at 3am)
The main remaining issue is formulae that can't be parsed in BIFF8 files; e.g. formulae that use functions that aren't available. In this case, all CF in that worksheet is corrupted, and the file errors when opened, so it is a serious issue. The ISODD()/ISEVEN example in 07_Expression_Comparisons.php uses these, so I've temporarily commented out setting that CF range until I've solved that problem. There are other limitations listed in the BIFF documentation; but they're harder to detect.
I've also left a couple of debug statements in the code to display these formula errors: I'll remove them once I've resolved the issue.
BaseWriter openFileHandle opens its output file with mode `wb+`. We don't appear to attempt any reads on the file after it is opened in write mode, so `wb` should be sufficient. This may have been a factor in the need for PR #2326, and is likely to be responsible for issue #2372.
These changes have already been implemented twice, and been regressed twice. I'll try once more (with a different approach), then give up ...
As configured, Phpstan running under Php7 reports no errors. However, running under Php8, it reports 100 (!) errors. The vast majority of these are due to two reasons:
- renaming parameters in Php builtin functions in preparation for named parameters.
- using the new class GdImage rather than type resource as the argument type for many image-based functions.
Regardless of the cause, this will be a problem sooner or later. This PR is an attempt to get ahead of that problem. For source members, it mostly adds annotations or updates doc-blocks. Only 2 members have changes to executable code, and these are very minor - BitWise and Writer/Xlsx. For test members, all baseline errors are deleted and the code is fixed. Php7 and Php8 both report no errors with this configuration.
* Add two cell anhor drawing.
* Add "Support for two cell anchor drawing of images." to CHANGELOG.md
* Add pull-request link to "Support for two cell anchor drawing of images." of CHANGELOG.md
Sample39 was not adjusted when Defined Name support was changed to include both relative and absolute addresses. As a result, the Xlsx output is currently incorrect. The Xls output is in even worse shape, since PhpSpreadsheet 'Cannot yet write formulae with defined names to Xls' (see Writer/Xls/Parser.php). (Working around that restriction was the reason for my first contribution to this project.) The sample is changed to define its named ranges properly, and to produce only Xlsx output.
You can set up a conditional style to, say, apply to cells equal to boolean values. For such conditions, the Excel XML specifies `TRUE` or `FALSE`. It is noteworthy that false matches empty cells as well as FALSE, but not 0; similarly TRUE does not match 1. The Xlsx Writer just casts these values to string, which will not work properly. The Xlsx Reader treats the values as strings, so it won't work properly either. This PR corrects both. Also the doc blocks in Style/Conditional allow bool in some places, but not in others; these are corrected but no executable code is changed there.
I made some changes to make our code ready when Phpstan is configured to run on Php8. These were regressed. I reinstalled. All was good for an hour or so till Dependabot pushed a version change for Phpstan. Checking that out, it runs clean on Php7, has 3 errors on Php8.0, and 100 errors on Php8.1. Although that number seems alarming, most of these were caused because Phpstan was reporting the same problem in a trait everywhere it was used, and a single change sufficed to eliminate most of those.
The remainder, some of which caused run-time problems with Php8.1 on my system but which are not yet showing up on Github, are mostly the usual "null supplied where string expected". However, a new problem showed up - `float % 2` gets an "implicit conversion from float to int" warning (and Phpunit issues an extraordinarily long message when this happens). There was also a totally undocumented Php change where `array_combine` throws an exception in Php8 when it would have returned `false` as it does in Php7. These problems are all addressed with very minor changes in this PR.
Xls Reader can read drawing offsetX and offsetY as float. However, Excel Xlsx (and PhpSpreadsheet) wants them only as int. This leads 20_Read_Xls and 30_Template to produce corrupt Xlsx files for any Php release. Change Xls Reader to treat values as int, eliminating the corrupt files.
The new array tests for IMCSC fail on my system because of a rounding error in the 14th (!) decimal position. This is not a real failure. Change the test to use only the first 8 decimal positions.
oleibman
Mark Baker
naotake51
Paul Weidner