Re: [Texmacs-dev] Table converision library

[Joris van der Hoeven]

> > > > Yes. Notice that you might also want to extract content and properties
> > > > simultaneously for certain purposes. In fact, the table paradigm is
> > > > very rich and we will need to play with it...
> > > 
> > > What are you thinking of?
> > 
> > What happens if you do a copy&paste.
> 
> What happens then is what I call table slicing.
> 
> > In fact, several parts of the library are already
> > implemented at C++ level in modify_table.cc,
> > so this can serve as a (partial) model.
> 
> I'll try to remember that.

OK; please take a look at how 'table slicing', following your words,
has been implemented.

> > > > Notice that we also have subtable-scopes.
> > > 
> > > What do you mean? Is that about typesetter subtables?
> > 
> > You may want to extract the information of rows 2 to 6 and columns 3 to 5.
> 
> Yes, I forgot that.
> 
> Some converters can find an use for such informations. But I think
> that kind of accessor is too generic. These scopes (which I would call
> row-range, col-range, and cell-range scopes) are only meaningful when
> one knows there IS some specific format associated to the ranges.

No: it is useful for cut & paste or inside spreadsheet applications.

> Maybe someting like
> 
>   range: global
>   properties: groups col-groups row-groups cell-groups
> 
> would be more useful. They could return a list of group definitions,
> where a group definition could be:
> 
>   (row-group i1 i2 prop1 ... propN)
>   (col-group j1 j2 prop1 ... propN)
>   (cell-group i1 i2 j1 j2 prop1 ... propN)
> 
> only then range accessor would be used on given ranges and
> properties...
> 
> But maybe decoupling group detection and range accessors is still too
> generic, and a more efficient solution would be returning
> 
>   (row-group i1 i2 (prop1 val1) ... (propN valN))
>   (col-group j1 j2 (prop1 val1) ... (propN valN))
>   (row-group i1 i2 j1 j2 (prop1 val1) ... (propN valN))
> 
> Also more intelligence could be use to produce simple elements when a
> group contains only one element.
> 
>   (row i (prop1 val1) ... (propN valN))
>   (row j (prop1 val1) ... (propN valN))
>   (cell i j (prop1 val1) ... (propN valN))
> 
> The group accessors would superseed all other accessors. Actually they
> would be just thin wrappers to the cwith data which perform
> aggregation of properties applied to the same ranges.
> 
> An outstanding problem is wether the i and j should use the negative
> number notation used in cwith (more information) or translate it to
> physical positions (more ready to use).

We'll rediscuss this issue later on.

> > Yes, but beyond scope for the moment.
> > We already do have an analogue in the case of line breaking;
> > a similar scheme will probably be relevant here.
> 
> I have just discovered what decorate-atoms was for.
> 
> That is a nice, but I have the feeling something is still missing. If
> the decoration takes horizontal space, the line runs into the right
> margin. I see no mechanism to increase the margins to make room for
> horizontal decorations of any length.
> 
> Similarly, title rows must be taken into account when hyphenating
> (page-breaking) tables. That is probably simpler because title rows
> are constants while atom decorations are dynamic values.

Let us resume this discussion later too :^)))

> Yes... but TINAPN (that is not a priority now) (pronounce tinappen).

Right...