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.
Researching a security advisory, the code for handling text colors in Html Writer when the cell is non-numeric and the color is hard-coded in the Number Format looked a bit suspicious. As it turns out, the code was *not* subject to a security exploit. However, the color for the Number Format was ignored. This PR corrects that omission.
oleibman
dependabot[bot]
William Desportes
Adedayo Oyetoke