oleibman

oleibman

Member Since 6 years ago

0 organizations

Experience Points
0
follower
Lessons Completed
0
follow
Best Reply Awards
4
repos

227 contributions in the last year

oleibman Most Used Languages
oleibman GitHub Stats

4 Pinned

⚡ A pure PHP library for reading and writing word processing documents
⚡ ARCHIVED
⚡ Shared components between all PHPOffice projects
⚡ A pure PHP library for reading and writing spreadsheet files
Jun
22
1 day ago
Activity icon
issue

oleibman issue comment PHPOffice/PhpSpreadsheet

oleibman
oleibman

Y2038 Problems?

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?

Software should continue to work after epoch change in 2038.

What is the current behavior?

Running on 64-bit Php is probably okay. 32-bit may have problems.

What are the steps to reproduce?

Too early? I think not. YMMV. The analysis below is probably not complete, but it's a start.

PHP itself has some Y2038 exposure (e.g. see https://bugs.php.net/bug.php?id=64992). Dealing with these is clearly out of scope for PhpSpreadsheet.

I think that PhpSpreadsheet is pretty well positioned to avoid problems. However, it does use functions mktime, gmmktime, and strtotime. Those functions will work just fine after the Y2038 transition when 64-bit PHP is used. However, they will fail when 32-bit PHP is used. It is hard to guess if 32-bit PHP will even be a thing when the time comes, but it's best to be prepared. I don't know that it is possible to make 64-bit a requirement, and, even if it is, doing that seems far too drastic. On the other hand, it should be possible to have the unit tests run in a 32-bit region. I don't know how to arrange that. I would suggest that it is probably sufficient to run one 32-bit region rather than a 32-bit version of each supported release of PHP.

Scanning the source code, I find the following use of mktime/gmmktime:

  • samples/templates/SampleSpreadsheet - gmmktime is used to populate one cell with the current date. This is very easily solved by instead using DateTime (which is supported beyond the epoch even on 32-bit systems), and I have a PR which I will be pushing shortly to address this.
  • Worksheet/Autofilter and 3 samples/10_Autofilter*. This is likely to fail before the others, since the tests involve filtering on future dates.
  • Shared/OLE - this looks fairly easy to recode, although research is needed to come up with suitable test cases.

The use of strtotime is more extensive. I haven't researched any of these:

  • Document/Properties
  • Reader/Gnumeric
  • Reader/Ods
  • Reader/Xml
  • Reader/Ods/Properties
  • Reader/Xlsx/Properties
  • Worksheet/AutoFilter

Scanning the vendor directory, the only uses of mktime/gmmktime that I see are in jpgraph, which is already problematic because it isn't supported through Composer. Again, I think this is out of scope. There is more extensive use of strtotime:

  • jpgraph
  • 1 use in phenx
  • 2 uses in symfony/finder, plus tests for symfony/finder
  • 1 use in tcpdf_static

My reading of the documentation for the strftime, localtime, date, and time functions, which take a timestamp argument, suggests that they may also be problematic after the epoch, especially when the timestamp argument is omitted. If so, this is probably a problem that PHP needs to address. For the record, Calculation/DateTime uses some of these.

Which versions of PhpSpreadsheet and PHP are affected?

AFAIK, only 32-bit PHP is affected.

oleibman
oleibman

PR #2141, which deals with many of the AutoFilter problems, has been merged. PR #2162 , which, I hope, deals with the rest of the AutofFilter problems, has been pushed.

pull request

oleibman pull request PHPOffice/PhpSpreadsheet

oleibman
oleibman

Xlsx Reader Better Namespace Handling Phase 1

There have been a number of issues concerning the handling of legitimate but unexpected namespace prefixes in Xlsx spreadsheets created by software other than Excel and PhpSpreadsheet/PhpExcel.I have studied them, but, till now, have not had a good idea on how to act on them. A recent comment https://github.com/PHPOffice/PhpSpreadsheet/issues/860#issuecomment-824926224 in issue #860 by @IMSoP has triggered an idea about how to proceed.

Gnumeric Reader was recently changed to handle namespaces better. Using that as a model, this PR begins the process of doing the same for Xlsx. Xlsx is much larger and more complicated than Gnumeric, hence the need to tackle it in multiple phases. I believe that this PR handles all of:

  • listWorkSheetNames
  • listWorkSheetInfo. Note that there was a bug in this function which would cause it to count only used columns rather than all columns. That bug is corrected.
  • active sheet
  • selected cell and top left cell
  • cell content (formulas, numbers, text)
  • hyperlinks
  • comments (partial - see below)

This PR does not address:

  • styles
  • images and charts
  • VBA and ribbons
  • many other items, I'm sure

The issue for non-standard namespacing till now has been the use of unexpected prefixes. While I was working on this change, @Lambik introduced issue #2067 PR #2068 which introduced a completely different problem - the use of unexpected URLs. That PR and the issue associated with it were quite well documented, including the supplying of a test file and tests for it. I asked if I could take a look to see if it could be integrated with my change, and the result seems to be yes, so those changes are also part of this PR.

While adding a comment to my test file, I discovered that Microsoft had added "threaded comments" as a new feature. I believe these are not yet supported by PhpSpreadsheet, and I am not going to add it, at least not now. I believe that, among other things, this will make identifying the author of a comment more difficult.

Although there are a number of Phpstan baseline changes as part of this PR, I did not attempt to resolve all Phpstan reports for Reader/Xlsx. Nor did I do anything to increase coverage. This change is already large and complex enough without those efforts.

I will add more detail as comments after I push this change.

This is:

- [x] a bugfix
- [ ] a new feature

Checklist:

Why this change is needed?

Activity icon
issue

oleibman issue comment PHPOffice/PhpSpreadsheet

oleibman
oleibman

Xlsx Reader Better Namespace Handling Phase 1

There have been a number of issues concerning the handling of legitimate but unexpected namespace prefixes in Xlsx spreadsheets created by software other than Excel and PhpSpreadsheet/PhpExcel.I have studied them, but, till now, have not had a good idea on how to act on them. A recent comment https://github.com/PHPOffice/PhpSpreadsheet/issues/860#issuecomment-824926224 in issue #860 by @IMSoP has triggered an idea about how to proceed.

Gnumeric Reader was recently changed to handle namespaces better. Using that as a model, this PR begins the process of doing the same for Xlsx. Xlsx is much larger and more complicated than Gnumeric, hence the need to tackle it in multiple phases. I believe that this PR handles all of:

  • listWorkSheetNames
  • listWorkSheetInfo. Note that there was a bug in this function which would cause it to count only used columns rather than all columns. That bug is corrected.
  • active sheet
  • selected cell and top left cell
  • cell content (formulas, numbers, text)
  • hyperlinks
  • comments (partial - see below)

This PR does not address:

  • styles
  • images and charts
  • VBA and ribbons
  • many other items, I'm sure

The issue for non-standard namespacing till now has been the use of unexpected prefixes. While I was working on this change, @Lambik introduced issue #2067 PR #2068 which introduced a completely different problem - the use of unexpected URLs. That PR and the issue associated with it were quite well documented, including the supplying of a test file and tests for it. I asked if I could take a look to see if it could be integrated with my change, and the result seems to be yes, so those changes are also part of this PR.

While adding a comment to my test file, I discovered that Microsoft had added "threaded comments" as a new feature. I believe these are not yet supported by PhpSpreadsheet, and I am not going to add it, at least not now. I believe that, among other things, this will make identifying the author of a comment more difficult.

Although there are a number of Phpstan baseline changes as part of this PR, I did not attempt to resolve all Phpstan reports for Reader/Xlsx. Nor did I do anything to increase coverage. This change is already large and complex enough without those efforts.

I will add more detail as comments after I push this change.

This is:

- [x] a bugfix
- [ ] a new feature

Checklist:

Why this change is needed?

oleibman
oleibman
pull request

oleibman pull request PHPOffice/PhpSpreadsheet

oleibman
oleibman

Reader/Gnumeric vs. Scrutinizer

Just reviewing Scrutinizer's list of "bugs". There are 19 ascribed to me. For some, I will definitely take no action (e.g. use of bitwise operators in AND, OR, and XOR functions). However, where I can clean things up so that Scrutinizer is satisfied and the resulting code is not too contorted, I will make an attempt.

I believe this is the only one with which will involve more than 2 or 3 changes. It fixes 5 items ascribed to me, and 4 to others.

This is:

- [x] a bugfix
- [ ] a new feature

Checklist:

Why this change is needed?

Activity icon
created branch

oleibman in oleibman/PhpSpreadsheet create branch scrutgnu

createdAt 18 hours ago
Jun
21
2 days ago
Activity icon
issue

oleibman issue comment PHPOffice/PhpSpreadsheet

oleibman
oleibman

Xlsx Reader Better Namespace Handling Phase 1 Try2

This is a replacement for #2088, which has run into merge conflicts. I will close that PR in the near future, however the comments in that PR may prove useful for this one. While that PR has been in draft status all along, I am marking this one as ready. I will gladly add additional tests (and, of course, make code changes) that anyone has to suggest, but, with my most recent test files which I will describe in a separate comment, I have no further ideas on useful additions.

As mentioned in the earlier ticket, this is a risky change. But, as has been demonstrated, delaying it comes with its own set of risks. It would be helpful to have a temporary moratorium on changes to Reader/Xlsx until this change is merged.

The original commit message follows.

There have been a number of issues concerning the handling of legitimate but unexpected namespace prefixes in Xlsx spreadsheets created by software other than Excel and PhpSpreadsheet/PhpExcel.I have studied them, but, till now, have not had a good idea on how to act on them. A recent comment https://github.com/PHPOffice/PhpSpreadsheet/issues/860#issuecomment-824926224 in issue #860 by @IMSoP has triggered an idea about how to proceed.

Gnumeric Reader was recently changed to handle namespaces better. Using that as a model, this PR begins the process of doing the same for Xlsx. Xlsx is much larger and more complicated than Gnumeric, hence the need to tackle it in multiple phases. I believe that this PR handles all of:

  • listWorkSheetNames
  • listWorkSheetInfo. Note that there was a bug in this function which would cause it to count only used columns rather than all columns. That bug is corrected.
  • active sheet
  • selected cell and top left cell
  • cell content (formulas, numbers, text)
  • hyperlinks
  • comments (partial - see below)

This PR does not address:

  • styles
  • images and charts
  • VBA and ribbons
  • many other items, I'm sure

The issue for non-standard namespacing till now has been the use of unexpected prefixes. While I was working on this change, @Lambik introduced issue #2067 PR #2068 which introduced a completely different problem - the use of unexpected URLs. That PR and the issue associated with it were quite well documented, including the supplying of a test file and tests for it. I asked if I could take a look to see if it could be integrated with my change, and the result seems to be yes, so those changes are also part of this PR.

While adding a comment to my test file, I discovered that Microsoft had added "threaded comments" as a new feature. I believe these are not yet supported by PhpSpreadsheet, and I am not going to add it, at least not now. I believe that, among other things, this will make identifying the author of a comment more difficult.

Although there are a number of Phpstan baseline changes as part of this PR, I did not attempt to resolve all Phpstan reports for Reader/Xlsx. Nor did I do anything to increase coverage. This change is already large and complex enough without those efforts.

I will add more detail as comments after I push this change.

This is:

- [x] a bugfix
- [ ] a new feature

Checklist:

Why this change is needed?

oleibman
oleibman

I am going to continue to study the change for a few more days to see if any tweaks or new test files are needed. I expect to give it a "go ahead" signal before Friday.

Activity icon
issue

oleibman issue comment PHPOffice/PhpSpreadsheet

oleibman
oleibman

Xlsx Reader Better Namespace Handling Phase 1 Try2

This is a replacement for #2088, which has run into merge conflicts. I will close that PR in the near future, however the comments in that PR may prove useful for this one. While that PR has been in draft status all along, I am marking this one as ready. I will gladly add additional tests (and, of course, make code changes) that anyone has to suggest, but, with my most recent test files which I will describe in a separate comment, I have no further ideas on useful additions.

As mentioned in the earlier ticket, this is a risky change. But, as has been demonstrated, delaying it comes with its own set of risks. It would be helpful to have a temporary moratorium on changes to Reader/Xlsx until this change is merged.

The original commit message follows.

There have been a number of issues concerning the handling of legitimate but unexpected namespace prefixes in Xlsx spreadsheets created by software other than Excel and PhpSpreadsheet/PhpExcel.I have studied them, but, till now, have not had a good idea on how to act on them. A recent comment https://github.com/PHPOffice/PhpSpreadsheet/issues/860#issuecomment-824926224 in issue #860 by @IMSoP has triggered an idea about how to proceed.

Gnumeric Reader was recently changed to handle namespaces better. Using that as a model, this PR begins the process of doing the same for Xlsx. Xlsx is much larger and more complicated than Gnumeric, hence the need to tackle it in multiple phases. I believe that this PR handles all of:

  • listWorkSheetNames
  • listWorkSheetInfo. Note that there was a bug in this function which would cause it to count only used columns rather than all columns. That bug is corrected.
  • active sheet
  • selected cell and top left cell
  • cell content (formulas, numbers, text)
  • hyperlinks
  • comments (partial - see below)

This PR does not address:

  • styles
  • images and charts
  • VBA and ribbons
  • many other items, I'm sure

The issue for non-standard namespacing till now has been the use of unexpected prefixes. While I was working on this change, @Lambik introduced issue #2067 PR #2068 which introduced a completely different problem - the use of unexpected URLs. That PR and the issue associated with it were quite well documented, including the supplying of a test file and tests for it. I asked if I could take a look to see if it could be integrated with my change, and the result seems to be yes, so those changes are also part of this PR.

While adding a comment to my test file, I discovered that Microsoft had added "threaded comments" as a new feature. I believe these are not yet supported by PhpSpreadsheet, and I am not going to add it, at least not now. I believe that, among other things, this will make identifying the author of a comment more difficult.

Although there are a number of Phpstan baseline changes as part of this PR, I did not attempt to resolve all Phpstan reports for Reader/Xlsx. Nor did I do anything to increase coverage. This change is already large and complex enough without those efforts.

I will add more detail as comments after I push this change.

This is:

- [x] a bugfix
- [ ] a new feature

Checklist:

Why this change is needed?

oleibman
oleibman

Forgot to add "more detail" when I pushed this change. Here it is.

I think this change is ready, but it requires more scrutiny than most changes. It is unusually likely that I didn't dot an "i" or cross a "t" somewhere that isn't caught in unit testing. Part of the reason is because test coverage of Reader/Xlsx isn't all that high in the first place, and a fair proportion of the coverage comes from samples. Here's an explanation for some of what I've done, since my motives won't always be obvious.

Added a Reader/Xlsx/Namespaces class to eliminate the hard-coded urls found in dozens of places throughout Reader/Xlsx and its subclasses.

Added 2 routines, loadZip and loadZipNoNamespace, to handle the reading of the zip files. Both can specify a namespace, but the latter ignores it. Any calls to loadZipNoNamespace should act exactly the same as before, but they indicate that I either haven't analyzed the call yet, or haven't been able to determine whether specifying a namespace would be a more correct action. In a couple of cases, I call both because namespaced seems to work with part of the code that follows, but not with other parts.

Introduced 2 functions, testSimpleXml and xpathNoFalse, to attempt to eliminate the plethora of SimpleXMLElement|false and array|false possibilities that Phpstan (and, doubtless, Scrutinizer) dislike. Similarly, I have tried to cast SimpleXMLElement to string once in cases where it is done several times within a few statements.

I did not do any major refactoring with this PR. Reader/Xlsx is desparately in need of it; I just couldn't figure out how to break it up with this PR. I plan to come back to it. I do, however, have some ideas for how to refactor Styles, which is what I plan to do next if this PR is merged.

The new test file namespacestd.xlsx and the tests associated with are based on the Sylk test file, because I know that covers a lot of cases. The new test file namespacenonstd.xlsx is crafted by hand from this so that they can run identical tests (and also because, despite the number of namespace issues, I couldn't find much in the way of useful example files). Some of the nonstd tests are, of course, marked incomplete for now.

The test file namespacepurl.xlsx and its tests come from @Lambik PR #2068.

The new test file issue2109b.xlsx is based on a file uploaded for issue #2109. I have manually confirmed that I can read and make an unstyled copy of the uploaded file, but it is much too large to add to the unit test suite. I used sed and vim to delete all but the first few rows of the spreadsheet. This brings it to a manageable size for the test suite. Although it required some manual manipulation on my part, I think we can classify it as "naturally" created (as opposed to namespacenonstd).

The new test file openpyxl35.xlsx was created with ancient version 2.3.5 of openpyxl, before its namespacing was changed to be PhpSpreadsheet-compatible. Not all the xml files within it use unexpected namespacing, but xl/themes/theme1.xml, xl/workbook.xml, docprops/app.xml, and docprops/core.xml all do, and I think that the last 3 are definitely involved in the unit tests. The technique used to create this file might prove helpful in targeting future tests.

So, we now have files generated in 4 different ways that would not have been readable by PhpSpreadsheet before this change. I am open to adding new methods, but I think this is a sufficient number.

Activity icon
issue

oleibman issue PHPOffice/PhpSpreadsheet

oleibman
oleibman

Locale Files are Generated with Windows Line-endings

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?

Files should have Unix line endings.

What is the current behavior?

They have Windows line endings. This causes git to think they have all been changed; at least that's what it thinks on my Windows machine (which I have configured to use Unix line endings). It would be easy enough to change them all, but, since they appear to be generated, I'm not sure any such change would stick.

What are the steps to reproduce?

Please provide a Minimal, Complete, and Verifiable example of code that exhibits the issue without relying on an external Excel file or a web server:

Which versions of PhpSpreadsheet and PHP are affected?

This seems to have been caused by #2111.

Activity icon
issue

oleibman issue comment PHPOffice/PhpSpreadsheet

oleibman
oleibman

Locale Files are Generated with Windows Line-endings

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?

Files should have Unix line endings.

What is the current behavior?

They have Windows line endings. This causes git to think they have all been changed; at least that's what it thinks on my Windows machine (which I have configured to use Unix line endings). It would be easy enough to change them all, but, since they appear to be generated, I'm not sure any such change would stick.

What are the steps to reproduce?

Please provide a Minimal, Complete, and Verifiable example of code that exhibits the issue without relying on an external Excel file or a web server:

Which versions of PhpSpreadsheet and PHP are affected?

This seems to have been caused by #2111.

Jun
19
4 days ago
push

oleibman push oleibman/PhpSpreadsheet

oleibman
oleibman

One More Attempt to Satisfy Scrutinizer

We shall sess.

commit sha: a488574cb614daec5e52d59017e46752228270ae

push time in 4 days ago
push

oleibman push oleibman/PhpSpreadsheet

oleibman
oleibman

Scrutinizer

Add 2 casts to eliminate minor Scrutinizer problem.

commit sha: 2723167d71ffa3fcdc60814d962f2f02fba79987

push time in 4 days ago
pull request

oleibman pull request PHPOffice/PhpSpreadsheet

oleibman
oleibman

Locale Generator - Change to Use Unix Line Endings Even on Windows

See issue #2172. The locale files are regenerated whenever the test suite is run.

The use of PHP_EOL in LocaleGenerator.php is awkward on Windows systems, since it causes git to think the file has changed. Change to use "\n" instead.

This is:

- [x] a bugfix
- [ ] a new feature

Checklist:

Why this change is needed?

Activity icon
created branch

oleibman in oleibman/PhpSpreadsheet create branch eollocale

createdAt 4 days ago
Activity icon
issue

oleibman issue comment PHPOffice/PhpSpreadsheet

oleibman
oleibman

Locale Files are Generated with Windows Line-endings

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?

Files should have Unix line endings.

What is the current behavior?

They have Windows line endings. This causes git to think they have all been changed; at least that's what it thinks on my Windows machine (which I have configured to use Unix line endings). It would be easy enough to change them all, but, since they appear to be generated, I'm not sure any such change would stick.

What are the steps to reproduce?

Please provide a Minimal, Complete, and Verifiable example of code that exhibits the issue without relying on an external Excel file or a web server:

Which versions of PhpSpreadsheet and PHP are affected?

This seems to have been caused by #2111.

oleibman
oleibman

Aha, it all starts to make sense now. There is a locale generator test which runs as part of the test suite, and that's what's causing the files to appear changed. I think I now know the fix, and will start working on it.

pull request

oleibman pull request PHPOffice/PhpSpreadsheet

oleibman
oleibman

Xlsx Reader Better Namespace Handling Phase 1 Try2

This is a replacement for #2088, which has run into merge conflicts. I will close that PR in the near future, however the comments in that PR may prove useful for this one. While that PR has been in draft status all along, I am marking this one as ready. I will gladly add additional tests (and, of course, make code changes) that anyone has to suggest, but, with my most recent test files which I will describe in a separate comment, I have no further ideas on useful additions.

As mentioned in the earlier ticket, this is a risky change. But, as has been demonstrated, delaying it comes with its own set of risks. It would be helpful to have a temporary moratorium on changes to Reader/Xlsx until this change is merged.

The original commit message follows.

There have been a number of issues concerning the handling of legitimate but unexpected namespace prefixes in Xlsx spreadsheets created by software other than Excel and PhpSpreadsheet/PhpExcel.I have studied them, but, till now, have not had a good idea on how to act on them. A recent comment https://github.com/PHPOffice/PhpSpreadsheet/issues/860#issuecomment-824926224 in issue #860 by @IMSoP has triggered an idea about how to proceed.

Gnumeric Reader was recently changed to handle namespaces better. Using that as a model, this PR begins the process of doing the same for Xlsx. Xlsx is much larger and more complicated than Gnumeric, hence the need to tackle it in multiple phases. I believe that this PR handles all of:

  • listWorkSheetNames
  • listWorkSheetInfo. Note that there was a bug in this function which would cause it to count only used columns rather than all columns. That bug is corrected.
  • active sheet
  • selected cell and top left cell
  • cell content (formulas, numbers, text)
  • hyperlinks
  • comments (partial - see below)

This PR does not address:

  • styles
  • images and charts
  • VBA and ribbons
  • many other items, I'm sure

The issue for non-standard namespacing till now has been the use of unexpected prefixes. While I was working on this change, @Lambik introduced issue #2067 PR #2068 which introduced a completely different problem - the use of unexpected URLs. That PR and the issue associated with it were quite well documented, including the supplying of a test file and tests for it. I asked if I could take a look to see if it could be integrated with my change, and the result seems to be yes, so those changes are also part of this PR.

While adding a comment to my test file, I discovered that Microsoft had added "threaded comments" as a new feature. I believe these are not yet supported by PhpSpreadsheet, and I am not going to add it, at least not now. I believe that, among other things, this will make identifying the author of a comment more difficult.

Although there are a number of Phpstan baseline changes as part of this PR, I did not attempt to resolve all Phpstan reports for Reader/Xlsx. Nor did I do anything to increase coverage. This change is already large and complex enough without those efforts.

I will add more detail as comments after I push this change.

This is:

- [x] a bugfix
- [ ] a new feature

Checklist:

Why this change is needed?

Activity icon
created branch

oleibman in oleibman/PhpSpreadsheet create branch namexlsx5

createdAt 4 days ago
Activity icon
issue

oleibman issue comment PHPOffice/PhpSpreadsheet

oleibman
oleibman

Locale Files are Generated with Windows Line-endings

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?

Files should have Unix line endings.

What is the current behavior?

They have Windows line endings. This causes git to think they have all been changed; at least that's what it thinks on my Windows machine (which I have configured to use Unix line endings). It would be easy enough to change them all, but, since they appear to be generated, I'm not sure any such change would stick.

What are the steps to reproduce?

Please provide a Minimal, Complete, and Verifiable example of code that exhibits the issue without relying on an external Excel file or a web server:

Which versions of PhpSpreadsheet and PHP are affected?

This seems to have been caused by #2111.

oleibman
oleibman

As a workaround, I can run bin/generate-locales under Cygwin. This changes the (line endings in) the locale files, but git no longer thinks they have been changed. It's weird, but it works. My guess is that "\n" rather than PHP_EOL in infra/LocaleGenerator.php will probably figure into the solution, if any is required.

Jun
18
5 days ago
push

oleibman push PHPOffice/PhpSpreadsheet

oleibman
oleibman

Move Reader Xlsx Tests from Reader to Reader/Xlsx Try 2

PR #2088 is having major merge problems. This is partly because it moves some tests from Reader to Reader/Xlsx. Making this move beforehand may help. Or it may make things worse, but they are already bad enough that I am contemplating redoing the PR. If I do that, having this done beforehand will make things easier.

This PR does nothing but move some tests. This will make it easier to test changes to Xlsx Reader without having to run each test individually, or without having to run tests for all the other readers at the same time.

oleibman
oleibman

Merge pull request #2171 from oleibman/xlsxtest2

Move Reader Xlsx Tests from Reader to Reader/Xlsx Try 2

commit sha: 33ef03d1fae39a683e3e482f5872f4d8a9f4d793

push time in 4 days ago
pull request

oleibman pull request PHPOffice/PhpSpreadsheet

oleibman
oleibman

Move Reader Xlsx Tests from Reader to Reader/Xlsx Try 2

PR #2088 is having major merge problems. This is partly because it moves some tests from Reader to Reader/Xlsx. Making this move beforehand may help. Or it may make things worse, but they are already bad enough that I am contemplating redoing the PR. If I do that, having this done beforehand will make things easier.

This PR does nothing but move some tests. This will make it easier to test changes to Xlsx Reader without having to run each test individually, or without having to run tests for all the other readers at the same time.

This is:

- [ ] a bugfix
- [ ] a new feature
- [x] testing

Checklist:

Why this change is needed?

Activity icon
issue

oleibman issue PHPOffice/PhpSpreadsheet

oleibman
oleibman

Locale Files are Generated with Windows Line-endings

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?

Files should have Unix line endings.

What is the current behavior?

They have Windows line endings. This causes git to think they have all been changed; at least that's what it thinks on my Windows machine (which I have configured to use Unix line endings). It would be easy enough to change them all, but, since they appear to be generated, I'm not sure any such change would stick.

What are the steps to reproduce?

Please provide a Minimal, Complete, and Verifiable example of code that exhibits the issue without relying on an external Excel file or a web server:

Which versions of PhpSpreadsheet and PHP are affected?

This seems to have been caused by #2111.

Activity icon
issue

oleibman issue comment PHPOffice/PhpSpreadsheet

oleibman
oleibman

Xlsx Reader Better Namespace Handling Phase 1

There have been a number of issues concerning the handling of legitimate but unexpected namespace prefixes in Xlsx spreadsheets created by software other than Excel and PhpSpreadsheet/PhpExcel.I have studied them, but, till now, have not had a good idea on how to act on them. A recent comment https://github.com/PHPOffice/PhpSpreadsheet/issues/860#issuecomment-824926224 in issue #860 by @IMSoP has triggered an idea about how to proceed.

Gnumeric Reader was recently changed to handle namespaces better. Using that as a model, this PR begins the process of doing the same for Xlsx. Xlsx is much larger and more complicated than Gnumeric, hence the need to tackle it in multiple phases. I believe that this PR handles all of:

  • listWorkSheetNames
  • listWorkSheetInfo. Note that there was a bug in this function which would cause it to count only used columns rather than all columns. That bug is corrected.
  • active sheet
  • selected cell and top left cell
  • cell content (formulas, numbers, text)
  • hyperlinks
  • comments (partial - see below)

This PR does not address:

  • styles
  • images and charts
  • VBA and ribbons
  • many other items, I'm sure

The issue for non-standard namespacing till now has been the use of unexpected prefixes. While I was working on this change, @Lambik introduced issue #2067 PR #2068 which introduced a completely different problem - the use of unexpected URLs. That PR and the issue associated with it were quite well documented, including the supplying of a test file and tests for it. I asked if I could take a look to see if it could be integrated with my change, and the result seems to be yes, so those changes are also part of this PR.

While adding a comment to my test file, I discovered that Microsoft had added "threaded comments" as a new feature. I believe these are not yet supported by PhpSpreadsheet, and I am not going to add it, at least not now. I believe that, among other things, this will make identifying the author of a comment more difficult.

Although there are a number of Phpstan baseline changes as part of this PR, I did not attempt to resolve all Phpstan reports for Reader/Xlsx. Nor did I do anything to increase coverage. This change is already large and complex enough without those efforts.

I will add more detail as comments after I push this change.

This is:

- [x] a bugfix
- [ ] a new feature

Checklist:

Why this change is needed?

oleibman
oleibman

Good news! I have been able to create a new branch combining 2171 and the changes in this PR, and it passes all the old and new unit tests, including the new spreadsheets added this week. Need to do a bit more testing, but expect a new PR early next week.

Jun
17
6 days ago
Activity icon
issue

oleibman issue comment PHPOffice/PhpSpreadsheet

oleibman
oleibman

Xlsx Reader Better Namespace Handling Phase 1

There have been a number of issues concerning the handling of legitimate but unexpected namespace prefixes in Xlsx spreadsheets created by software other than Excel and PhpSpreadsheet/PhpExcel.I have studied them, but, till now, have not had a good idea on how to act on them. A recent comment https://github.com/PHPOffice/PhpSpreadsheet/issues/860#issuecomment-824926224 in issue #860 by @IMSoP has triggered an idea about how to proceed.

Gnumeric Reader was recently changed to handle namespaces better. Using that as a model, this PR begins the process of doing the same for Xlsx. Xlsx is much larger and more complicated than Gnumeric, hence the need to tackle it in multiple phases. I believe that this PR handles all of:

  • listWorkSheetNames
  • listWorkSheetInfo. Note that there was a bug in this function which would cause it to count only used columns rather than all columns. That bug is corrected.
  • active sheet
  • selected cell and top left cell
  • cell content (formulas, numbers, text)
  • hyperlinks
  • comments (partial - see below)

This PR does not address:

  • styles
  • images and charts
  • VBA and ribbons
  • many other items, I'm sure

The issue for non-standard namespacing till now has been the use of unexpected prefixes. While I was working on this change, @Lambik introduced issue #2067 PR #2068 which introduced a completely different problem - the use of unexpected URLs. That PR and the issue associated with it were quite well documented, including the supplying of a test file and tests for it. I asked if I could take a look to see if it could be integrated with my change, and the result seems to be yes, so those changes are also part of this PR.

While adding a comment to my test file, I discovered that Microsoft had added "threaded comments" as a new feature. I believe these are not yet supported by PhpSpreadsheet, and I am not going to add it, at least not now. I believe that, among other things, this will make identifying the author of a comment more difficult.

Although there are a number of Phpstan baseline changes as part of this PR, I did not attempt to resolve all Phpstan reports for Reader/Xlsx. Nor did I do anything to increase coverage. This change is already large and complex enough without those efforts.

I will add more detail as comments after I push this change.

This is:

- [x] a bugfix
- [ ] a new feature

Checklist:

Why this change is needed?

oleibman
oleibman

PR 2171 is ready to merge. If we haven't figured a way out of the mess in this PR by the start of next week, I will re-do it using 2171 as my starting point.

Activity icon
issue

oleibman issue comment PHPOffice/PhpSpreadsheet

oleibman
oleibman

Move Reader Xlsx Tests from Reader to Reader/Xlsx Try 2

PR #2088 is having major merge problems. This is partly because it moves some tests from Reader to Reader/Xlsx. Making this move beforehand may help. Or it may make things worse, but they are already bad enough that I am contemplating redoing the PR. If I do that, having this done beforehand will make things easier.

This PR does nothing but move some tests. This will make it easier to test changes to Xlsx Reader without having to run each test individually, or without having to run tests for all the other readers at the same time.

This is:

- [ ] a bugfix
- [ ] a new feature
- [x] testing

Checklist:

Why this change is needed?

oleibman
oleibman

Fixing the one minor Scrutinizer issue (which does not prevent the change from passing) and removing the Phpstan annotation for the same line are out of scope for this change. It would involve changing some doc blocks and/or code in src/Charts.

Activity icon
delete

oleibman in oleibman/PhpSpreadsheet delete branch xlsxtest

deleted time in 5 days ago
pull request

oleibman pull request PHPOffice/PhpSpreadsheet

oleibman
oleibman

Move Reader Xlsx Tests from Reader to Reader/Xlsx

This is:

- [ ] a bugfix
- [ ] a new feature
- [x] testing

Checklist:

Why this change is needed?

PR #2088 is having major merge problems. This is partly because it moves some tests from Reader to Reader/Xlsx. Making this move beforehand may help. Or it may make things worse, but they are already bad enough that I am contemplating redoing the PR. If I do that, having this done beforehand will make things easier.

This PR does nothing but move some tests. This will make it easier to test changes to Xlsx Reader without having to run each test individually, or without having to run tests for all the other readers at the same time.

Activity icon
issue

oleibman issue comment PHPOffice/PhpSpreadsheet

oleibman
oleibman

Move Reader Xlsx Tests from Reader to Reader/Xlsx

This is:

- [ ] a bugfix
- [ ] a new feature
- [x] testing

Checklist:

Why this change is needed?

PR #2088 is having major merge problems. This is partly because it moves some tests from Reader to Reader/Xlsx. Making this move beforehand may help. Or it may make things worse, but they are already bad enough that I am contemplating redoing the PR. If I do that, having this done beforehand will make things easier.

This PR does nothing but move some tests. This will make it easier to test changes to Xlsx Reader without having to run each test individually, or without having to run tests for all the other readers at the same time.

oleibman
oleibman
Activity icon
issue

oleibman issue comment PHPOffice/PhpSpreadsheet

oleibman
oleibman

Xlsx Reader Better Namespace Handling Phase 1

There have been a number of issues concerning the handling of legitimate but unexpected namespace prefixes in Xlsx spreadsheets created by software other than Excel and PhpSpreadsheet/PhpExcel.I have studied them, but, till now, have not had a good idea on how to act on them. A recent comment https://github.com/PHPOffice/PhpSpreadsheet/issues/860#issuecomment-824926224 in issue #860 by @IMSoP has triggered an idea about how to proceed.

Gnumeric Reader was recently changed to handle namespaces better. Using that as a model, this PR begins the process of doing the same for Xlsx. Xlsx is much larger and more complicated than Gnumeric, hence the need to tackle it in multiple phases. I believe that this PR handles all of:

  • listWorkSheetNames
  • listWorkSheetInfo. Note that there was a bug in this function which would cause it to count only used columns rather than all columns. That bug is corrected.
  • active sheet
  • selected cell and top left cell
  • cell content (formulas, numbers, text)
  • hyperlinks
  • comments (partial - see below)

This PR does not address:

  • styles
  • images and charts
  • VBA and ribbons
  • many other items, I'm sure

The issue for non-standard namespacing till now has been the use of unexpected prefixes. While I was working on this change, @Lambik introduced issue #2067 PR #2068 which introduced a completely different problem - the use of unexpected URLs. That PR and the issue associated with it were quite well documented, including the supplying of a test file and tests for it. I asked if I could take a look to see if it could be integrated with my change, and the result seems to be yes, so those changes are also part of this PR.

While adding a comment to my test file, I discovered that Microsoft had added "threaded comments" as a new feature. I believe these are not yet supported by PhpSpreadsheet, and I am not going to add it, at least not now. I believe that, among other things, this will make identifying the author of a comment more difficult.

Although there are a number of Phpstan baseline changes as part of this PR, I did not attempt to resolve all Phpstan reports for Reader/Xlsx. Nor did I do anything to increase coverage. This change is already large and complex enough without those efforts.

I will add more detail as comments after I push this change.

This is:

- [x] a bugfix
- [ ] a new feature

Checklist:

Why this change is needed?

oleibman
oleibman

Trying test moves again as PR #2171. This seems to be more successful, and, if that holds, that will give me a new base to start from if need be.

pull request

oleibman pull request PHPOffice/PhpSpreadsheet

oleibman
oleibman

Move Reader Xlsx Tests from Reader to Reader/Xlsx Try 2

PR #2088 is having major merge problems. This is partly because it moves some tests from Reader to Reader/Xlsx. Making this move beforehand may help. Or it may make things worse, but they are already bad enough that I am contemplating redoing the PR. If I do that, having this done beforehand will make things easier.

This PR does nothing but move some tests. This will make it easier to test changes to Xlsx Reader without having to run each test individually, or without having to run tests for all the other readers at the same time.

This is:

- [ ] a bugfix
- [ ] a new feature
- [x] testing

Checklist:

Why this change is needed?

Activity icon
created branch

oleibman in oleibman/PhpSpreadsheet create branch xlsxtest2

createdAt 5 days ago
push

oleibman push oleibman/PhpSpreadsheet

oleibman
oleibman

Fix #1933. Swapped chart axis options

oleibman
oleibman

Eliminate a big chunck of duplicated code for reading styles (#2021)

  • Eliminate a big chunk of duplicated code for reading styles
oleibman
oleibman

Issue 1967 conditional formatting data bar problems (#2012)

  • Only store additional formatting objects for DataBars
    • Ensure that Xlsx Reader/Writer can still read DataBar Conditional Formatting, while ignoring IconTypes that are triggering errors
  • Ensure that Xls Writer only writes CF Headers if there are non-DataBar CF Records that it needs to write
  • Ensure that Xlsx Reader only reads SheetView data to retrieve currently selected cells after it has read CF Records that can otherwise change the currently selected cell
  • Try to apply proper support for cell ranges in conditional formatting
oleibman
oleibman

Xls writer improve styles (#2014)

  • Extract 3 separate (duplicated) switch statements for mapping colours in conditional formatting rules into a single class
  • Replace switch statement with an array map for colour lookup
  • Eliminate duplicate colour map entries
  • Apply some stricter type checking
  • Extract Cell Data Validations
  • Extract Error Code mappings
oleibman
oleibman

MathTrig - Fix Phpstan Accomodations (#2020)

  • MathTrig - Fix Phpstan Accomodations

This should be the last of my mass changes to MathTrig. All he Phpstan violations found in baseline which are part of MathTrig are now fixed and removed from baseline. There were about 20 of these.

oleibman
oleibman

DateTimeExcel - Change Names of funcWhatever to evaluate (#2015)

  • DateTimeExcel - Change Names of funcWhatever to evaluate

Per discussions while MathTrig was being broken up, this would help standardize the code. This PR applies that standardization to the DateTimeExcel family of functions.

The deprecation messages in DateTime.php are changed to match the style used in PR #2005.

All Phpstan grandfathered errors (about 25) in DateTimeExcel are fixed and removed from baseline. A small number (about 5) of phpstan annotations in the source members in that directory are also fixed and eliminated.

oleibman
oleibman

BREAKING Worksheet::getCellByColumnAndRow() cannot return null anymore

Worksheet::getCellByColumnAndRow() used to optionnaly return null if passed a second argument. This second argument was removed entirely and the method always returns a Cell (possibly creating it if needed).

This make the API more predictable and easier to do static analysis with tools such as PHPStan.

If you relied on that second parameter, you should instead use the Worksheet::cellExistsByColumnAndRow() before calling getCellByColumnAndRow().

oleibman
oleibman

BREAKING Worksheet::getRowDimension() and Worksheet::getColumnDimension() cannot return null anymore

Both methods used to optionally return null if passed a second argument. This second argument was removed entirely and the method always returns a RowDimension or ColumnDimension respectively (possibly creating it if needed).

This make the API more predictable and easier to do static analysis with tools such as PHPStan.

If you relied on that second parameter, you should instead use the Worksheet::getRowDimensions() or Worksheet::getColumnDimensions() and check for existence yourself before calling the getters.

oleibman
oleibman

Some refactoring improvements to parsing Style information in the Xls Reader (#2025)

  • Some refactoring improvements to parsing Style information in the Xls Reader
oleibman
oleibman

Improve Range handling in the Calculation Engine for Row and Column ranges (#2028)

  • Improve Range handling in the Calculation Engine for Row and Column ranges
oleibman
oleibman

Completion of refactoring for Excel Lookup and Reference functions (#2030)

  • Completion of refactoring for Excel Lookup and Reference functions
  • Fix LookupRef tests checking for cell existence
  • Fix a couple of now invalid callable references in the Calculation Engine lookup table
oleibman
oleibman

Fix a couple of now invalid callable references in the Calculation Engine lookup table

oleibman
oleibman

Merge remote-tracking branch 'origin/master'

oleibman
oleibman

Initial implementation of the URLENCODE() web function (#2031)

  • Initial implementation of the URLENCODE() web function
oleibman
oleibman

Mpdf Caching

Mpdf caches font data in a temporary directory. When running the test suite, it uses different directories for samples vs. normal tests. One is sufficient. This will slightly reduce disk usage and overhead when running test suite.

oleibman
oleibman

Resolve problem where underscore placeholder in a number format masks (#2038)

  • Resolve problem where underscore placeholder in a number format mask was being replaced, but leaving the sizing character as part of the mask
oleibman
oleibman

Start work on refactoring the last of the Excel Statistical functions (#2033)

  • Refactoring the last of the Excel Statistical functions
oleibman
oleibman

Fix for Issue 2029 (Invalid Cell Coordinate A-1) (#2032)

  • Fix for Issue 2029 (Invalid Cell Coordinate A-1)

Fix for #2021. When Html Reader encounters an embedded table, it tries to shift it up a row. It obviously should not attempt to shift it above row 1. @danmodini reported the problem, and suggests the correct solution. This PR implements that and adds a test case.

Performing some additional testing, I found that Html Reader cannot handle inline column width or row height set in points rather than pixels (and HTML writer with useInlineCss generates these values in points). It also doesn't handle border style when the border width (which it ignores) is omitted. Fixed and added tests.

oleibman
oleibman

#984 add support notContainsText for conditional styles in xlsx

commit sha: 16d0075640af3ff595e458870b4f39f22dc682f1

push time in 5 days ago