-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Generated Excel file loses page breaks when prininting area does not start in the first column #3143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
When I look at the xml in area_ko, the difference between the original and the version generated by PhpSpreadsheet is that the original |
Fix PHPOffice#3143. Page break was dropped. Difference between good and bad was the use of attribute `max` in `brk` tag in the good spreadsheet. However, `max` was *not* required in a similar spreadsheet. So the reason for the problem isn't completely explained. Nevertheless, it can't really hurt to capture the `max` value on read (if present) and generate it on write. This resolves the issue. User is also permitted to specify max column when setting a row break programatically. I am not yet in position to document when that might be a good idea.
* Permit Max Column for Row Breaks Fix #3143. Page break was dropped. Difference between good and bad was the use of attribute `max` in `brk` tag in the good spreadsheet. However, `max` was *not* required in a similar spreadsheet. So the reason for the problem isn't completely explained. Nevertheless, it can't really hurt to capture the `max` value on read (if present) and generate it on write. This resolves the issue. User is also permitted to specify max column when setting a row break programatically. I am not yet in position to document when that might be a good idea. * Case-sensitive Directory Name Not a problem on my Windows system. * Update Documentation and Add Tests Change is necessitated by probable Excel bug. * Unhappy With Initial Implementation I kind of shoe-horned it in. Better to create a new PageBreak class, which will make it easier to accomodate any future surprises about page break handling. The only difficulty with the new approach is making sure getBreaks maintains backwards compatibility. New tests will ensure that.
Fix PHPOffice#1275, which had been closed as stale, and is now reopened pending the implementation of this PR. If there is a page break inside a defined print area, Excel may not render the print correctly unless the xml `brk` tag contains a `max` attribute. Libre Office renders it correctly. This seems like a bug in Excel (https://learn.microsoft.com/en-us/openspecs/office_standards/ms-oe376/b32ae11b-dee7-4dcb-9b46-a0feb32ce94f states that Office ignores min and max). PR PHPOffice#3345 (issue PHPOffice#3143) already addressed this problem by allowing the user to explicitly specify a `max` property in the PageBreak object. This PR eliminates the need for the user to make use of that kludge, by adding `max` to the xml whenever a page break is specified on a sheet with a defined print area. Xlsx Reader will now ignore the `max` attribute for row breaks, since it is no longer needed; it already ignores it for column breaks. The user may still set the `max` property if desired, just in case the new treatment is not adequate (I have not found a case where that is true). Two existing unit tests are very marginally changed because of this PR.
This is:
What is the expected behavior?
The Printing configuration should be kept after saving the document.
What is the current behavior?
When the printing area does not start on the first column, the page breaks disappears or ar return to automatic ones.
What are the steps to reproduce?
This simple code allows to test the case, it just opens the file and save it without modification.

The area_ko.xlsx gives the following result (left is the original file, right is after opening and saving it with PhpSpreadsheet.)
The area.xlsx file is the same case just with the printing area set to start on the first column, and works as expected

What features do you think are causing the issue
The text was updated successfully, but these errors were encountered: