tdf#50916 : Calc : Dynamic column container

Eike Rathke erack at redhat.com
Mon Oct 12 08:29:27 PDT 2015


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20151012/fa75c455/attachment.sig>


More information about the LibreOffice mailing list