Apache OpenOffice (AOO) Bugzilla – Issue 31612
Column limitation in SpreadSheet
Last modified: 2013-08-07 15:15:24 UTC
Please increase the column limit in calc from 256. I find most of my problems with DataPilot failing to generate, involve running out of columns. The lack of error message detail when that happens confounds. If there must be a maximum, I don't know what it should be. Just today I could use double (512), but more would be welcome. I've searched the website and found a doc talking about increasing the 32000 row limit, but nothing on the column limit. Sorry if this is a dupe.
Hi Bettina, one for your department. Frank
So, any news here? Is it still on the To-Do list? (didn´t find it there) Are there any plans for OO.o 2.2 ? I'like to ask, weather ODF/ISO 26300 proposes this limit, or is it a tecnical limitation? - I just heard rumors, that Excel 2007 will break it and reach behind. Other products already support more than 256 cols (i.e. KSpreak which reaches to 32k [and has of course support for csv files]) As I currently work with a 300x300 matrix, this limit is not handful in my special case and I had to go for an other software.
No plans for 2.x, also not an ODF file format limitation, "just" technical challenges. See also http://wiki.services.openoffice.org/wiki/Calc/hacks/number_of_rows However, implementation of slightly more columns (say 512 or so) may be easier to cleanup, mostly work to be done in preventing export to binary file formats, than going up to 16k columns or increasing rows to 1M.
But we should introduce this, as Excel 2007 will handle bigger Spreadsheets than we do right now. IMHO, we won't gain nothing just waiting for the future to solve the troubles.Therefore I would be glad to see things changing. Let's handle the limits per document type, but not as a feature of the application.
I often work with 640 x 480 arrays, and it would be especially handy to drop them into a spreadsheet to test various things on them. Right now, I have to break them into pieces to drop them in - then recombine afterwards. Its a real pain. More columns would be incredibly helpful.
Seems to be dup of http://www.openoffice.org/issues/show_bug.cgi?id=30215 Please transfer votes to 30215. *** This issue has been marked as a duplicate of 30215 ***
and closing.
This is _not_ a duplicate of issue 30215, which is about the row limit whereas this issue here is about the column limit. The issues are kept separate for technical reasons because different problems have to be solved. It would probably be easier to quadruple the number of columns first than to increase the number of rows to a million or so.
As with rows, the amount of data that scientists are getting is surpassing the limitations of OOo spreadsheets. I routinily get data sets that use 300 or 400 columns to work with now. Yea, this is a limit in Excell, at least until 2007 came out. I just voted for this issue. I would suggest that the limit be higher than what is available in Office 2007 or even plan for an easy path to increase the number of columns.
Excel 2007 has 16384 columns.
Hi Niklas, these RFEs are in your ownership.
Please consider this.
This along with increasing the row limit should be worked on. I want to move to using Open Office but these limits prevent it.
Plan is to have 1024 columns in 3.0.
Niklas, thanks a lot for bringing this up. Is there a technical reason to set limit so low? Regards, KP.
We're mostly keeping the fixed-size structure, and don't want to run into performance problems.
For my personal way of using it, 1024 columns are enough. But it might not be enough to import Excel 2007 spreadsheets. In Excel 2007 you can use 1.048.576 rows and 16.384 columns.
I guess you have considered introducing in "calc.xcu" an option that will set this limit? Those with specific need and fast CPUs can have 16K columns, everybody else will get default of 1024.
If OpenOffice is going to compete, the features have to be as good or better than MS's product. I don't see any issue with 1024 columns today but it could be an issue tomorrow which would limit me. To me, if the number of columns can be dynamic, only created as necessary, the performance won't be that big of a hit. Also if it is dynamic, (Only the number needed), there could be a performance improvement. If you only need 10 columns, then only 10 are saved. Maybe a default 2^6 columns with the ability to create upto 2^15 columns if required. This is one bit better than MS. :) I prefer the dynamic way of creating columns (and rows) over a static need. If there is going to be modifications for the number of columns, then why impose another small limit. I hate to say it but MS has set the bar and OOo has to at least make that level to remain competitive.
The change to 1024 columns is on CWS "calccolumns". The "used area" logic for automatic print ranges, HTML/RTF export, and the Ctrl-End keyboard shortcut has changed: If there are at least 30 equal-formatted columns somewhere behind the last column that has cell contents, the attributes in these and the following columns are ignored in determining the used area.
back to QA for verification
verified in cws_calccolumns
So the 1024 columns are now in. Anyway, that's not enough - it's just a temporary enhanced limit. How shall we proceed to ask for at least 16k rows ? - reopen this bug - file a new issue I propose to reuse this issue. Please consider reopening it, as it has only been fulfilled partly.
bettlerthomas, I sort of agree with you but in real terms of the OP's comment, the issue has been fixed. The request was for 1024 or more, not to compete with MS Office 2007. I suppose that an issue should be created to increase the column count to equal or surpass that of MS Office 2007 to remain competitive in todays market. The new issue should reference this issue and the number should also be posted into this issue. My issue is rows, not columns at this time. http://www.openoffice.org/issues/show_bug.cgi?id=30215 But I have said it before, OpenOffice.org has to meet the MS Office latest specifications or be better. This is a marketing issue that MS can use against OOo. They may even use this in their push for OOXML as an ISO standard as an indication that OOXML can meet higher standards.
Well, to insist on the initial request would mean to just ignore all those propositions added by voters and watchers! Seriously, if I had filed a such bug 4 years ago it would had been closed as a DUP, wouldn't it? So by now I should reintroduce a new bug - simply with the same content, except for the initial request for 16k? - Honestly, I can't follow your logic. Therefore I propose to reopen THIS very issue, because it's just the same one...
OK, ok, just to give you the choice.... reopen this one ... or treat its successor issue 86049
As there are 1.024 columns in m28 possible, I will close this issue.