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

Page breaks order changes when inserting new row which breaks Excel paging #3552

Closed
1 of 8 tasks
alarai opened this issue May 4, 2023 · 1 comment · Fixed by #3555
Closed
1 of 8 tasks

Page breaks order changes when inserting new row which breaks Excel paging #3552

alarai opened this issue May 4, 2023 · 1 comment · Fixed by #3555

Comments

@alarai
Copy link

alarai commented May 4, 2023

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?

Inserting rows should not break page breaks.

What is the current behavior?

Inserting rows changes the behaviour of the page breaks.

What are the steps to reproduce?

Please use the following demonstration file :
demo_break.xlsx

With this snippet :

<?php

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

$xlsxReader = \PhpOffice\PhpSpreadsheet\IOFactory::createReader('Xlsx');
$workbook = $xlsxReader->load('demo_break.xlsx');    
$worksheet = $workbook->getActiveSheet();

$worksheet->insertNewRowBefore(397, 1);


$writer = new  \PhpOffice\PhpSpreadsheet\Writer\Xlsx($workbook);
$writer->save('break_result.xlsx');

When running the script that simply adds a line the page breaks have changed in Excel.
There is an added page break that is not present on the initial file. This is a comparison picture (generated file is on the left, initial file is on the right).

image

As you can see there is only an added line on line 397, and the page break initially between line 417 and 418 correctly moved to between line 418 and 419, but there is a new break between line 451 and 452 which never existed before. If I use this document and print it as PDF the result will not respect the initial page breaks.

I've tried to find the cause of the issue and from what I can see the biggest change that happened after this is that the page breaks are not in the initial order in the array obtained by getBreaks on the spreadsheet.

The order is changed in the following way (first line is before the insertNewRow, second line is after)
A92 A184 A276 A368 A417 A511 A554
A92 A184 A276 A368 A555 A512 A418

The modified page breaks are presents but their order is inverted. The solution seems to have this array in the proper order or at least saved in the correct order as when I added in my code a change to get all the breaks, remove them all, and then recreated them in the correct order resulting in the second line being properly ordered, that added break is not present anymore. So that seems to be the issue.

What features do you think are causing the issue

  • Reader
  • Writer
  • Styles
  • Data Validations
  • Formula Calculations
  • Charts
  • AutoFilter
  • Form Elements

Which versions of PhpSpreadsheet and PHP are affected?

At least from 1.25 to 1.28

oleibman added a commit to oleibman/PhpSpreadsheet that referenced this issue May 5, 2023
Fix PHPOffice#3552. Inserting rows or columns can cause page break arrays to be out of order. Sort them in Worksheet functions getBreaks, getRowBreaks, and getColumnBreaks before returning to caller.
@oleibman
Copy link
Collaborator

oleibman commented May 5, 2023

Thank you for the excellent documentation. If you have the ability to do so, please test with PR 3555.

oleibman added a commit that referenced this issue May 11, 2023
Fix #3552. Inserting rows or columns can cause page break arrays to be out of order. Sort them in Worksheet functions getBreaks, getRowBreaks, and getColumnBreaks before returning to caller.
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