Re: [Texmacs-dev] texmacs tree sanity checks needed

[david]

On Mon, Jan 13, 2003 at 09:11:10PM +0100, PUYDT Julien wrote:
> > > > A macro... parenthesis in my opinion are used to show blocks, hence they
> > > > must come by pair, to mark the begin and the end of the block. With the
> > > > possibility that in some cases we don't want it to be visible (<right|.>
> > > > comes to mind), but still exists.
> > > 
> > > Yes, so you can make a macro, which takes a block as argument and
> > > puts brackets around it. You can also make a macro which takes three
> > > arguments: the left parenthesis, the block, and the right parenthesis.
> > 
> > Actually, the macro might be an interesting solution in the abstract,
> > but currently that is not really useful because:
> > 
> >   -- there is no way AFAIK to make the macro export properly to
> >      big delimiters in LaTeX;
> > 
> >   -- last time I checked, expansions did not go along very well with
> >      indices, superscripts, and generally the extended typesetting
> >      information required to make math boxes.
> 
> Bad.

I just checked again. Math macros are still broken:

(document
(assign "big()" (macro "body" (concat (left "(") (arg "body") (right ")"))))
(equation* (document (concat (big\(\) (frac "x" "y")) (rsup "2")))))

If you paste this (Edit->Paste From->Scheme), you well see the
superscript is not correctly placed.


> > > > > > * double itemization: <\expand|itemize-minus><\expand|itemize-dot>;
> > > > > 
> > > > > This is perfectly valid.
> > > > 
> > > > Perfectly valid if you want to make a second list in one of the items of
> > > > the first list. But when the first list has that second list as a single
> > > > item, that is just bogus redundancy...
> > > 
> > > Still, you should be able to write such a thing.
> > > But I agree that we should make that more *difficult* to do.
> > 
> > I disagree. At least for HTML-exporting, that is invalid code and
> > should not be allowed. It might be useful as an intermediate state
> > when doing some edition, but it should not be considered valid.
> 
> Can you tell me what the second list does to the output on screen and
> paper? If "nothing", then it has nothing to do in the document...

It increases the left margin.

But "does it affect screen output" is not the right question. Some
semantic (i.e. logical) markup might not affect screen display but
still be desirable because it contributes information.

The right question might rather be: is that meaningful? Or maybe: can
it be exported to reasonable logical generic document formats?

These are actually the same question, but the latter externalizes the
definition of "what is meaningful" to the designers of accepted
"reasonable logical generic document formats". The remaning question
is what is "reasonable generic logical document format". At the moment
that is XHTML+MathML.


> > > > > > * <tabular|...> in math mode: removing it solved the problem.
> > > > > 
> > > > > This is also valid; it is a plainly stupid property of
> > > > > LaTeX to make tabular only available in text-mode.
> > > > 
> > > > When the only son of the tabular is a table, same problem: bogus.
> > > 
> > > Here I disagree: you may want a double frame around some text.
[...] 
> > Same difference: that may be meaningful to the typesetter, but that is
> > not meaningful as document information.
> 
> It doesn't seem it was meaningful: I don't remember texmacs to have had
> any problem when I removed them...

By "meaningful to the typesetter" I meant "the typesetter has no
problem handling it". I should probably have said "it makes sense to
the typesetter", since in that particular case the table did not seem
to bring additional meaning (to the typesetter or the user).


> > That is an instance of a more general problems: some constructions may
> > be meaningful for the typesetter, but do not constitute a valid
> > structure. A typical example is 'expand' where the first parameter
> > (macro name) is not a string node. That is meaningful for the
> > typesetter and it allows some useful trick in stylesheets but it is
> > not handled by export filters.
> 
> Not all valid trees for the parser are valid trees for the document.
> Only the tree that is minimal among those describing well the document
> should be considered valid. The others need cleaning.

That definition seems quite fuzzy to me... To make it useful you would
have to define clearly what is your ordering relation and how you
define "describing well".

Actually I am trying to figure out useful levels of document
normalization for my conversion needs. I would welcome your reflexion.


> > > > The fact that you can embed a table in another table is a feature. The
> > > > fact that you can make a table of a table (with only that) is bad.
> > > 
> > > As I illustrated above: no.
> > > Also, when programming style files or when doing complex operations
> > > on documents, it may sometimes be useful to be more permissive.
> > > Make a table of a table (with only that) is usually allowed
> > > in DTD's (like xhtml). One should be able to construct and edit
> > > all valid texts. Nevertheless, the editor may try to make it harder
> > > for you to construct seemingly (psychologically) incorrect texts.
> > 
> > That is almost my point when I talk of heuristically correct documents
> > and of the "document subset" of the typesetting language.
> 
> I guess your "document subset" is related to that "minimal tree
> representing the document" I was talking about above.

Not quite. I am trying to formalize things at the moment. I will start
another threads sometime soon to discuss these issues.

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