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

Xlsx writer - wrong rId for Drawings in Rels, when printerSettings is present in file #1236

Closed
noblescz opened this issue Nov 10, 2019 · 3 comments · Fixed by #1462
Closed

Comments

@noblescz
Copy link

noblescz commented Nov 10, 2019

This is:

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

What is the expected behavior?

After addSheet(), which contains printer settings and images at the same time, images are displayed correctly (have correct rId in xl/worksheets/sheet2.xml.rels)

What is the current behavior?

After addSheet(), which contains printer settings and images at the same time, file is opened as corupted and images are discarded - removed from file.

rId in xl/worksheets/sheet2.xml.rels has wrong index, because number one is taken by printerSettings

What are the steps to reproduce?

addSheet(), which contains printer settings and images at the same time - the sheet is created in MS Office

Which versions of PhpSpreadsheet and PHP are affected?

1.9.0 and previous versions

This worked for me
PROPOSED PATCH:
/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Writer/Xlsx/Rels.php
line: 200

ADD:
if (isset($unparsedLoadedData['sheets'][$pWorksheet->getCodeName()]['printerSettings'])&&is_array($unparsedLoadedData['sheets'][$pWorksheet->getCodeName()]['printerSettings'])) {
$d += count($unparsedLoadedData['sheets'][$pWorksheet->getCodeName()]['printerSettings']);
}

EXPLANATION:
If unparsed data contatains 'printerSettings' rise referenceID

NOT SURE if printerSettings have always referenceID=1, so the patch might not be universal

@stale
Copy link

stale bot commented Jan 9, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If this is still an issue for you, please try to help by debugging it further and sharing your results.
Thank you for your contributions.

@stale stale bot added the stale label Jan 9, 2020
@stale stale bot closed this as completed Jan 16, 2020
@noblescz
Copy link
Author

This must be an explanation for many issues, where "loss of images" is reported.

Suggested solution works for me, succesfully. Please implement it!

@oleibman
Copy link
Collaborator

Addressed by PR #1462 and PR #1690

@oleibman oleibman removed the stale label Jul 14, 2024
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