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>.
Html Reader recognizes a `data-format` attribute for storing the number format associated with a cell. However, Html Writer does not set this attribute. This PR offers a new Writer property `preserveFormatAndValue` and setter; when `true`, for any cell which uses a number format other than the default `General` the writer will generate a `data-format` attribute and, for strings or numbers, it will also generate a `data-value` attribute. This will increase the accuracy of the spreadsheet when reading/writing Html.
To make this change less abstract, assume a cell which has a value of `1234` and a number format of `$#,###.00`. The cell displayed in the generated Html will appear, regardless of the setting of the new property, as `$1,234.00`. However, the Reader currently treats it as a string with that value. If the html has been generated with the new property set to `true`, the Reader will treat it as a numeric cell with a value of `1234` and a style of `#,###.00`. This permits a more accurate reproduction of the original spreadsheet.
I suspect that setting the new property, aside from causing a slight increase in file size, will not cause any significant breaks. However, I'm not totally convinced, so the property will default to `false` (no change in behavior). The default may change in a future breaking release.