Fix#3889. Fix#2464. After evaluating HYPERLINK function specifying cell address(es) rather than literal(s), the calculated hyperlink is attached to the wrong cell. I probably should have figured this out sooner - this is just another instance of the common problem of trying to assign a cell to a variable and then using the variable after a delay during which the "current" cell may have changed. The problem is resolved by storing the cell's worksheet and coordinate on entry to HYPERLINK, then restoring those before manipulating the hyperlink before returning to the caller.
An additional problem with hyperlinks is that assigning a new value to a cell has not cleared any hyperlink associated with the cell. This will now happen, if needed, whenever `setValue` or `setValueExplicit` is called.
A third problem is unaddressed. A (fairly unrealistic) formula like:
```php
$sheet->getCell('A4')->setValue('=LEN(HYPERLINK("http://www.example.com", "Example"))');
```
winds up attaching a hyperlink to the cell when its value is calculated, and it probably shouldn't. However, @TobiasBg reports in 2464 that Excel for Mac does the same thing, and I've just confirmed that Excel 365 on Windows does likewise. Furthermore, the hyperlink which Excel creates is not usable ("Cannot open the specified file"), whereas the link that PhpSpreadsheet creates is usable. So we're not doing any worse than Excel, and arguably doing better. I'm satisfied.
Thank you to @raziel057, who pointed out this problem while doing some research on a PR on which he is working. The code in AxisShadowTest generates a spreadsheet which, if written to disk, will be treated by Excel as corrupt. Since the test doesn't actually generate a spreadsheet, it isn't entirely invalid, but it should do a better job of presenting usable code.
Chart axes have a shadow property, which has many sub-properties. One of these is `size`, which also has sub-properties. Two of those are `kx` and `ky`, representing the skew angle of the shadow. These must be < 90 degrees and > -90 degrees (strangely *not* <= and >=) (see https://ooxml.info/docs/20/20.1/20.1.10/20.1.10.23/). If the supplied value is outside that range, Excel treats the chart as corrupt. That is the main problem with AxisShadowTest - kx was supplied as `-94`. This problem is easily solved in the test by setting it to a valid value instead. And, of course, Chart Writer is changed to not output the value if it is out of range.
Size also has 2 other properties `sx` and `sy`, where a value of 1 indicates 100% of normal size. The test sets `sy` to `254`, a not-particularly sane value. I am fairly certain that `2.54` was intended. I do not believe Excel treats `254` as corrupt, but the test is also changed to supply a sensible value. I imagine that there is a maximum value that Excel will allow, but I don't see it documented anywhere. The UI restricts it to 2 (200%), but larger values are accepted in the xml, so, at least for now, I allow anything.
I have to admit that the Excel UI puzzles me with respect to these properties. There is a single value that can be set for `size` (i.e. no separate property for `sx` and `sy`), and I don't see any way to set the skew angle. There is a settable `angle` property, but that refers to a different shadow property `direction`. At any rate, Excel seems to respond to changes in the xml for all of `sx`, `sy`, `kx`, and `ky`, so we will continue to support them.
Fix#918, which went stale in 2019 and is now reopened. Writing out a RichText object with no text to Xls creates a file which Excel considers corrupt. Treating such an object as a null string rather than a RichText object when writing eliminates the problem.
Fix#4776. DefaultValueBinder treats strings that look like scientific notation as floats. However, if Php evaluates them as `INF`, this can cause problems for Excel. A one-line change to DefaultValueBinder avoids this situation. Tests are added for DefaultValueBinder, and also for StringValueBinder and AdvancedValueBinder, although those extend DefaultValueBinder and needed no code changes.
Fix#1319, which went stale in 2020, and is now reopened. Rowspan is not showing up when saving some spreadsheets as Html. There is some logic concerning property `isSpannedRow` which indicates that this is deliberate, but I have no idea what purpose it serves. It leads directly to this issue, and also adversely affects (in a minor way) some samples (e.g. 17a_Html), where merged cells maintain their text but lose their top and bottom padding. After discarding this logic, the reported problem goes away, the samples look better, and no tests fail. So, whatever its purpose, it wasn't tested for. This PR permanently removes the property, and adds a little additional bulletproofing. A minor accommodation is needed for Tcpdf in one place.
This PR probably deletes more lines from Html Writer than it adds. It would not surprise me if this is one of those unusual cases where Coveralls reports a decrease in coverage despite the fact that all the new code is covered.
This attribute is written by Xlsx Writer, using the `tooltip` attribute, introduced by PR #904 in 2019. It is ignored by Excel, but may be used by Google Sheets (see issue #807). If it is used by anyone, it should be supported by Xlsx Reader, and exist as its own attribute in the `Hyperlink` class. Writer will continue to use tooltip if the new attribute isn't set.
oleibman
Thomas Lallement
Thomas Lallement