Received: by nummer-3.proteosys id <01C19443.99BAEA7C@nummer-3.proteosys>; Thu, 3 Jan 2002 11:44:20 +0100 Return-Path: <@vm.gmd.de:LATEX-L@DHDURZ1.BITNET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19443.99BAEA7C" 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]) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: Re: Validating LaTeX output Date: Sat, 1 Feb 1992 07:48:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Don Hosek" Sender: "LaTeX-L Mailing list" To: "Rainer M. Schoepf" Reply-To: "LaTeX-L Mailing list" Status: R X-Status: X-Keywords: X-UID: 568 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19443.99BAEA7C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm not sure what's desired regarding validating LaTeX output. A trip-style output test seems wholely unnecessary. If my TeX passed trip and I have the same files as you then my output will be the same (within defined limits). If my files are different than yours than obviously my output will be different. What are we trying to validate? Answer that question and the answer to how to do it will be simplified. Do we simply care that the files are uncorrupted? Well then as long as we include the character table at the beginning we're fine (longest-line checking can be done by placing a line at the beginning of the file which will contain text the length of the longest line which we can check for truncation/wrapping). Are we trying to see that our TeX is working correctly? Trip should pick up most problems and those it doesn't it should. Why are we even concerned about that issue. Are we tring to see if a new style file handles everything it should? Then what we need to do is give it a file (or set of files) for its class of documents that check to see if all features are correctly implemented. e.g., we would have one test file that could test both article.sty and ltugboat.sty. Looking at DVItype output in this case is useless. -dh Don Hosek dhosek@ymir.claremont.edu Quixote Digital Typography 714-621-1291 ------_=_NextPart_001_01C19443.99BAEA7C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Validating LaTeX output

I'm not sure what's desired regarding validating LaTeX = output. A
trip-style output test seems wholely unnecessary. If = my TeX
passed trip and I have the same files as you then my = output will
be the same (within defined limits). If my files are = different
than yours than obviously my output will be = different.

What are we trying to validate? Answer that question = and the
answer to how to do it will be simplified. Do we = simply care that
the files are uncorrupted? Well then as long as we = include the
character table at the beginning we're fine = (longest-line
checking can be done by placing a line at the = beginning of the
file which will contain text the length of the = longest line which
we can check for truncation/wrapping).

Are we trying to see that our TeX is working = correctly? Trip
should pick up most problems and those it doesn't it = should. Why
are we even concerned about that issue.

Are we tring to see if a new style file handles = everything it
should? Then what we need to do is give it a file (or = set of
files) for its class of documents that check to see = if all
features are correctly implemented. e.g., we would = have one test
file that could test both article.sty and = ltugboat.sty. Looking
at DVItype output in this case is useless.

-dh

Don Hosek
dhosek@ymir.claremont.edu
Quixote Digital Typography
714-621-1291



------_=_NextPart_001_01C19443.99BAEA7C--