Apache OpenOffice (AOO) Bugzilla – Issue 86049
Column limitation in SpreadSheet (enhance to > 16k)
Last modified: 2022-08-24 21:25:24 UTC
Please increase the column limit to match at least the limit of MS Excel (which is currently at 16k). btw: KSpread supports 32k. The objective must be the compatibility between all those office solutions. Another important question: Why is the limit statically implemented [hardcoded] on application level? Wouldn't it be smarter to define it per spreadsheet [or even omit an explicit limit] say have a dynamic solution? This is the logical sequence of Bug 31612, [which had been in pipe already 4 years]
this issue is dup for issue 19440 please transfer your votes
Reassign to owner requirements
Nope, read correctly, it isn't dup. The other issue is about number of rows and sheets but not about nr of cols!
This issue is related to the increase in the number of rows to compete/surpass other applications. http://www.openoffice.org/issues/show_bug.cgi?id=30215
So what was then about bug 31612? Honestly, I don't get your logic...
*** Issue 86049 has been confirmed by votes. ***
From nsaa on Issue 30215 (further thoughts on row limits) To manually hack an increase to the number of columns: http://wiki.services.openoffice.org/wiki/Calc/hacks/number_of_rows Change MAXCOLCOUNT_DEFINE in sc/inc/address.hxx to a multiple of 16.
Of course this workaround exists. But I'd like to send these the large docs to anyone using OO.o. So this isn't the right way.
Now that the row limit <http://www.openoffice.org/issues/show_bug.cgi?id=30215> is being targeted for 3.0, maybe this should be as well to ensure compatibility for Microsoft's planned support for ODF in 2007.
reassigning features and enhancements to user requirements@openoffice.org which will be the default owner for those tasks (was introduced some time ago)
I agree that this is an issue that may not happen often but when it does it is a show-stopper. Even more important is the row count limitation.
*** Issue 126506 has been marked as a duplicate of this issue. ***
For anyone interested, LibreOffice 7.4 was released today with support for 16384 columns in Calc: https://llunak.blogspot.com/2022/03/enabling-calc-support-for-16384-columns.html Technical details blogpost from 2017: https://niocs.github.io/LOBook/misc/16kcols.html
Other alternatives are gnumneric with 16,384 columns (http://www.gnumeric.org/) as LO. And Caligra Sheets with 32,767 Columns (https://calligra.org/) as max value. Both have this feature for years. So other Open Source Spreadsheet apps are much more powerfull in this respect, or have the feature for longer time, but they do not feel the need to advertise their product in other projects bug tracker like spammers do. I hope you understand that bug trackers are a development tool and not a evaluation platform for the best tooling. Use other channels if you feel the need for your dvertisements. Thank you! All the best Peter
He may not be aware that LO license does not allow us to take code from them... But maybe reading the technical blogpost can give us some hints?
Ohh no. I did not consider that. It seems I am to frustrated on some statements, to even consider this. :( This is of course wrong and not what I want. I am sorry. Please take my apologies. yes we should look into this too.
Okay, in order to add morte columens we need to change the way lots of fields are processed. Currently SC moves through all fields in order for update. This is very slow, anmd becomes slower if there are more fields. LO did move to a vector array, enhanced the formula of processing and they are now confident to increase the field amount. I am not sure this is the right track. It depends on the way the table is build and I am not sure the container type is the best decision that has been taken. Especially if you think that a table might not be uniform. I have an Idea how to solve this issue, but I need to experiment a bit. Also more research is needed.