Conference vaxuum::document_ft

134.0. "TeX Problem" by DECWET::CUSTER () Fri Mar 20 1987 20:12

    Okay, I give up......TeX wins.  
    
    Here's the problem:  I have a manual with approximately 20 elements.
    Each individual element runs properly, without TeX error messages.
    However, when I ran the whole book through DOCUMENT, I got several
    messages "Error found by TeX."  The message in the LIS file would
    always say something like this: 
    
    "Error produced by \errpage.  I can't produce an error message.
    Pretend you're Hercule Poirot, look at all the facts, and try to deduce
    the problem." 
    
    Needless to say, I'm *not* Hercule Poirot, but I have been successful
    in getting rid of some of these errors, mostly by adding
    <xxxx_ATTRIBUTES> tags to long examples or tables.  In Chapter 13,
    however, I tried this "fix" and now I get the following:
    
   ###########################################################
%TEX-E-TEXERROR, Error found by TeX

%TEX-I-ONPAGE, on page [13-5]

%TEX-I-OUTFILENAME, 'disk$work3:[custer.convert]3222PRO.DVI_LN3'
\unpenalty' in vertical mode.
\tablecodexamplevskip ->\unpenalty 
                                   \unskip \skip 0=\asisblanklinevskip \rela...
l.220 \tablecodexamplevskip
                           
Sorry...I usually can't take things from the current page.
Perhaps you can make the output routine do it.
   ############################################################
    
    I have no idea what's going on, as the output when viewed through
    the previewer looks fine.  Anyone have any clues out there?
    
    And now to express a little frustration.  TeX error messages are
    extremely *unhelpful*.  My book takes approximately 30 minutes to
    run through DOCUMENT.  Since these errors only occur when I do a
    complete book run and not when I run individual chapters, I must
    run the whole book each time I try a new "fix."  I've spent the
    last 8 hours (and at least two days prior to this) trying to fix
    these TeX errors.  It just doesn't seem reasonable that TeX would
    refuse to create a DVI file when it produces errors that don't seem
    to affect the output one bit.
    
    I realize you guys didn't write TeX, but is there something that
    can be done?  Most writers I know are *not* programmers and don't
    have experience trying to debug something as complex as TeX code.
    Anyhow, any information would be appreciated.
    
    
    	-hkc
    
    

    p.s.  This new error message occurs on page [13-5] (or so TeX claims).
    This bug had never appeared before, but now it's appearing for page
    [13-5] and as far as I can tell, every page in the remainder of
    the book.  There are six more elements following Chapter 13.  So,
    apparently, the Chapter 13 bug is snowballing.  Sigh....

    
    Please mail me chapter 13. I need to take a look.
    
    As far as the messages go -- we have modified TeX so that in the
    real V1.0 version, all of the messages generated by TeX that may
    be seen by the user generate Informational level errors, so that processing
    will continue and you will get output. (The only warning level errors
    are those can only happen when some is modifying a DTP file.) Based
    on the informational message and the line number, you can look at
    your output and see what may be amiss. No one should ever see a
    message telling them to act like Hercule Poirot again!
    
    patti

                            Who is Hercule Poirot?

    Yes, he's a rather eccentric detective created by Agatha Christie (sp?)

    
    	-hkc

Nonsense.  He's a DEC customer software support employee.
 <_Jym_>

    WHo rides the Orient Express...

    
    well, I'm poirot'd out on this one. The file that causes distress
    during the book build is fine. The file before that, however, had
    a fair number of problems. The errors were diagnosed by the tag
    translator, and no output file was written for the bookbuild, HOWEVER:
    because the state of processing during a bookbuild is slightly
    different than in a normal file build, the output from the translator
    on the next file is badly corrupted. (counters and such not being
    reset to 0 when they ought to have been).
    
    (In this particular case, a table was terminated before the end
    of file A, so a code example in file B was processed *by the tag
    translator* as if it were in the middle of a table. During *text
    formatting* there was no table, ergo... )
    
    will fix this.