Fix#3159, at least as far as we can. Requester would probably prefer that we automatically translate the PhpSpreadsheet header and footer information to forms that the Pdf vendors can handle. That seems like it would be very difficult. On the other hand, we can add some new properties to the Pdf writers to make it *relatively* easy for the user to define their own headers and footers for the writers.
Mpdf, as mentioned in the issue, can already handle this in conjunction with the `editHtmlCallback` property. This is demonstraded in Sample21c, which is now renamed to something more descriptive, `Mpdf_Custom_Headers`. That is the only change needed for Mpdf.
Tcpdf, which currently automatically prevents any footers or headers, needs some new properties to allow them. Even with the new properties, a user would need to extend both PhpSpreadsheet's Tcpdf Writer, and the vendor's own class (extending that class is actually the vendor's recommendation). A new sample `Tcpdf_Custom_Headers` demonstrates how this would be done.
Dompdf has 2 ways to add headers and footers. One is pretty good at styling, but doesn't offer much flexibility for dynamic properties other than the current page number; it can't handle different odd/even/first headers, nor the number of pages in the document. The second makes the dynamic properties possible, but seems difficult to style. Two new samples `Dompdf_Custom_Headers` (using `editHtmlCallback`) and `Dompdf_Canvas_Headers` (using a new protected method `callPageScript`) illustrate the use of each.
None of the samples demonstrates the full capabilities of what can go into a header or footer. I consider that out of scope; enabling the ability is one thing, perfecting it is quite another.
Fix#1810, just before it turns 6 years old. Reporter thinks it can save time. Easy to implement, especially with the advent of named parameters which were not available when issue was opened.
Issue3982Test mysteriously ran into memory problems when we migrated from Phpunit 9 to 10. It wasn't all that critical a test, so it has been disabled ever since. I finally had some time to research, and the problem is unquestionably with Phpunit's `assertCount` test - it doesn't like something about our array. However, we can easily redo that test by using Php's native `count` function, and testing that result with `assertSame`. I have not yet succeeded at simplifying the test to a state where I am willing to report the bug, but I'll keep trying. In the meantime, the test is recoded, and can now be run successfully. No source code changes.
This will improve round-tripping from Xlsx to Html and back again. The calculated result will still be what is displayed when viewing the result in a browser, but, using the new option, the original formula can be reconstructed when PhpSpreadsheet reads the Html file. The ability to recognize this situation is automatically enabled in Html Reader, however, to avoid BC issues, it needs to be explicitly enabled for Html Writer. A new boolean property `dataFormula` and setter are added to Writer; it will default to current behavior `false` for now, but my plan is to change the default in the next breaking release. I cannot think of a decent use case for a getter, so have not added one.
Fix#4280, an issue with many problems; this is the last one (PR #4281 and PR #4677 dealt with other aspects of the problem). New releases of Excel allow representing TRUE/FALSE as a checked/unchecked checkbox. This requires a change to Styles, as expected. But Excel has implemented it in such a manner that changes are also required to Content_Types and workbook.xml.rels; and a new xml file propertyFeatureBag is also required. Seems like a lot of work for such a small change. A new property is added to Style, but only Xlsx Reader and Writer support it; no other format does.
oleibman
dependabot[bot]
xannyprox