Fix#347, which had gone stale but is now reopened. PhpSpreadsheet is automatically replacing CR-LF and CR with LF. The reason for this is unknown, although I suggest a possibility in the issue. I am not willing to make this a breaking change. This PR adds a new property `preserveCr` with setter and getter to DefaultValueBinder (and, by extension, to StringValueBinder and AdvancedValueBinder). The property defaults to false, but users who wish to preserve CR-LF and CR can set it to true for a Spreadsheet or a Reader.
Fix#1104, which went stale over 6 years ago, and is now reopened. This PR addresses the alignment of the table, not alignment of text. Support is added for the following:
- Html. Full support.
- Mpdf. Full support, except that, when mixed LTR and RTL worksheets are output, all tables will be on the left of the page (but will be properly aligned).
- Tcpdf. Full support when all worksheets being output are RTL; no support when mixed LTR and RTL worksheets are output.
- Dompdf. No support.
By default, when an Xlsx spreadsheet is read, its calculation engine is set to `RETURN_ARRAY_AS_VALUE` for array formulas. The user does have the option to change this. However, the presence of certain metadata in the file indicates that it was saved as if `RETURN_ARRAY_AS_ARRAY` was in use. This PR tests for the metadata, and, if present, sets `...ARRAY` rather than `...VALUE`. This eliminates the need for any extra action on the user's part.
My system short date format is set to `yyyy-mm-dd`.
I used Excel to create a spreadsheet, and included some dates, specifying `yyyy-mm-dd` formatting. When I looked at the resulting spreadsheet, I was surprised to see that Excel had stored the style not as `yyyy-mm-dd`, but rather as builtin style 14 (system short date format). Apparently the fact that the Excel styling matched my system choice was sufficient for it to override my choice! This is an astonishingly user-hostile implementation. Even though there are formats which, by design, "respond to changes in regional date and time settings", and even though the format I selected was not among those, Excel decided it was appropriate to vary the display even when I said I wanted an unvarying format.
This PR adds a new method `replaceBuiltinNumberFormat` to undo the damage that Excel does in such a situation. It also adds an `Excel Anomalies` document to the formal documentation, just to make situations like this readily available to the community.
BTW, Excel's sabotage can be avoided by using a number format style like `[Black]yyyy-mm-dd`.
Fix#4528. Fix#2507. Ods Reader expects `table:table-row` to descend directly from `table:table`. But it turns out that it can be nested under `table:table-header-rows`, `table:table-rows`, or `table:table-row-group`. Similar considerations apply to `table:table-column`. Ods Reader is changed to process the nesting tags, and therefore the nested tags underneath them. This is a major change, but it doesn't seem to have broken any existing tests or samples.
No attempt is made to add any of the nesting tags in Ods Writer.
It should be noted that 4528 has an additional problem, which has been reported as issue #4530. It is not fixed by this PR.
Fix#4521. Reader/Csv (which can be invoked by IOFactory::read), checks the mimetype of files if they don't have a csv/tsv extension. It allows empty files, whose mimetype was set to `inode/x-empty` for Php5.3.11 through Php7.3.33 (except for 5.4.0). For 5.3.1-5.3.10, 5.4.0, and 7.4.0+, the mimetype is `application/x-empty`. Reader/Csv recognizes the `inode` version but not the `application` version, which this PR adds.
The person who issued the report also noted that, for a file consisting of cr-lf, Php8.1.* and Php8.2.* report the mimetype as `application/octet-stream`, whereas all other releases report it as `text/plain`. The behavior of Php8.1/2 seems to be a bug, and I cannot possibly guess all the conditions that might lead to that bug. So I will not fix that problem. Anyone who is adversely affected by it can either add a `csv` extension to the filename, or upgrade to Php8.3+, or pre-process the file (e.g. to make it truly empty) before passing it to PhpSpreadsheet. A test case to document the problem is added for documentary purposes; the test will be skipped for Php8.1/2, but run for all other releases.
Fix#4260. A number of Security Advisories related to libxml_options were opened. In the end, we disabled the ability to specify any libxml_options. However, some users were adversely affected because they needed LIBXML_PARSEHUGE for some of their files. Having finally obtained access to a file demonstrating this problem, we can restore this ability.
- The operation is potentially dangerous, a vector for memory leaks and out-of-memory errors. It is not recommended unless absolutely needed.
- It will not be permitted as a global (static) property with the ability to adversely affect other users on the same server.
- It will instead be implemented as an instance property of Xlsx Reader (default to false), with a setter. I do not see a use case for a getter.
- People will need to set this property individually for each file which they think needs it.
- This change will be backported to all supported releases.
- The sheer size and processing time for the file involved makes it impractical to add a formal test case. It has, nevertheless, been tested satisfactorily.
oleibman
dependabot[bot]
Sebastian Hädrich