Received: by nummer-3.proteosys id <01C19443.991BFBBC@nummer-3.proteosys>; Thu, 3 Jan 2002 11:44:19 +0100 In-Reply-To: <9201301637.AA27302@danpost2.uni-c.dk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19443.991BFBBC" Return-Path: <@vm.gmd.de:LATEX-L@DHDURZ1.BITNET> X-MimeOLE: Produced By Microsoft Exchange V6.5 x-vm-v5-data: ([nil nil nil nil nil nil nil nil nil][nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil]) Content-class: urn:content-classes:message Subject: Validating LaTeX output Date: Thu, 30 Jan 1992 18:07:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Kresten Krab Thorup" Sender: "LaTeX-L Mailing list" To: "Rainer M. Schoepf" Reply-To: "LaTeX-L Mailing list" Status: R X-Status: X-Keywords: X-UID: 557 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19443.991BFBBC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rainer Schoepf writes: >With the trip and trap tests Don Knuth has given us a tool to validate >TeX and Metafont. But up to now there is no similar tool to validate >LaTeX (nor any other macro package). > >One might argue that one could use the same strategy (i.e. producing a >dvi file and using dvitype to check its contents) but there are some >problems: > >1. It is difficult to see what the correct behaviour is. > > With TeX the test checks the working of the internals of the > program. With LaTeX you have to check whether the output > corresponds to the input and to the desired design. This is much > more complicated. I think this is the whole point. What kind of tests would you like to be able to make, really? A usefull usage for such a test document would be to test how overloaded (user or anybody designed) functions/macros behave, like if I write a new \caption command, it need accepting an optional argument, and this should be placed correctly in the list of figures, and when I look at the output the caption is placed next to the figure etc. Some text next to this figure should then tell how it should be. >3. The output of dvitype slightly differs between different > implementations. This makes it almost unusable, except for > specialists. The purpose of `testing a LaTeX environment' is to make shure that it looks right. This is *subjective*, and cannot be tested by simple file comparison. A testsuit like this would indeed be usefull for writing new styles. The `kernel' of LaTeX must be supposed to be correct. LaTeX *is* LaTeX (in some version :-), and hence, the test should aim on catching errors when changing LaTeX somehow. I hope this may give you some ideas... /Kresten ------_=_NextPart_001_01C19443.991BFBBC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Validating LaTeX output

Rainer Schoepf writes:
>With the trip and trap tests Don Knuth has given = us a tool to validate
>TeX and Metafont. But up to now there is no = similar tool to validate
>LaTeX (nor any other macro package).
>
>One might argue that one could use the same = strategy (i.e. producing a
>dvi file and using dvitype to check its contents) = but there are some
>problems:
>
>1. It is difficult to see what the correct = behaviour is.
>
>   With TeX the test checks the working = of the internals of the
>   program. With LaTeX you have to = check whether the output
>   corresponds to the input and to the = desired design. This is much
>   more complicated.

I think this is the whole point.  What kind of = tests would you like to
be able to make, really?

A usefull usage for such a test document would be to = test how
overloaded (user or anybody designed) = functions/macros behave, like if
I write a new \caption command, it need accepting an = optional
argument, and this should be placed correctly in the = list of figures,
and when I look at the output the caption is placed = next to the figure
etc.  Some text next to this figure should then = tell how it should be.

>3. The output of dvitype slightly differs between = different
>   implementations. This makes it = almost unusable, except for
>   specialists.

The purpose of `testing a LaTeX environment' is to = make shure that it
looks right.  This is *subjective*, and cannot = be tested by simple file
comparison.

A testsuit like this would indeed be usefull for = writing new styles.
The `kernel' of LaTeX must be supposed to be correct. = LaTeX *is* LaTeX
(in some version :-), and hence, the test should aim = on catching
errors when changing LaTeX somehow.

I hope this may give you some ideas...

/Kresten

------_=_NextPart_001_01C19443.991BFBBC--