Created attachment 184564 [details] The attachment announced in the report Maximum number of columns was increased to 16384 (2^14; XFD). Older versions prepared to be confronted with supersize sheets from different software load new files sending a warning if there is content in the upscaled range. So far ok. However, the warning also pops up if there is no content, but just a CF that reaches out there - without any references to cells from that range. In addition the respective CF remains dysfunctional after that. For a related issue see https://ask.libreoffice.org/t/86329/4 The first example I attached there to my answer is afflicted. I also attach it to this report. Insofar this is an issue with V7.3 and many older ones. A fix may be difficult (impossible) because it depends on the behavior of old versions. If a "new outreaching" CF can be stored to .ods in a way allowing old versions to ignore the additional columns is -at least- doubtable.
If it works with 7.4, you got 3 possibilities: - refuse new file if you want to stick to LO < 7.4 (I suppose it can be complicated) - get the source code and try to (or ask/pay someone to) fix the pb (idem) - upgrade to a newer LO version (hopefully, LO is free). Now of course, depending on your situation, it may have a cost (time obviously) and money if you're in a professional world and must migrate several workstations to use new LO version (eg: to test that a bunch of specific documents with macros still work) IMHO this bugtracker should be a WONTFIX since 7.3 branch is EOL (see https://wiki.documentfoundation.org/ReleasePlan#7.3_release).
The report was definitely not due to my personal needs. I never used more than about 100 columns, e.g, and rarely that much. Also, I'm tempted to think the support of nonsensically large numbers of columns by "competitors" is a combative measure, without which there would be no reason for LibO developers to introduce such hokum. Can you give me a realistic example of the need? For users thinking in 2D-tables (contingency or whatever) for any kind of information we would need as many columns as rows. (And what about the higher dimensions?) I think we have another case of forcing a waste of development resources including the related risks of regressions on LibO abusing the expectations of a badly informed crowd. On the other hand I use lots of time trying to support LibO by my contributions to the ask site and to a conventional forum on the topic. That's my personal motive to prefer fresh versions. Doing so I had to learn today that an example I made with V7.4 to show how a request (linked into my report above) could be solved, did not work for the questioner nor for a different contributor both using a V 7.3.x. I would assume the compatibility of a software with its own different versions -backwards and forwards- wherever possible at all, is at least as much important as the compatibility with alien software for similar purposes. Well, in this case a true fix may be impossible. If somebnody is interested in my idea in what way remedy could be found nonetheless introducing a kind of workaround into the core code, I will answer the question, of course. Anyway I hope this was the last time here that somebody told the story of the open-source ways and the paid-for development.
I suppose that this should be mostly WONTFIX, because, while I agree that we need descent backward compatibility, it is also normal that any new feature that was absent in previous versions should be ignored in those versions. This happens how, the feature being the large range in the conditional format. There could be a corner case (shown in the attachment 184564 [details]), where the range spans the whole width. Then we can simply store the range as <calcext:conditional-format calcext:target-range-address="SheetN.1:1048576"> instead of <calcext:conditional-format calcext:target-range-address="SheetN.A1:SheetN.XFD1048576"> which would work for all versions since 5.0. The discussed corner case could be important enough to warrant the special treatment, because this could generally be used for "decorating" the whole area. Incidentally, the problematic file works fine in AOO, and even in OOo 2.2.0. It looks like we lack a fallback to the older (non-calcext) data when newer data can't be used. Unfortunately, this can't be fixed in 7.3 and older; but maybe it's worth fixing separately anyway.
Created attachment 184623 [details] Demonstrate the suggested workaround Because I have talked about a possible workaround, I would also like to explain how it is conceived and demonstrate that it would be applicable. 1. The workaround would require to include an additional step into the process of storing a spredsheet document: Filter all the defined CF for their ranges, and split every CF as well including cells with .Coulumn<1024 as some with .Column>=1024 in two, one restricted to the old limit of 1024 columns, the other restricted to the rest. 2. When loading such a file older versions currently destroying the complete "supersize" CF could then accept the first part and ignore the second one. 3. Versions >= 7.4.0 can even re-merge the pairs of ranges created the described way. Of course, I didn't create a private version of LibO for the demo, but did the split "manually". The trick worked with V 7.3.6. See new attachment Open it first with 7.4 or higher. Then try 7.3.6 or the like.
Yes. The afflicted versions killing the complete oversize CF settings will die out one day. But the problem occurred at least since V 3.6.5. Many users may still stick to versions in the range of 3.6 through 7.3 and will then not be able to use (e.g.) one of my listing-paper-templates created with 7.4 or higher. Compatibility of 7.4 files with later versions isn't afflicted anyway. The question is if a "dirty" workaround the way I described should be accepted/implemented. A clean solution will not be found.