Merging Calc's label range functionality with named range.

Eike Rathke erack at
Tue Jul 23 04:00:09 PDT 2013

Hi Kohei,

On Thursday, 2013-07-18 08:25:45 -0400, Kohei Yoshida wrote:

> >* The actual label name displayed is taken from a cell's content,
> >   formula expressions using a label automatically change their display
> >   label names whenever that cell content is changed.
> >   * This is not possible with named ranges.
> Sure. But is this *that* important to users?  To me the whole label
> range implementation is such a duplicate functionality for very
> little marginal difference, and I'm not really sure if that
> difference even matters.

For those who use it it probably is important ... anyhow, this is even
part of ODFF, so we somehow should support it. What is debatable is the
"automatic label lookup" that IMHO should be deprecated and the default
configuration setting be disabled.

> >* One label names exactly one row or one column, expressions or
> >   multi-column/row ranges are not possible.
> >   * The named expressions dialog could restrict that though.
> I don't see how that restriction could be useful.  You can define
> one column / one row only named ranges (or database ranges for that
> matter).  Is there a use case where having this restriction is
> useful in real life?

It is needed for the intersection of row and column labels, that works
only with vectors, e.g.  ='Sales' 'Hamburg'

> >* The label name can include spaces and other arbitrary characters that
> >   in a formula expression would have special meanings, using such a name
> >   in an expression is possible by enclosing the entire label name in
> >   single quotes. A label name can even be a string that otherwise would
> >   be a cell reference.
> Yes.  And the fact that this can be a string is actually very scary
> to me.  This potentially makes tracking references very difficult
> without sacrificing performance.  Dropping it would enable us to
> optimize it further.

The performance bottleneck is the automatic label thing where the
sheet's content is searched for a string; searching just a few defined
label ranges (if any) doesn't make much difference compared to named

> >   * A named range currently has to consist of alphanumeric+underscore
> >     characters and can't resemble a cell reference.
> >   * ODFF does provide means to store usage of such non-simple names
> >     though with $$SingleQuoted but we need to implement that in the
> >     formula compiler (anyway), see
> >
> >
> >Furthermore we probably could use exactly the Label functionality for
> >the GSoC "Enhanced Database Ranges" Table feature when it comes to
> >in-Table formula expressions adressing the Table's rows or columns.
> >Actually it would be necessary to support identical label names for
> >different Tables (ranges) within one sheet, again this is not possible
> >with named ranges.
> I'd rather we extend the database range code to support these
> missing bits rather than piggybacking on top of the label range
> code.  I don't see it as a reason why we need to keep label range.

I meant the special Excel cell formula syntax for formulas in cells of
a Table that address rows/columns/intersections of the Table by their
header names. That is very similar to defined labels
compiler/interpreter-wise. Of course it doesn't matter where we actually
stick the "defined label" in, having them as part of the database range
probably is best because we usually can derive it from the top-row of
the database range (don't know currently if Excel allows more than one
row for those Table labels, they did a very awkward thing with their
labels back then).


LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key ID: 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
For key transition see
Support the FSFE, care about Free Software!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <>

More information about the LibreOffice mailing list