Skip to content
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

Generated Excel file loses page breaks when prininting area does not start in the first column #3143

Closed
1 of 8 tasks
alarai opened this issue Oct 26, 2022 · 1 comment · Fixed by #3345
Closed
1 of 8 tasks

Comments

@alarai
Copy link

alarai commented Oct 26, 2022

This is:

- [X] a bug report
- [ ] a feature request
- [X] **not** a usage question (ask them on https://stackoverflow.com/questions/tagged/phpspreadsheet or https://gitter.im/PHPOffice/PhpSpreadsheet)

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.)
image

The area.xlsx file is the same case just with the printing area set to start on the first column, and works as expected
image

<?php

require __DIR__ . '/vendor/autoload.php';

// Load the file
$xlsxReader = \PhpOffice\PhpSpreadsheet\IOFactory::createReader('Xlsx');
$workbook = $xlsxReader->load('area.xlsx');    
//$workbook = $xlsxReader->load('area_ko.xlsx');    

// Save the file
$writer = new  \PhpOffice\PhpSpreadsheet\Writer\Xlsx($workbook);
$writer->save('result.xlsx');

What features do you think are causing the issue

  • Reader
  • Writer
  • Styles
  • Data Validations
  • Formula Calculations
  • Charts
  • AutoFilter
  • Form Elements
@oleibman
Copy link
Collaborator

oleibman commented Feb 4, 2023

When I look at the xml in area_ko, the difference between the original and the version generated by PhpSpreadsheet is that the original brk tag includes the attribute max="16383" and the PhpSpreadsheet file does not. Furthermore, when I add that tag to the PhpSpreadsheet version, the spreadsheet is now as expected. What surprises me is that exactly the same difference occurs between the two versions of area.xlsx, but now it is not necessary to add the new attribute. I imagine it is not a problem to always add it, but I need to think about it some more. FWIW, the documentation on that attribute says "Zero-based index of end row or column of the break. For row breaks, specifies column index; for column breaks, specifies row index". There is also an analogous min parameter; based on your analysis of the problem, it makes more sense to me to set that, but setting that to 1 breaks the spreadsheet, and setting it to 0 doesn't break it but also doesn't fix the problem.

oleibman added a commit to oleibman/PhpSpreadsheet that referenced this issue Feb 4, 2023
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.
oleibman added a commit that referenced this issue Feb 11, 2023
* 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants