[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Kspread row limit
From:       Tomas Mecir <mecirt () gmail ! com>
Date:       2009-12-29 18:19:56
Message-ID: 492258b10912291019hb7a06f0gb4cfbdaf36fdb58a () mail ! gmail ! com
[Download RAW message or body]

2009/12/29 Boudewijn Rempt <boud@valdyas.org>:
> If there is no maintainer right now, no decision can be made. If someone steps
> up to do the work to lift these limitations, he or she should not be stopped.
>
> The big issue here is, of course, that nobody has tried to get Hendrik to
> continue his experiments: he had already taken obstacles that most would-be
> contributors never manage, like getting the code to compile and changing
> things in it.

I am not active in KSpread development currently, but I'll throw in a
couple of comments regarding the limitations and the possibility of
their removal.

Firstly, regarding whether to do this at all or not, it tends to be
argued that if you really need more than the offered 32,000 rows or
columns, you should probably use a relational database, not a
spreadsheet, as they are better specialized for large data volumes.
That's not really a technical argument, though.

As for the actual work, there may be some obscure problems related to
raising the limits, but the basic work is trivial. In
kspread/Global.h, change the KS_rowMax and KS_colMax constants. Then,
remove the ": 16" bits from the Cell::Private structure in
kspread/Cell.cpp. The PointStorage class already operates on "int"s,
so no change is needed there.

Tada, row/column limit has been increased.

Then, of course, you need to test if everything is still working
correctly - there may be some odd limitations in some functions,
although I doubt that.

This change doesn't come free, though, and there are two things to
consider before doing it.

First, the limits allow the row/column numbers (stored in each
instance of the Cell class) to be 16-bit integers. Upon raising them,
the numbers will become 32-bit, perhaps even 64-bit on 64-bit
platforms. Thus, you get higher memory usage even if you don't
actually need so many rows/columns.

Second, attempting to load a file that makes use of more rows into an
application than what the application can support will probably lead
to loss of data  excel 2003 or older would be a prime example here;
not sure if the 2007 version or OO.org would handle this better.
Limits in file formats could also be an issue - ODS is XML-formatted,
so storing a bigger integer should not be a problem, but other formats
could be storing row/column numbers as 16-bit integers (investigation
is needed here).

Neither of these problems is a show-stopper, of course, but they do
need to be pointed out.

/ Tomas
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]