Context: https://github.com/SheetJS/sheetjs/issues/2011 The reported issue involves: - file parsed by the XSSF library - a cell was programmatically added using createRow/createCell API calls - updated file was written The user provided a sample file, attached to the GitHub comment https://github.com/SheetJS/sheetjs/issues/2011#issuecomment-646472892 Inspecting the file, POI appears to have added cells E8/F8 but did not update the worksheet range to include the new cells. Is this known / expected behavior?
Bug #65562 reports the same for SXSSF
Dominik - I think the XSSF and SXSSF issues should be treated differently. XSSFSheet has this code. protected void write(OutputStream out) ... // finally, if we had at least one cell we can populate the optional dimension-field if(minCell != Integer.MAX_VALUE) { String ref = new CellRangeAddress(getFirstRowNum(), getLastRowNum(), minCell, maxCell).formatAsString(); if(worksheet.isSetDimension()) { worksheet.getDimension().setRef(ref); } else { worksheet.addNewDimension().setRef(ref); } } ``` While in SXSSF, the issue is that the order of the XML is messed up. Microsoft chose to put the dimension in the sheet XML before the row data - so the SXSSF code doesn't yet know the dimensions when it writes the dimension data. It might be possible to get SXSSF to work by taking advantage of temp files and creating the sheet XML based on row data that is in temp files (and we then know how many rows there are. In XSSF, this is so much easier because the whole sheet is in memory.
The code is the linked sheetJs issue is pretty out of date. I wrote a new test - r1899091 and it passes ok. I added a new getDimension() method to XSSFSheet to help test.