Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Column limitation in SpreadSheet (enhance to > 16k) | ||
---|---|---|---|
Product: | Calc | Reporter: | bettlerthomas <bettlertho> |
Component: | ui | Assignee: | AOO issues mailing list <issues> |
Status: | CONFIRMED --- | QA Contact: | |
Severity: | Trivial | ||
Priority: | P3 | CC: | agnostos88, gbpacheco, issues, kami911, kyoshida, mseidel, ooo, openoffice, pagalmes.lists, petko |
Version: | OOo 2.3.1 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Latest Confirmation in: | --- |
Developer Difficulty: | --- | ||
Issue Depends on: | |||
Issue Blocks: | 15522 |
Description
bettlerthomas
2008-02-12 21:14:53 UTC
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. |