-
Notifications
You must be signed in to change notification settings - Fork 48
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
OdfTableCellRange() is unusably slow for spreadsheets with whole-sheet formatting #285
Comments
@Nnnes A pull request is very much welcome. Thanks in advance! |
I'm making progress. Laying out some of my thought process here, mostly for me to use as a reference for myself. According to the spec, Similarly, As far as I can tell, all of this means I can handle repeated rows all at once in There are a few other places with patterns like |
There are usually existing test documents available, I took a quick look and found three promising ones: |
Or https://github.com/tdf/odftoolkit/blob/master/odfdom/src/test/resources/test-input/_tableRepeated.ods Godspeed! |
This issue is very closely related to #64. A fix for that issue would most likely also fix this one. The root problem is how LibreOffice handles setting formatting for an entire spreadsheet and how this library interacts with such spreadsheets.
Steps to reproduce:
This creates a
content.xml
with the following inner content:getColumnCount()
andgetRowCount()
then respectively return 16384 and 1048576. This is a problem for functions likegetCellRangeByName(...)
andgetCellRangeByPosition(...)
that eventually callgetCellCoverInfos()
, which will then attempt to iterate over every cell in the table multiple times.It might be possible to fix this by patching
getOwnerCellByPosition()
without having to deal with the spreadsheet size issue. I'll try to do so and submit a pull request if I can figure out what a covered cell is.The text was updated successfully, but these errors were encountered: