Re: [Texmacs-dev] Table converision library

[david]

On Thu, Feb 06, 2003 at 03:01:56PM +0100, Joris van der Hoeven wrote:
> 
> > Yes, but typesetter evaluation from Scheme is not yet available. So
> > the 'default' parameter is currently required.
> 
> I recall you that one 'table' can take several nested 'tformat's.
> The addional parameter should therefore not be necessary.

That is true. I think that the 'default' parameter provides for
convenient notation. It allows one to write

  (tmtable-parser default x)

instead of

  (tmtable-parser `(tformat ,@default ,x)).

Then it is mostly a matter of taste. The first notation is shorter and
lighter, the second notation can be regarded as a better expression of
intent.

Well... after all I think I prefer the second notation *because* it is
a better expression of intent :-)


> > > 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.

> 
> > > 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).

I think you underestimate the expressiveness of XSL.

It is true that I have never seen that kind of construction anywhere
else. But saying that it is not present in XML is missing the
difference betwen XML and XML applications (XHTML, DocBook/XML, etc.).
But that can be considered nitpicking.

 
> > > 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.

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).


> > 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.

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.

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

Yes, that would be a great feature and an interesting way to leverage
the orthogonality of macro expansion and table format items.


> 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.

I understand what you mean. Someting like

  (cwith ... "transform" (macro "i" "j" "content" ...))


> 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.

Argh... scientist jargon again...

> Table formatting and line/page/table decorations are all part of
> this general scheme. We still have to pursue the idea further.

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


-- 
David Allouche         | GNU TeXmacs -- Writing is a pleasure
Free software engineer |    http://www.texmacs.org
   http://ddaa.net     |    http://alqua.com/tmresources
   address@hidden  |    address@hidden
TeXmacs is NOT a LaTeX front-end and is unrelated to emacs.