Currently Calc is limited to 1024 columns. This limitation causes problems for certain use cases: * import of .xlsx files with more than 1024 columns (Excel 2007 allows 16384 columns) * generally calculations with big matrices/tables Please enable Calc to handle up to 16384 columns.
See discussion on bug 43911 for more information. The tl;dr is: "increasing the column limit will increase the the memory needed for every sheet extremelly" unless we "change the column container to a dynamic container," a change that "might take much more time" than a month.
I had a colleague of mine send her data twice, in different formats, assuming a file corruption. This was because LibreOffice Calc does not even warn when it encounters a file with more columns than it can deal with. This is a bit embarassing, not? For your internal priorisation, please be aware that today, with many research lab are equipped with machines to perform high throughput analyses, files with >1500 columns (which typically host attributes in statistics) are no longer exceptional. Excel once was sucking badly with 256 columns, but they got that one fixed for a reason. Together with this functionality of thousands of columns there will be new interfaces developing alongside for the filtering of such. Time will bring it. Just now, please fix this behaviour. I offer 100 Euros from my very private pocket for this feature. The missing notice of losing data I tend to see as a bug. Concerning the "dynamic container" comment below I suggest to think about sparse formats. There is tons of sparse data out there in scientific data and to have a regular desktop tool prepared to handle that efficiently would be exciting.
Kohei/Markus/Eike: I suppose there must be some reasons we still got this limit but could you tell/remind them? I think I must have read about this on IRC or dev mailing list but don't remember.
(In reply to comment #3) > Kohei/Markus/Eike: I suppose there must be some reasons we still got this > limit but could you tell/remind them? I think I must have read about this on > IRC or dev mailing list but don't remember. Markus' comments on bug 43911 provide more details: --- Markus Mohrhard 2012-01-05 14:21:03 UTC No. We won't increase the column limit soon. First we would need to rework all internal cell datastructures like I did for sheets in 3.5. We still use fixed size containers for columns. That means that increasing the column limit will increase the the memory needed for every sheet extremelly. The column limit of 1024 is a design decision by us. If you are really in need for LibO with a bigger column limit you can easily build one yourself and I tell you the line you need to change to increase the limit. --- --- Markus Mohrhard 2012-01-05 15:30:04 UTC > So, our hopes is to convince developers to increase the "Max Column" limit, or > that they switch to a dynamic size column container approach in order to use > necessary memory. This is not an easy switch. This is more like half a heart transplant and therefore is nothing that will be done just from today to tomorrow. I needed around one month for the change for the sheet change and I think that changing the column container might take much more time. > Is it the final decision that the distributed official LibO version will have a > "Max Column" limit of 1024 in the near future releases? And people like me will > have to modify the "Max Column" limit and recompile/recreate a special LibO > version for our needs? It is not a final decision but I doubt that we will increase the column limit if we did not change the column container to a dynamic container. In my dev builds a empty sheet already needs around 150 KB. For the change we need someone who has enough time to work on it. Feel free to step in here and help to improve the situation. You'll get as much help as possible by us and we will assist as much as we can. ---
@Steffen Moeller @Gerry Consider http://www.r-project.org/
@Phil: Thanks for the nice suggestion. However, spreadsheets, databases and statistical software like R, Stata, ... have very different goals. Having said this, there is a clear need and usage for spreadsheets handling more than 1024 columns. People use it and I use it, too. Given the dynamic idea of cells in spreadsheets (dependencies on other cells, formulas in cells, fill-out features), they are very good at data processing and data generation. These are features which are not as good to handle in statistical software. Data analyis is, of course. Independently from this, when receiving .xlsx files with more than 1024 columns, LibreOffice cannot be used. Gnumeric can serve as an alternative then.
The question is then how to kick start/fundraise money to make the column container to a dynamic container? What will be needed in funds? The 1024 column limit is the simplest way to shoot down any suggestion for using Libreoffice in any organization. It MUST be fixed, and all I can offer is €.
The last column showing for me is column "AMJ". I don't see numbers so not sure what that is, guess you can figure that out by creating a crazy formula with the number of alphabet letters. Maybe the result is 1024 - not sure. If that is not sufficient for your usage and would like to see this bug fixed and want to put in cash for that specific enhancement please create an account on http://freedomsponsors.org and setup a bounty. I'm aware of several LO bugs that got fixed that way.
I recently hit that bug, i.e. RFE and came here... I usually avoid using Calc for large datasets (CSV/Perl/gnuplot), but sometimes I use/make tools that output in columns instead of rows (e.g. few spectra in 4K columns). Since all machines around here have at least 16GB RAM, I don't think increased memory footprint is a problem for me. I also use Gentoo, so recompiling LibreOffice is the norm. Has anyone identified what needs to be patched to increase max cols? --- Markus Mohrhard 2012-01-05 14:21:03 UTC If you are really in need for LibO with a bigger column limit you can easily build one yourself and I tell you the line you need to change to increase the limit. --- I will try if I have some better pointer at where to look in the source (file/line, etc.) since I don't want to dive headfirst in the huge codebase. Once a patch is available, distros (Gentoo at least) can easily choose to decide whether it cares for power (ab)users or not.
How likely will it be that the limitation of Calc to 1024 columns will be increased in the next LO release(s), 4.3 or 4.4? I have seen that lots of performance-related parts of Calc have been rewritten. Are these changes also related to this enhancement request?
(In reply to comment #10) > How likely will it be that the limitation of Calc to 1024 columns will be > increased in the next LO release(s), 4.3 or 4.4? I have seen that lots of > performance-related parts of Calc have been rewritten. Are these changes > also related to this enhancement request? No. Unless someone steps up and starts working on it the chances are not too big that it will be implemented for the next releases. This bug requires another not so small refactoring of calc core and therefore requires someone to invest the time in working on it. If you want to see this enhancement request implemented the best way forward is to start working on it. You will get any help you need from the community but right now I think there is no Calc developer who has the time to implement it.
*** Bug 78255 has been marked as a duplicate of this bug. ***
I suggest an importance increase. I have also suggest adding a new tag - msoffice or compatibility. The goal of this tags is to group all bugs that, in my view, critically affect Libreoffice - compatibility with MS Office files. I run a company that has, from day 1, used Libreoffice (and Openoffice before) exclusively. But as much as we care for this project and what it means, it is vital that the community understands that a lack of compatibility with what the majority of users (and companies) use it a hindrance in the adoption of Libreoffice. And a headache to those who use it but have to interact with people who use MS Office.
@Miguel: Please see the comments to Kohei's blog: http://kohei.us/2014/09/09/slides-for-my-talk-at-libreoffice-conference-in-bern/ I quote Kohei: "The only thing that’s holding us back is nothing technical i.e. we have a pretty good idea how we want to get it done. It’s just a matter of getting the effort funded." I also wished to use >1024 columns in Calc (even 2048 would already help), but I understand the problem of funding this improvement, as it requires some deeper changes in Calc.
@Gerry - something like https://www.bountysource.com/ ? Perhaps it would be a good idea to add a link there then. I remember a (still open) Evolution Mail bug where, within the comments alone, people were pledging to add the ability to change email fonts used. If the technical effort has been calculated, then the hard part is done and a funding process can be added?
@Miguel: I think for this, you need to ask the Calc developers directly: Kohei, Eike or Markus, for example. I think they are CCed in this bug.
Adding self to CC if not already on
Just hit the limit myself and I'd like to see this implemented soon. How can I contribute to bounties, fundraising, etc.? Is there anything set up yet?
Throwing money at it alone won't help. Dedicated developer resources to come up with a viable concept to change column allocation to dynamic containers that at the same time would not make sheet operations suffer from performance bottlenecks AND IMPLEMENT it would help.
I used freedomsponsors.org for a small bugfix in Thunderbird recently and had a very quick result, I had added a realistic reward. This feature sounds like a biggie! Another I have seen is www.bountysource.com. I haven't got clue if doing these is considered good, bad, or annoying but it does target what you want.
This problem becomes a showstopper for implementation simply because people get xlsx sheets by mail with more than 1024 rows.
If 16384 columns in Calc require quite some refactoring, would this be also the case if the number of columns would be increased to 2048? I think 2048 columns would already solve many problems, but - of course - in the long run >= 16384 are required for Excel compatability. Thanks!
in this case yes, I exported a database, about 2kx2k in csv file to be eaten by a python program and I can open it with excel but I cannot with libreoffice, and this is bad.. :-) :-) please enable calc to handle up to 16364 columns..
Hi devs, If no one is yet working on this, I would like to work on this. My motivation is to learn the Calc code-base in depth from the experts. Right now I will be able to spend one full day per week, but may increase depending on my work priorities. I am aware that this change will take quite some time at this rate, but I still want to work on it.
(In reply to Dennis Francis (ldcs.co.in) from comment #24) > If no one is yet working on this, I would like to work on this. My > motivation is to learn the Calc code-base in depth from the experts. Hi Dennis, It's great to hear that you're going to join our merry band of LibreOffice developers! Please start by building LibreOffice from source and completing your first Easy Hack: https://wiki.documentfoundation.org/Development/Easy_Hacks Good luck! --R
(In reply to Dennis Francis (ldcs.co.in) from comment #24) > Hi devs, > > If no one is yet working on this, I would like to work on this. My > motivation is to learn the Calc code-base in depth from the experts. Right > now I will be able to spend one full day per week, but may increase > depending on my work priorities. > I am aware that this change will take quite some time at this rate, but I > still want to work on it. Hey, great to see you looking into that. So the approach is to first understand the problem with increasing the number of columns in the current design. For that you should read a bit in the table*.[ch]xx files and check where we use the maximum column number. ONe of the biggest problems is replacing the static array of the number of columns with something dynamic. Finding a good data structure for that will be crucial for finding a design that does not suck performance wise. If you need more information feel free to ask here or on the dev IRC channel. Kohei (kohei), Eike (erack) and I (moggi) -- (IRC nicks) -- can answer your questions if you need some input.
From table.hxx, and column.[hc]xx, it looks like each column is set as a fixed sized mdds mtv of MAXROWCOUNT. http://opengrok.libreoffice.org/xref/core/sc/source/core/data/column.cxx#83 hence every single column in the table costs us memory space proportional to MAXROWCOUNT irrespective of the number of non empty data cells in that column. Can't we set the initial number of elements of mtv's like maCells, maBroadcasters etc.. to a smaller value say INITROWCOUNT=100 in the ScColumn constructor and call mtv resize() only when we get a request to set a new data at a logical location (say 120) which is beyond the current capacity of the mtv (100) ? If calling mtv resize(old_size + additional_space_needed) for every new data addition is suboptimal, can we do resize(old_size + k*additional_space_needed) where k is some heuristic measure of "expected growth" in space for that column from the saved history of previous calls to resize() ?
(In reply to Dennis Francis (ldcs.co.in) from comment #27) > From table.hxx, and column.[hc]xx, it looks like each column is set as a > fixed sized mdds mtv of MAXROWCOUNT. > > http://opengrok.libreoffice.org/xref/core/sc/source/core/data/column.cxx#83 > > hence every single column in the table costs us memory space proportional to > MAXROWCOUNT irrespective of the number of non empty data cells in that > column. > > Can't we set the initial number of elements of mtv's like maCells, > maBroadcasters etc.. to a smaller value say INITROWCOUNT=100 in the ScColumn > constructor and call mtv resize() only when we get a request to set a new > data at a logical location (say 120) which is beyond the current capacity of > the mtv (100) ? > > If calling mtv resize(old_size + additional_space_needed) for every new data > addition is suboptimal, can we do resize(old_size + > k*additional_space_needed) where k is some heuristic measure of "expected > growth" in space for that column from the saved history of previous calls to > resize() ? mdds is not the problem as mdds internally does not more or less what you mentioned. Actually increasing the row limit is not a problem. The problem is all the places where we iterate through each column.
(In reply to Markus Mohrhard (retired) from comment #28) > The problem is all the places where we iterate through each column. Start from something. If it has to be a §for§ loop, then make it a §for§ loop. Improve when you get better ideas. Something as slow as §for§ is better than nothing at all. Someone like you should know it.
(In reply to Jouni Järvinen from comment #29) > Start from something. If it has to be a §for§ loop, then make it a §for§ > loop. Improve when you get better ideas. Something as slow as §for§ is > better than nothing at all. Someone like you should know it. The developer team has a clear understanding of the problems and potential solutions for the 1024 columns limit. So, I don't understand your point. The problem is that the solution entails a refactoring of (old, pre-LibreOffice) code. Lots of work. @Dennis Francis: Did you have time to look into the code related to the refactoring towards >1024 columns?
excel files import have >1700 columns
We know. And please don't mess around with the Version field.
I would love to work on this Bug too.
Hi All Me and my colleagues(Arul, Yogesh, Kumar and Sahas) are working on this bug as per the discussion we had with LO devs at http://nabble.documentfoundation.org/tdf-50916-Calc-Dynamic-column-container-td4162663.html The first of the many incremental patches to come is at https://gerrit.libreoffice.org/21620 -- Thanks. www.ldcs.co.in team@ldcs.co.in
Dennis Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f14d271d31e75de09821cf1766c7ab2a9c6e0461 Patch#1 : Dynamic column container in the pursuit of tdf#50916 It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dennis Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bc20c6d0f397c0c1aef6ef7d6f750c2f81af8db6 Refactor ScMarkData for tdf#50916 It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dennis Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=187669de1096ebbf4347ec1126eb6b693f6c5a96 tdf#50916 : Unit tests for the refactored ScMarkData... It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Submitted a patch for refactoring ScAttrArray at https://gerrit.libreoffice.org/27828
Hi all, After having reached the 1024 column limit myself, I am glad to see that a patch has been released. I use LibreOffice for business across many devices on both Linux and Windows systems. Is this patch implemented in the Windows 5.2 release or Linux only? Thanks for all the hard work!
(In reply to Nasi Chassoulas from comment #39) > Hi all, > > After having reached the 1024 column limit myself, I am glad to see that a > patch has been released. I use LibreOffice for business across many devices > on both Linux and Windows systems. Is this patch implemented in the Windows > 5.2 release or Linux only? We have not yet increased the column count from 1024. There is still a lot of work to do before we can increase that and there are many more patches to come in yet. We will keep this page updated on the progress. Thanks.
Dennis Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=06d3294502413a231e5c5265609862c7f67a2f2b Refactor ScAttrArray for tdf#50916 It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dennis Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ad2bc869bfe2d34bde7d42e10593db1c5ffccc2a tdf#50916 : Refactor table1.cxx wherever there is column access It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5e223be2102a171c857be8db1327f23faea0ef78 tdf#50916 Use aCol.size() instead of MAXCOL to increase max number of column It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4f6d6d905ffe4e9962ea858d415273df4f5829fd tdf#50916 Make sure that we don't access aCol out of range It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e15fd1371567fd4b78dab37d843562ff676c52b8 tdf#50916 Allow ScTable work on dynamic ScColContainer It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hello All I have compiled a writeup at https://niocs.github.io/LOBook/misc/16kcols.html to help new contributors to get started on working with this feature addition project. I will try to keep it updated as more patches are added. Thanks, Dennis
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b78c6d8efd9531243e62a388bffc3f071d9a56eb tdf#50916 Introduce new column validation function It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0e0fef10002b46965edad02b3f460a502d9f6595 tdf#50916 Allow proper updating, deleting and inserting tabs It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a1b1ed766d1110acf843b807d554f9375963234c tdf#50916 Allow dynamically increase number of columns according to needs It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e1e2defb2cd9b572747b964e5ec97d289029af8c tdf#50916 Simplify and refactor source code It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thank you very much for all the commits with regard to this enhancement request for Calc to handle more than 1024 columns. Will this feature be ready for the upcoming LibreOffice 5.4 release?
Hi Gerry. Unfortunately this feature (Allow more than 1024 columns in calc) will not be ready in 5.4.0 release.
Why ? If it's ready, you could add this feature in the 5.4 release.
Dennis Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a680f6988482f13489d6c802b6078d43564ae934 tdf#50916 : More refactoring in table1.cxx It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dennis Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=637f7b50e4e8fbb56b4c552e28058bbdfcf85d5a tdf#50916 : Refactor table1.cxx ScTable::GetNext*() methods It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Polite ping: is this bug fixed? if so, could you please close it as RESOLVED FIXED
It's not fixed, it's ongoing longer term work.
When this limit will be changed ? The issue is old (2012) and a patch is apparently here. Is it fix ? And if it's not why ? The patch is not complete ?
It is not fixed and it is not just a matter of some patch(es) being applied. Bumping this bug doesn't help anyone. You will read in some future release notes that 16k columns are supported when it is ready.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=45d5c18a9a643590b18e7cc48ab80076a31b75b3 tdf#50916 Refactor of the table7.cxx to allow dynamic column size It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi Bartosz, Dennis and Eike, with regard to ">1024 columns in Calc" I would like to ask you whether there is a chance that it will be ready for LibreOffice 6.1? Or whether there is still much more refactoring to be done? Thanks.
As long as this hasn't its status set to RESOLVED FIXED it isn't ready.
*** Bug 117494 has been marked as a duplicate of this bug. ***
*** Bug 118788 has been marked as a duplicate of this bug. ***
The problem returned and what do we do with it?
Noel also did a chunk of work on this - his commits (and fixes for various regressions) contain the 'dyncolcontainer' string.
*** Bug 119755 has been marked as a duplicate of this bug. ***
*** Bug 120914 has been marked as a duplicate of this bug. ***
Some useful information for developers which would like to continue working on this topic: The very basic classes involved are : ScDocument - which represents the document, ScTable - which represents a sheet, ScColumn - represents a single column. With below patches Dennis made a dynamic column container class called ScColContainer which represents the dynamic column container and this container gets instantiated in ScTable class as member aCol. Previously ScTable was having a static array of ScColumn's of size 1024. The list of Dennis patches which created dynamic column container and further code refactoring is below in chronological order : 1. https://gerrit.libreoffice.org/21620 [ This is where the dynamic container got created but still uses fixed number of columns to initialize the datastructure. We can change this only after making changes to all places where columns are accessed like aCol[nColIdx].someMethod() or similar because in all these places it is assumed that there are always MAXCOL columns are available] 2. https://gerrit.libreoffice.org/22163 [ Refactors ScMarkData (to hold user selection) and supporting classes to work efficiently with dynamic column container ] 3. https://gerrit.libreoffice.org/27828 [ Addresses some issues with ScAttrArray class(stores the attributes like background color, number format etc..) when dynamic column container is used. This is discussed in the above mentioned mailing list thread ] 4. https://gerrit.libreoffice.org/31125 [ Changes all places in table1.cxx where there is naive column access to work correctly with the new dynamic column container We next need to complete the refactoring of table1.cxx and other files where column access is made which assumes there are MAXCOL columns.]
At this point, most of the technical groundwork for this has been laid. See discussion here: https://gerrit.libreoffice.org/#/c/44802/ Now some tricky bureaucratic/technical hard work needs to happen around modifying the ODF file format to handle the extra columns and figuring out backwards/forwards compatibility issues
Created attachment 148535 [details] 20190115 error when open file
Is making a truly dynamic sheet even needed? Excel only allows a static number of columns and a static number of rows and it seems like a massive undertaking for such a seemingly niche application. Excel 2016/ M365 supports 1,048,576 rows or 16,384 columns as that static limit. Looking over the comments I can see that there may have already been an effort to produce a dynamically sized sheet. Has anyone done testing to see if the dynamic sheet comes with any performance penalty? If so it might be wise to use a large static value under most cases and allow the dynamic sizing as a niche option with an opt-in configuration. That would prevent constant allocation/frees around when adding and removing rows and cols if that does turn out to be a performance problem. I would look into the performance consequences myself, but I am brand-new to this project and wholly unfamiliar with the code base and procedures for performance monitoring of this project. If anyone could point me to some guiding documentations I would be willing to make an effort at fulfilling my own request.
Hi Emily; the dynamic sizing is mostly about compatibility while not blowing up our memory requirements. When it comes to performance - a dynamic size seems rather unlikely to be significant compared with many more significant algorithmic complexity issues =) but of course, if you can measure something there its always interesting to improve. There are a number of known performance issues that we should fix first I think - such as the O(log(log(N))) interpolation search we should re-introduce to mdds etc.
The fix is it already in progress?
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/7282014e362a1529a36c88eb308df8ed359c2cfa%5E%21 tdf#50916 Makes numbers of columns dynamic. It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/6db38ca2cc9cafb353dd2ca2f4a617d5fa3eb51d%5E%21 ofz#14093 bunch of new ofz detected crashes related to tdf#50916 It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/3c364f5d574515a257ba0bb84e199275fbea944f%5E%21 Related: tdf#50916 create valid empty ScHorizontalCellIterator when... It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/e056abae09796f2b3806e94e62cae7f0d262d4d5%5E%21 tdf#50916: XLS: make sure to set default widths to all columns It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 151048 [details] A spreadsheet with 10 000 empty sheets FYI: LO with attached file takes 4 170 000 KB RAM with Version: 6.2.3.2 (x64) Build ID: aecc05fe267cc68dde00352a451aa867b3b546ac CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL Today's master (dbgutil buiild) takes 1 600 000 KB.
Hi, there were a number of commits in the past months addressing this bug/enhancement. How likely is it that Calc gets dynamic numbers of columns for LO 6.3? Thanks!
(In reply to Gerry from comment #80) Since commit mentioned in comment 75, the number of columns in Calc *is* dynamic - and that's version 6.3. But that is inly the change of internal allocation mechanics; the maximum number of columns that can be dynamically allocated still remains 1024, so from end user's PoV, nothing changed. Now what's remaining is iiuc (1) change one constant from 1k to 16k (a simple part), and (2) decide how to keep compatible with older implementations file-format-wise (including whole-row/whole-column references).
See here for the concerns that still need to be addressed before we can raise the limit from 1024 columsn to something bigger: https://lists.freedesktop.org/archives/libreoffice/2019-January/081909.html
This really is an important missing feature. If you work with large data sets, especially in ML/DL, 1024 is a serious limitation. Seeing as the first request was filed in 2012, I find it surprising that a fix is still pending. Do consider a change of file format if necessary for backward compatibility but please include this feature in 9.3.
I would really like to underline once again how important it is to implement this issue. I often work with tables that have more than 1024 columns and can't use Calc in these cases.
Created attachment 152897 [details] Spreadsheet with 3201 columns for testing with previous LO versions I have tested following document with 3201 columns on LibreOffice 5.4 and 6.3. It's working as expected. Only 1024 columns are imported. Could you please test this document with other version of LibreOffice, to confirm any regression?
Created attachment 152939 [details] LO spreadsheet with 3201 columns for testing with previous LO versions
As suggested by Bartosz, I opened the file attached to comment 86 in LibreOffice 6.1. It gives (as expected) the error message: "The data could not be loaded completely because the maximum number of columns per sheet was exceeded". Then Calc opens the file, but only shows (as expected) columns up to 1024. Version: 6.1.6.3 Build ID: 1:6.1.6-0ubuntu0.18.10.3 CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3; Locale: en-GB (de_DE.UTF-8); Calc: group threaded
Created attachment 152963 [details] Screenshot from Excel, while .xls file is opened. The 256 colums limitation is visible If excel is opening .xls file (which support only 256 columns), there is no possible to edit columns above 256 (see attached screenshot). To be able to edit columns above 256, document needs to be saved in another file format (like .xlsx).
Another test with the attachement to comment 86: I opened the file in the document viewer of UBPorts (Ubuntu Touch). The document viewer is based on LibreOffice 5.x Kit (is it version 5.4?). The document loads fine. There is no error message. However, the application crashes when I scroll to column 1024. Actually, it crashes when I am in column 1019, because then 1024 would be visible, which seems to cause the crash. System: UBports with document viewer (LibreOfficeKit 5.x)
Test of the attachment to comment 86 with Gnumeric 1.12.43. Gnumeric loads the spreadsheet nicely up to column 3201. No problem.
thanks for the share, facing this issue since many days, regards, https://www.titaniumtvapp.xyz/
This issue has been noted since 2012. It is now more than 7 years later and a solution still has not been implemented. Meanwhile, not only is Excel at 16k columns, but even WPS Spreadsheet also has 16384 columns. Meanwhile user like myself have had numerous times when this issue becomes a problem. I would be happy to be a beta test user when you get to that stage. Thanks.
> It is now more than 7 years later and a solution still has not been implemented. This can be squarely blamed on all those who havn't implemented the feature: there are globe full of those slackers ;-) Then again; Noel has been doing some good work here - we're even fixing the regressions from the re-factoring required. I would be amused to see how WPS scales with any significant volume of data. So there is progress, but it is not done yet. I imagine there are prolly some other regressions from the re-factoring to make this possible, do go give the latest LibreOffice 6.3.n or nightly snapshots a good hammering in calc in this area and see if you can find some. Thanks.
I would like to support watkec's comment. A spreadsheet that is limited to 1024 columns is of little pratical value. We live in "big data" times. I think you should consider assigning this feature a higher priority. In my work I continue to use Excel mainly because it supports large spreadsheets.
(In reply to Michael Meeks from comment #93) > > It is now more than 7 years later and a solution still has not been implemented. > > I would be amused to see how WPS > scales with any significant volume of data. WPS Office 2016 with an xlsx of about 40MB with more than 3000 rows and 5000 columns work way better than all competitors, included MSOffice 2016. It opens in competitors like FreeOffice,GNumeric, OnlyOffice,.... And Libreoffice remains not opening right xlsx files and, in enterprises, noone can leave MSOffice if it can't open his files It's not much important to LOO devs to open xlsx files? Since 2012/06/09..
As one of the libreoffice developers working on this feature, I would just like to say that every time I see another complaint about something I do in my space time with my own resources, means that I decide to work on something else for a while.
(In reply to Noel Grandin from comment #96) > As one of the libreoffice developers working on this feature, I would just > like to say that every time I see another complaint about something I do in > my space time with my own resources, means that I decide to work on > something else for a while. Well, it's not that I'm arguing against you or other devs, it's more for "Libreoffice people that assign bugs and importance of things to improve" that maybe it's better to finish this instead of improving other things that works If I knew C++ as yours, I could help, but I not good at that at this level Thanks for your work at free time in Libreoffice! I hope you don't take it the wrong way
Hi Kevin, > Well, it's not that I'm arguing against you or other devs, it's more for > "Libreoffice people that assign bugs and importance of things to improve" > that maybe it's better to finish this instead of improving other things > that works Just to translate - there is no-one doing global prioritization for what our volunteers work on; so complaining in bugs does nothing good - except put off those who are interested in working on this; one of whom is Noel. > If I knew C++ as yours, I could help, but I not good at that at this level All people start like this, if you want to get involved - this particular change is a matter of replacing 'MAXCOL' with pDoc->MaxCol() at a very large number of places and testing the result. It is something that a beginner can do (in many cases) as an easy-hack. If you'd like to get involved - I'd be happy to help you. > Thanks for your work at free time in Libreoffice! I hope you don't take > it the wrong way Thanks for saying thank-you ! =) much appreciated.
(In reply to Michael Meeks from comment #98) > > > If I knew C++ as yours, I could help, but I not good at that at this level > > All people start like this, if you want to get involved - this > particular change is a matter of replacing 'MAXCOL' with pDoc->MaxCol() at a > very large number of places and testing the result. It is something that a > beginner can do (in many cases) as an easy-hack. If you'd like to get > involved - I'd be happy to help you. Well.. I downloaded source code and prepared a folder, but.. I don't know how to start, see, etc... For me is big project at "first see". Any help I will appreciate it much :)
Hi Kevin, > Well.. I downloaded source code and prepared a folder, but.. I don't know how > to start, see, etc... For me is big project at "first see". Any help I will > appreciate it much :) Great attitude ! so - I just pushed another small sample patch like this: https://gerrit.libreoffice.org/81000 sc: rowcol: tdf#50916 And remembered the commit id - which should help link it into this bug as/when it goes through gerrit. In a nutshell, for each use of 'MAXCOL' we need to classify whether this is an 'easy' one - ie. we have a well defined use-case, and an in-range column (it seems we use MAXCOL+1 as an out-of-bound magic/invalid) state. And for all the easy ones we need to just replace the macro MAXCOL with pDoc->MaxCol() - for some value of pDoc [ we need a reliable pointer and/or reference to the document we are using that reference for ]. Hopefully that makes sense. I would submit these in small chunks (as above) to gerrit - and let our CI system compile and test the result; you could possibly even edit inside gerrit for this one - but best to get familiar with doing that on the real code. Please do CC me or Noel for reviews, Thanks ! =)
Michael Meeks committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2b660f0bd0867bdd89f611e7ee60362b11be1874 sc: rowcol: tdf#50916 chip away at some more call sites. It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Meeks committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2571a11aeb0bdca20242caa5c96f0a5b3ea5db90 sc: rowcol: tdf#50916 convert ucalc test, and docfunc. It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Aron Budea committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f900c896697386fcc82b51f3f9ab3c8a84fdbb67 sc: rowcol: tdf#50916 convert ui/undo It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c219bcdc1ef4972f67e994ce153e21c144e636e9 sc: rowcol: tdf#50916 convert viewfunc It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 128299 has been marked as a duplicate of this bug. ***
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ad3e00237f48c52dbd2833f21f5e2f5acfdd4167 sc: rowcol: tdf#50916 convert tabview It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Aron Budea committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4cee86a0ee1c2f2b35c59b13e708d9a6941d2730 sc: rowcol: tdf#50916 convert some in ui It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/25732d7f211ce51fcecbb15ce6d9c551c2715b6e sc: rowcol: tdf#50916 convert output It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bef71336399f1dc678eee16b5d6d7bf26a17f491 sc: rowcol: tdf#50916 convert gridwin It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5d3b6e482e72451bd508b3a4db9f182ab4da388d sc: rowcol: tdf#50916 convert cellsh It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/009e7a54f40ebacd9dd4a394504c277789699801 sc: rowcol: tdf#50916 convert unoobj It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/48ab1b2fbb3496cef478db11539ccd08b527656d sc: rowcol: tdf#50916 convert miscdlgs It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6055814a98a764117cd95adf2bbab91fa34456c2 sc: rowcol: tdf#50916 convert app It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dbf02b8b6c34313affda860fc6c5bbc64839b2d9 sc: rowcol: tdf#50916 convert docshell It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
with: Version: 6.4.0.0.alpha1+ (x64) Build ID: 1efe1f82fabb3b8566c0beca2ba5df21c54fa6d5 CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded - select cell AMJ1 - insert Columns after -> crash no crash with: Version: 6.3.2.2 (x64) Build-ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc:
(In reply to Oliver Brinzing from comment #115) > - select cell AMJ1 > - insert Columns after > -> crash I can reproduce this, and it manifests as an assertion failure in a debug build: soffice.bin: /.../libreoffice/sc/source/ui/docshell/docfunc.cxx:1706: bool ScDocFunc::InsertCells(const ScRange&, const ScMarkData*, InsCellCmd, bool, bool, bool): Assertion `!"can't move"' failed. This is with a (debug) build from 1efe1f82fabb3b8566c0beca2ba5df21c54fa6d5. What I can say is that there's no crash with the current latest linux bibisect (non-debug) build: de4839e66d3d195315729b95cc144cdab96b6e74. Considering most of the changes are from the past few days, this doesn't tell a lot either way.
(In reply to Aron Budea from comment #116) > soffice.bin: /.../libreoffice/sc/source/ui/docshell/docfunc.cxx:1706: bool > ScDocFunc::InsertCells(const ScRange&, const ScMarkData*, InsCellCmd, bool, > bool, bool): Assertion `!"can't move"' failed. So, this isn't a new thing, and could be checked with the old lo-linux-dbgutil-daily bibisect repos, and goes back to 5.2 (the assertion check was added then). Opened a new bug report on it: bug 128359.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6a45c9755293f0969b4c2081d6d602bac9986d16 sc: rowcol: tdf#50916 convert documen* It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/78f63c2b1cd4e185f11486a7b2bdf7fd89ef1b03 sc: rowcol: tdf#50916 convert column* It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Aron Budea committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1bca91f086be08c41e51f5f7cc7616ce8c5cb799 sc: rowcol: tdf#50916 convert filter/excel for the most part It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Honkai Impact 3 finally arrives on the PC! Download the game here and take the fight to the Honkai menace with action RPG gameplay. https://honkaiimpact.io/
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0ef5c47547bec6319b853326603f3b807407fe78 sc: rowcol: tdf#50916 convert core/tool It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Aron Budea committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dc4a4c392944afac3d8cb02d0036b653b251efba sc: rowcol: tdf#50916 convert filter/* It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/218db5faae9255247c6fc30ebe37f82764397161 cid#1455213 sc: rowcol: tdf#50916 check pDoc for MaxCol() or MAXCOL It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f7ccd0f546c7362ef9a19ce515ac1404866a8c82 sc: rowcol: tdf#50916 convert data/attrarray It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a8a064d11c05feed83f05b0ce8209f7054afd804 sc: rowcol: tdf#50916 convert mark data structures It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f8641f0106ee45731449966f798957a8dc09cfb6 sc: rowcol: tdf#50916 convert core/data/table* It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/916746a5155a1a17225e85d2c30a1c2322aac589 sc: rowcol: tdf#50916 convert segmenttree It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1c8b8e97eb6127e430c1dc0fc3578cec94371fd7 sc: rowcol: tdf#50916 add UI to turn jumbo sheets on It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/79f80e21022f897de27ba37c516bb0e6e64693ce sc: rowcol: tdf#50916 initial conversion of Valid* methods It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi guys, I have just read the whole thread showing 7 years of work and efforts for this major improvement to come and one only comment for you : congrats ! I'm a teacher and everytime I use LibreOffice with the kids, I tell them about you, your work and all that stuff. Thanks !
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/40b0bd21e87480b659e7ed92854eee385a2a3c55 sc: rowcol: tdf#50916 pass ScDocument to the token classes It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/afad9ccb381a02b90654a5fa302480e46f38a1fc sc: rowcol: tdf#50916 pass ScDocument* around in data/ It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0cb4b2a18b790ff74a6893781beba2c4a4a8ce8f sc: rowcol: tdf#50916 pass ScDocument* around in filter/ It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/113444f59dc7690850919155b9b164b1a686bbe7 sc: rowcol: tdf#50916 create ScSheetLimits to hold by rtl::Reference It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5bcdbf03012e9d2754c3eb166bd5a01201406d9b sc: rowcol: tdf#50916 convert Valid* methods It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
https://bestreviewsproducts.com/lightest-gaming-mouse/ Looking to alleviate carpal tunnel or repetitive strain injury without cutting down on your computer time? Using the best ergonomic mouse should help. There are ...
https://pinoytambay.su/
(In reply to Gerry from comment #0) > Currently Calc is limited to 1024 columns. > > This limitation causes problems for certain use cases: > * import of .xlsx files with more than 1024 columns (Excel 2007 allows 16384 > columns) > * generally calculations with big matrices/tables > > Please enable Calc to handle up to 16384 columns. <a href="https://pinoytambay.su/" rel="noopener" target="_blank">Pinoy Tambay Online Tv Show</a>
I like this website its a master peace ! Glad I found this on google. Check my new blog post https://scooterlay.com/best-longboards/
Will upcoming LibreOffice Calc 7.0 support more than 1024 columns? Since 6.4 there were 8 commits targeting the next release. Is there still anything missing to finish this feature for 7.0? Thanks!
There is still some file filter work to store the current workbook's geometry which is needed to ensure that formulae keep working - that needs a calc core person to find some time to do it; or a very enthusiastic volunteer. Then the feature could come out of experimental I guess, and allow user-configurable sheet sizes too perhaps.
(In reply to Michael Meeks from comment #142) > There is still some file filter work to store the current workbook's > geometry which is needed to ensure that formulae keep working - that needs a > calc core person to find some time to do it; or a very enthusiastic > volunteer. Then the feature could come out of experimental I guess, and > allow user-configurable sheet sizes too perhaps. Thanks Michael for the explanation. Is it possible that you bring this to the ESC / developers call? It sounds like the toughest parts of this important Calc feature are done. More than 1024 columns in Calc are really needed.
> Thanks Michael for the explanation. Is it possible that you bring this > to the ESC / developers call? Anyone can do that; just show up - but in general pleading for developers to work on certain features there is frowned upon really: there is no magic supply of development resource to address this that I'm aware of =) > It sounds like the toughest parts of this important Calc feature are done. > More than 1024 columns in Calc are really needed. Happy to help provide you or anyone else with some code pointers and/or mentoring to work on this if you're interested of course.
I would be happy to help implementing this feature. @Michael Could you please provide the some example document for testing, and some instruction how to test filters? Such information will be very useful for implementation validation.
At beginning of the rapport you can find an example named "A spreadsheet with 10 000 empty sheets".
Created attachment 160704 [details] MS Excel 2016 spreadsheet with 3200 columns .xlsx (default) format
Created attachment 160705 [details] MS Excel 2016 spreadsheet with 3200 columns Strict OpenXML (.xlsx) format
Created attachment 160706 [details] MS Excel 2016 spreadsheet with 3200 columns exported to .ods OpenDocument format
(In reply to Bartosz from comment #145) > I would be happy to help implementing this feature. > > @Michael Could you please provide the some example document for testing, and > some instruction how to test filters? > > Such information will be very useful for implementation validation. Thank you so much @Michael and @Bartosz : I just added 3 example documents, all created in MS Excel 2016 and all have the same content: In the first row there are continuous numbers from 1 - 3200, so that the sheet has 3200 columns. attachment 160704 [details]: saved as .xlsx (default) file format attachment 160705 [details]: saved as Strict OpenXML (.xlsx) format attachment 160706 [details]: saved as .ods OpenDocument format -> I checked this one and MS Excel 2016 opens it correctly with 3200 columns.
The relevant parts of the content.xml in the .ods file (attachment 160706 [details]) seems to be (showing columns 1, 2, 3, 3199, 3200): [...] <table:table table:name="Tabelle1" table:style-name="ta1"><table:table-column table:style-name="co1" table:number-columns-repeated="16384" table:default-cell-style-name="ce1"/><table:table-row table:style-name="ro1"><table:table-cell office:value-type="float" office:value="1" table:style-name="ce1"><text:p>1</text:p></table:table-cell><table:table-cell office:value-type="float" office:value="2" table:style-name="ce1"><text:p>2</text:p></table:table-cell><table:table-cell office:value-type="float" office:value="3" table:style-name="ce1"><text:p>3 [...] </text:p></table:table-cell><table:table-cell office:value-type="float" office:value="3199" table:style-name="ce1"><text:p>3199</text:p></table:table-cell><table:table-cell office:value-type="float" office:value="3200" table:style-name="ce1"><text:p>3200</text:p></table:table-cell><table:table-cell table:number-columns-repeated="13184"/></table:table-row><table:table-row table:number-rows-repeated="1048575" table:style-name="ro1"><table:table-cell table:number-columns-repeated="16384"/></table:table-row></table:table></office:spreadsheet></office:body></office:document-content>
There are code pointers here: https://lists.freedesktop.org/archives/libreoffice/2019-January/081909.html This and associated are the missing pieces: => switch to dynamic dimensions instead of MAXROW/MAXCOL ~everywhere. + anchor this on the document - as per Excel. + store a 'libo:max_range="A1:AMJ100000"' extended attribute on each ODF spreadsheet. => so MAXROW/MAXCOL becomes the real upper limit and/or defaults for new docs. + create new defines for default below:
I just updated LibreOffice 7.0 Release Notes, with information how to enable Very Large Spreadsheet support: https://wiki.documentfoundation.org/ReleaseNotes/7.0#Support_for_very_large_spreadsheets Please take a look and verify if the information are correct.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b5372f4fe3fbcdb0267ab6c5bef9876e851118ff tdf#50916 Fix keyboard shortcut for enabling very large spreadsheets It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/16861376f684f46ab7ca9716d0de2a3f9f5c5a57 tdf#50916 FILEOPEN Remove too many columns warning, which is no longer relevant It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi Bartosz, (In reply to Commit Notification from comment #155) > tdf#50916 FILEOPEN Remove too many columns warning, which is no longer > relevant Is it clear that this will no longer be in experimental mode in LO7?
(In reply to Cor Nouws from comment #156) > Is it clear that this will no longer be in experimental mode in LO7? That warning was not related to the user-visible warning, but a debug warning that is irrelevant now for any mode (both standard and "big table").
If you want to https://techsquiral.io/episode-mod-apk the episode mod apk then thay will be at right place
Windows 10 x64, LibreOffice_7.0.0.1_Win_x64.msi After enabling Support_for_very_large_spreadsheets it can read these big .xlsx and it can create spreadsheets with more than 1024 columns, but it can't save it in any way. The saved file is corrupt :(
Windows 10 x64, LibreOffice_7.0.0.2_Win_x64.msi The sheet with values in XFA1 and XFB7 created in MS Excel and saved as xlsx and ods opens with no error but the values are moved to AMK1 and AML7, accordingly. The same result is in case of creation in Calc (XFA1 and XFB7) and saving in ods format.
How to enable support for very large spreadsheets in LO7 RC2 Calc?
kindly let me know how to find a bug in the website. https://wikisbios.com
(In reply to tr00don from comment #161) > How to enable support for very large spreadsheets in LO7 RC2 Calc? Via the following steps in Tools -> Options...: - First under LibreOffice -> Advanced, check Enable experimental features (may be unstable), - After a restart, under LibreOffice Calc -> Defaults, check Enable very large spreadsheets (16m rows, 16384 cols).
@Andrey, did you report these issues as separate bug reports? (And made them block this meta bug: https://bugs.documentfoundation.org/show_bug.cgi?id=133764 ) Related to this bug: can it now be closed? Or do we still need something, like a message to explain to the user that the file they are trying to open will only work if the experimental feature is turned on?
For men tattoo ideas check this out: https://www.tatoosdesign.com/ For Women Beatiful Tattoo design ideas check this out: https://www.tattoosforgirl.com/tiger-tattoos-for-women/
English: I think it could be left open to put a link to the bugs that we see appear with this new functionality, for example I just saw a failure by pressing the CTRL + keys below, Calc closes. Spanish/Español: Pienso que podría dejarse abierto para poner un enlace a los bugs que veamos aparecen con esta nueva funcionalidad, por ejemplo yo acabo de ver un fallo pulsando las teclas CTRL+abajo, se cierra Calc. Esperanto: Mi pensas, ke oni povus lasi ĝin malferma por meti ligon al la eraroj, kiujn ni vidas kun ĉi tiu nova funkciado, ekzemple mi nur vidis malsukceson premante la klavojn CTRL + sube, Calc fermiĝas.
thanks for creating such a nice info about Allow more than 1024 columns in calc. True and exact information i found on this page, kindly keep sharing with us. https://coffeetalkwriters.com/best-instant-coffee
Thanks for the post https://excricket.com/
thanks for the post <a href="https://techloguide.com/best-laptops-for-sims-4/">Best laptop for sims 4 </a>
Why Calc is Limited to 1024 I am facing issues in Importing data https://bigbos14.com https://watchbiggboss14.com
Grat information and solutions. Thanks https://www.pickmyscooter.com/best-longboard-wheels
(In reply to Aron Budea from comment #163) > (In reply to tr00don from comment #161) > > How to enable support for very large spreadsheets in LO7 RC2 Calc? > Via the following steps in Tools -> Options...: > - First under LibreOffice -> Advanced, check Enable experimental features > (may be unstable), > - After a restart, under LibreOffice Calc -> Defaults, check Enable very > large spreadsheets (16m rows, 16384 cols). Thank you very much for this great improvement. I have just a question. Now, the maximum number of columns 16384 can be changed (to a larger number). What it depends on?
(In reply to iago from comment #172) > Thank you very much for this great improvement. > > I have just a question. Now, the maximum number of columns 16384 can be > changed (to a larger number). What it depends on? You could change the maximum number of columns/rows with MAXCOL_JUMBO and MAXROW_JUMBO constants. Unfortunately you need to rebuild the LibreOffice. MAXCOL_JUMBO and MAXROW_JUMBO constants could be changed here: https://cgit.freedesktop.org/libreoffice/core/tree/sc/inc/address.hxx#n74 Keep in mind that usage of such high number of columns/rows, would impact performance and memory consumption.
@gmolleda: the meta Bug 133764 exists for that exact reason: tracking any issue related to this feature. I think this bug can definitely be closed now.
Currently Calc is limited to 1024 columns. This limitation causes problems for certain use cases: * import of .xlsx files with more than 1024 columns (Excel 2007 allows 16384 columns) * generally calculations with big matrices/tables Please enable Calc to handle up to 16384 columns. (In reply to Gerry from comment #0) > Currently Calc is limited to 1024 columns. > > This limitation causes problems for certain use cases: > * import of .xlsx files with more than 1024 columns (Excel 2007 allows 16384 > columns) > * generally calculations with big matrices/tables > > Please enable Calc to handle up to 16384 columns. (In reply to Gerry from comment #0) > Currently Calc is limited to 1024 columns. > > This limitation causes problems for certain use cases: > * import of .xlsx files with more than 1024 columns (Excel 2007 allows 16384 > columns) > * generally calculations with big matrices/tables > > Please enable Calc to handle up to 16384 columns.
(In reply to aashish kumawat from comment #175) Dear Aashish, the feature is implemented, but still highly experimental. You can enable it in the preferences if you activate "experimental features". However, you will encounter a number of bugs. Please see meta bug 133764 for known bugs. If you encounter other new bugs, please report them.
The year 2020 is slowly coming to its end - but Empyrion Galactic Survival is not! With the upcoming v1.3 we are adding a bunch of bug fixes, but also several new features and more content. One of the main features is the new decals system. The decals feature will allow you to bring custom pictures into the game and add it to structures spawned in the playfields.
*** Bug 139688 has been marked as a duplicate of this bug. ***
(In reply to m.a.riosv from comment #178) > *** Bug 139688 has been marked as a duplicate of this bug. *** I asked bout the row limit being increased, or simply removed. And the error message being clarified to say what the actual limit is. Of course, could simply open in a 2nd, or 3rd sheet if over the limit? My TSV file has 34M rows Unfortunately I still see this issue with v6.4.6.2 maybe my Ubuntu package is out of date I enabled, but same error : "The data could not be loaded completely because the maximum number of rows per sheet was exceeded." "Menu/Tools/Options/LibreOffice/Advances - Enable experimental features." Maybe my v6.4.6.2 on latest Ubuntu is out of date. Can the error message clarify the 1 Million line limit?
LibreOffice Calc 7.0.5.2(x64) seems to successfully open my tab-formatted file (4670x3650 cells) but then it just crashes no matter what I do.
Creed stood out for many fine fragrances. This Creed Royal Oud review focuses on one of the most well-received creations of the last decade of the new millennium. Many frown their eyebrows when they found out how recent this instant classic is.
Creed stood out for many fine fragrances. This Creed Royal Oud review focuses on one of the most well-received creations of the last decade of the new millennium. Many frown their eyebrows when they found out how recent this instant classic is. www.groomingwise.com/creed-royal-oud-review/
<a href='www.groomingwise.com/creed-royal-oud-review/'>Creed Royal Oud</a>
Bug 144300 created by me same with this. If i use experimental features and find bugs, i reported back here or not at all?
Thanks for the amazing work Here.
More than 1024 columns are now allowed in Calc by enabling the experimental feature, so this bug is marked as fixed. Issues related to this should be reported as separate bugs, categorising it with the meta bug 133764 (use that number in the "Blocks" field of the bug report). For example, one could be opened to make this feature not experimental anymore. (In reply to tr00don from comment #180) > LibreOffice Calc 7.0.5.2(x64) seems to successfully open my tab-formatted > file (4670x3650 cells) but then it just crashes no matter what I do. tr00don, if you still experience the issue with a current version of libreOffice, please open a new report. (In reply to elias estatistics from comment #184) > Bug 144300 created by me same with this. If i use experimental features and > find bugs, i reported back here or not at all? elias, please continue reporting specific issues in separate but reports.
(In reply to stragu from comment #187) > More than 1024 columns are now allowed in Calc by enabling the experimental > feature, so this bug is marked as fixed. I'd leave this open until the feature leaves experimental mode, since that would mean it's mature enough for everyday use.
*** Bug 137228 has been marked as a duplicate of this bug. ***
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4c5f8ccf0a2320432b8fe91add1dcadf54d9fd58 change default Calc number of columns to 16384 (tdf#50916) It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.