Hi, On Saturday, 2015-10-10 00:05:11 +0200, Markus Mohrhard wrote:
Most likely a few more that I have not in mind right now.
Additional caveats that sprang to mind:
* sizes and distribution of area listener slots
* this currently is based on MAXCOLCOUNT values on compile time and
there even exist preprocessor checks that ensure certain multiples
of 16 so that things fit, see sc/source/core/data/bcaslot.cxx
* distribution of slots is exponential starting from top left because
it is assumed that the top left of a sheet is more populated than
the far out bottom right
* actual creation of slots is already dynamical, but the distribution
algorithm may have to be reworked
* if a user really needs and populates more than 1024 columns, having
even larger slots in the far right probably slows down things when
changes occur in that area
* named expressions that involve relative comlumn offsets
* ugly stuff, because relative offsets wrap around the column edges
* e.g. having defined a name on A2 to =A1 and using it on A1 will
give =A1024 with 1024 columns
* this because Excel does it ...
* already a nightmare during import/export of documents that have
different dimensions, because neither ODF nor OOXML or BIFF store
the actual dimensions, they are only implicityl known by which
program and version generated which file format
* we'll probably have to change that and come up with file format
extensions
* none of the generators or readers so far handle dynamic column
limits
* reference update procedures work with MAXCOL values
* these would have to get the actual column maximum get passed in
* BUT, references like 1:1 meaning the entire row would not know that
a larger column suddenly is available, internally they currently
store for example A1:AMJ1 and just know that it's the entire row and
take it into account that the anchors are sticky when references are
updated
* probably range references need a "this is the last column" flag
* if that changed, the next caveat kicks in: how to store in file
format? An older release encountering A1:XXX1 when reading the
file WILL fail on that
* so a change will have to be carefully prepared and distributed
over various releases to enable at least the two previous
releases to handle such references
* if dynamically adding columns is made possible, increasing the columns
would have to be done on *all* sheets, else all 3D addressing would be
a nightmare
Just what I quickly came up with..
Eike
--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Attachment:
signature.asc
Description: PGP signature