Fix#943, which went stale a long time ago, and is now reopened. I believe that the specific problem in that issue was actually mostly resolved some time ago. However, `highestRow/Column` produces questionable results when the delete range overlaps the highest row/column. That is fixed by this PR.
In addition, `removeRow/Column` allow the specification of a non-negative value for `numberOfRows/Columns`. But the expected results in those cases are not defined, and the actual results probably do not meet user expectations. I believe that very few, if any, users are taking advantage of this "feature", but we may as well straighten it out. For 0 rows/columns, I think it makes perfect sense to do nothing. As for negative - if `removeRow(5, 2)` says to remove 2 rows *starting* with 5, I think `removeRow(5, -2)` ought to remove (up to) 2 rows *ending* with 5. The undefined behaviors are changed to act as described in this paragraph.
A number of interesting performance ideas have been submitted by @kemo. PR #4833 optimizes Xls Reader in a number of different ways. One of those, slightly modified, is to use the protected `readFilter` property which is available to all classes which inherit from `BaseReader` (which all our supported readers do), rather than call the `getReadFilter` method to obtain it (often in a loop). That applies to all readers, not just Xls, and is such a good idea that I am fast-tracking it ahead of 4833. Gnumeric, Ods, Xls, Xlsx, and Xml will all receive small performance boosts from it. Csv already does this, so no change is needed there. Html and Slk do not appear to do any filtering; possibly work for another day.
Writer/Xlsx/Chart hard-codes a lot of output values. While nobody has reported a problem involving these, it makes sense to me to copy those values over from what Xlsx/Reader/Chart read, rather than hard-coding them. This involves adding some new properties to Chart and Layout, all, naturally, initialized to the values that we have been hard-coding.
- Chart\date1904
- Chart\lang
- Chart\pageMargins
- Chart\pageSetup
- Layout\bodyPr
With one exception, I have not investigated any of the new properties in depth. That may come in time. The one I did look at is `date1904`. Chances are that it should match the equivalent spreadsheet setting, but it won't matter if there are no dates on your chart, and it often won't matter even if you do. It may well matter if you are using a `date axis`. While looking into that, it became apparent that some Shared Date conversions need to be a bit more flexible, specifying an optional `calendar` parameter rather than relying on the Spreadsheet `calendar` (which is not accessible while processing the chart) or the Shared\Date `calendar` (which is accessible).
Building on PR #3508 and PR #4393, which allowed ignoring 5 different cell 'errors'. Adding this new one should have been dead easy, but MS, in its own inscrutable way, decided to complicate this by making the xml attribute require its very own namespace, unlike any of its relatives.
There are supposed to be several ways to activate this tag. One is to enter a date in cell A1, then in cell B1 enter the formula `=A1`, and set B1's numeric format to `General`.
Fix#413, which went stale in 2018 and is now reopened. A DataTable can be used on a chart in place of a Legend (or in addition to one, but it doesn't really make sense to have both). The fix was substantially developed by @topaDev before the issue went stale. This PR provides basic support for reading and writing DataTables on charts. The new sample on this PR shows them in action. They have obscure features which are not implemented (e.g. `glow`); those will have to wait for another day.
Fix#411, which went stale in 2018 and is now reopened. You can get a style for a set of cells which uses multiple ranges, e.g. `A1:B2,C5:H10`, but we throw an exception if you try to change the style. I don't know how useful that is, but it's been requested and it's pretty easy to implement with recursion.
The comma in the ranges represents the `union` operator. `getStyle` is very permissive - it will allow almost anything to be specified. However, attempts to use a space as the `intersection` operator, or, indeed, many other nonsense strings, will still be permitted for `getStyle` but will continue to throw an Exception if an attempt is made to alter the style.
Fix#863, which went stale in 2019 and is now reopened. Add methods to `Cell` which operate in a cursor-like manner, allowing you to change to cells on the right, left, down, or up.
Fix#661 (marked stale in 2018, but now reopened). That issue was already mostly resolved by many changes to Xlsx Chart Writer logic some time ago. However, a new problem popped up. PR #2950 added `brightness` logic to Xlsx Reader and Writer. That was done primarily for the benefit of scatter charts. Xlsx Writer writes two brightness properties `lumMod` and `lumOff`. These values are complete complementary (if you know one, you know the other), so I am not sure why both are needed, but my scatter chart testing indicated that they were. It turns out that Radar charts can also set brightness, but, if the writer specifies both `lumMod` and `lumOff`, the resulting chart is slightly off. There may be more to this, but that's all I can deal with for now - I suppress writing `lumOff` if we're writing a radar chart. If there are other problems in this area, I will wait for them to be reported. None of the existing radar chart samples used the brightness properties; however, the example attached to 661 did. It is added as a new Sample, and tests are added.
It requires an index to an array which needs to be supplied as a string, even though the array is indexed exclusively by int. It is called only once in the code base, by some inefficient code which becomes much simpler when restructured and eliminates the call altogether. It is not independently tested. The use case for its existence is not clear. It should probably just be deprecated. However, for now, I'm just allowing the parameter to be int|string, rather than just string, and adding tests.
A large volume of changes due to "sealed" arrays. Some are sensible; some are very confusing and are handled with `ignore` annotations.
Modules in src with changed code (as opposed to doc-blocks or annotations) are:
- DateTimeExcelDays
- Reader/Xlsx
- Reader/Xlsx/AutoFilter
- Reader/Xlsx/Chart
- Reader/Xlsx/ConditionalStyles
- Reader/Xlsx/TableReader
Fix#4875. If rotation is applied to a Drawing, Html Writer will now generate the appropriate Css. This will cause the image to be rotated for Html, Dompdf, and Mpdf; Tcpdf does not recognize the rotation Css.
writeCellFormula() falls back to using $cellValue (the formula source) as
$calculatedValue when getPreCalculateFormulas() is false. The source is
always a string, so the is_string($result) branch always fires, every
formula cell ends up with t="str" — even those whose formula evaluates
to a number or boolean.
Some readers (notably older LibreOffice and Gnumeric) treat t="str" as
a hint that the cell is a string, and either skip recomputation or
present a #NAME error for numeric formulas they would otherwise compute
correctly.
Fix: leave $calculatedValue null and $calculatedValueString empty when
pre-calc is off. The type-inference branches no longer fire, so no t
attribute is written. The surrounding writeElementIf already guards <v>
emission on getPreCalculateFormulas(), so no cached value is written
either — readers see "formula with no cached value, no type hint",
respect the workbook's fullCalcOnLoad="1", and recompute on open.
Updates the existing PreCalcTest assertion to match: <c r="B2"><f>3+A3</f></c>
instead of <c r="B2" t="str"><f>3+A3</f></c>.
My research indicates they should be treated as Big-Endian.
This leaves UTF-7 as the only encoding known to be unsupported by CsvChunk; it will be handled by parent.
Chunk routine would fail if chunk ended between two halves of a surrogate. Fix that.
UTF-7, UTF-16 and UCS-2 (no endian-ness specified and no BOM), UTF-32 and UCS-4 (no endian-ness specified regardless of BOM) all revert to parent routine.