Re: [Texmacs-dev] Table converision library

[Joris van der Hoeven]

> Yes, but typesetter evaluation from Scheme is not yet available. So
> the 'default' parameter is currently required.
> 
>   Note: typesetter evaluation will probably require the converter to
>   apply to a buffer (or a view) loaded with the document to export. It
>   may be useful on the short term to use that approach so the init-env
>   can be easily accessed by converters (e.g. to handle page size and
>   margin information).

I recall you that one 'table' can take several nested 'tformat's.
The addional parameter should therefore not be necessary.

> Also we could optionnaly make scope behave smartly. For example, the
> properties of a 'col' scope could not match the internal 'cwith'
> definitions if all cells of the columns overloads the 'col' settings.
> 
> That would make exported structure more WYSIWYG. But maybe that kind
> of transformation should rather reside in a tmtm simplification
> module.

I guess so.

> > > Properties are named by symbols. They match table properties used by
> > > the typesetter. Rows, columns and cells also define the extra property
> > > 'content' which gives the table data. Rows content is the table data
> > > as a list of lists in natural order, columns content is the table data
> > > in transposed order, cell content is the actual content of the
> > > designated TeXmacs cell element
> > 
> > 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.

> To me, "extracting  content and properties simultaneously" rather
> looks like table slicing. But I think the applicable algorithms can
> generally be implemented using Scheme mapping and iteration constructs
> with iterator scopes.
> 
> I think there should be clearly separated submodules in the table
> library. A table-parsing submodule and a table-construction submodule
> which provide primitive functionnality, more elaborate tools (like
> table slicing) could be built on those primitives. So the parsing
> would not get intermixed with higher level features.

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.

> > This really is a new, and interesting, level of abstraction which
> > is not really present in XML.
> 
> I do not see how XML is relevant here. Markup languages are about
> describing and transmitting data across modules. Here we are talking
> about a processing model...

The point is that the tformat construction is really a markup tool
with a non-trivial processing semantics. The semantics is slightly
beyond the XSL paradigm (and really table-specific).

> > > There could also be some accessors for grouping scopes, which might be
> > > useful to carry the meaning of cwith on ranges which are not simple
> > > rows, columns. But maybe that would only be really meaningful when
> > > TeXmacs has a real support for row groups and column groups.
> > 
> > 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.

> > I also agree that we need better support for row groups and column groups.
> > A good example of a situation where this is needed are numbered equation
> > arrays. One would like to be able to have properties or even macros
> > for saying that a row should be numbered or not.
> 
> This kind of feature could be implemented by a primitive which gives
> read-access to the table-context of the current cell (which would
> indeed be very useful). That is not what I mean when I mention row and
> column groups.
> 
> The HTML4 spec has an interesting discussion about row and column
> groups. From memory there are two kinds of groups:
> 
>   title groups -- <h:thead> <h:tfoot> <h:th>
>     Groups which relate specially to the rest of the table. For
>     example, when a table span several pages vertically, its top and
>     bottom title rows are repeated on each page. If the editors allows
>     scrolling of the table contents, the title group may be
>     decorations aroung the scrolling area.
> 
>     That is arguably very relevant to TeXmacs

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.

>   body groups -- <h:tbody> <h:colgroup>
>     Groups whose contents are semantically related. For example, in an
>     accounting application, a transfer column and a running balance
>     for the same account may belong to the same column group. They
>     also probably need to have precise nesting semantics.
> 
>     I am unsure that is relevant to TeXmacs. It seems that one reason
>     why that was included in HTML was to allow good aural rendering of
>     tables.
> 
> Groups are significantly different from subtables because their
> geometry is constrained by the table they belong to.

I think that "body groups" might correspond to macros which regroup
several cwith commands; we'll think about that later.

> And while we are talking of new typesetter features for tables, I want
> to remind that we may use more elaborate table property logic. For
> example one may want to have rows with alternated background colors
> (hey, Alvaro!).

In fact, I planned to implement a special property "transformation macro",
which will transform the contents of each cell in a specific way.
However, this is complicated now and will be easier after rewriters.

In fact, as a general idea, I think that it is very useful to
have the analogue of first-order lambda-like logic as part of markup.
Table formatting and line/page/table decorations are all part of
this general scheme. We still have to pursue the idea further.