Conference vaxuum::document_ft

    TeX can be unbelievably fussy at times. What may look reasonably good
    to us is an error condition for TeX. This happens most often with
    tables and examples where TeX has much less latitude to compose its
    lines. It shouts as loudly for a 128 point error as for one of 3.32924
    points 

    I'm glad that TeX is so jealously guarding those points; we never know
    when we'll need one some day. 

    
    It's a warning, not an error. The warning messages replace the lines
    that used to go into the .LIS file (and in early base levels were
    printed on the terminal) namely, the 'overfull \hbox' messages.
    
    The are intended to alert you that a line doesn't exactly fit. In
    the case of 3.3 points, in a ragged-right document style, it won't
    matter. But when it's 40 or 50 points, then you should probably
    do something about it. The file should continue to process and will
    look okay except in the instance where it runs off the page. The
    message tells you that DOCUMENT knows that the text is too wide.
    
    patti
    

    Your 3.3 points is about 1/20 inch.

Preceding and ending tables and figures with <P> seemed to fix 
LINE-TOO-LONG in most instances, but a new problem has appeared as a 
result.  When DOCUMENT floats figures and tables it doesn't float 
surrounding <P>s, causing an extra space between paragraphs of text.  
Consider a file coded like this:


   <P>
   The quick brown fox jumped over the lazy sleeping dog.  
   See <REFERENCE>(brown_fox_fig).
   <P>
   The dog was sleeping because it was old and anemic.  If the
   dog's master would only give it liver and Geritol, the dog's anemia
   could probably be controlled. 
   <P>
   <FIGURE>(Brown Fox Jumping Over Dog\brown_fox_fig)
   <LINE_ART>

   +------------------------------------------------------+
   |                                                      |
   |        Imagine pix here                              |
   |                                                      |
   +------------------------------------------------------+

   <ENDLINE_ART>
   <ENDFIGURE>
   <P>
   Don't be a mean master, buy your old dog liver and Geritol.



DOCUMENT floats the figure, resulting in an extra space after the 
penultimate paragraph:


   The quick brown fox jumped over the lazy sleeping dog.  See Figure 1.

   Figure 1:  Brown Fox Jumping Over Dog

   +------------------------------------------------------+
   |                                                      |
   |                                                      |
   |                                                      |
   +------------------------------------------------------+

   The dog was sleeping because it was old and anemic.  If the
   dog's master would only give it liver and Geritol, the dog's anemia
   could probably be controlled. 


   Don't be a mean master, buy your old dog liver and Geritol.


I prefer to let DOCUMENT float figures wherever possible; it's been a 
rare occassion that I've had to force-keep a picture.   According to the 
documentation, tables are always floated if necessary.  No problem; but 
how do I make the extra <P> go away?  Is it a simple matter of more 
educated coding, or ????


Thanx

Rose

    I'm real curious to hear how <p>'s will fix the line-too-long errors.
    Fixing a problem by placing superfluous tags is very risky. (``Gee, I
    wonder what a <chapter> tag would do here.'') 
    
    No criticism of anyone's coding practices. Just that problems should be
    fixed by fixing the problem. 
    
    It'd be nice if we could tell TeX to keep quiet when the overrun is
    < 7 pts. or some doctype settable parameter.  
    
    kh

    Putting a <p> after <endmumbledy> is not a "fix", it
    is just following the rule that you "tag" everything.
    The <mumbledy> tag "ended" the paragraph that preceded it,
    and you should be inserting a tag after the <endmumbledy>
    to say what is coming next.
    
    Putting a <p> tag directly in front of <mumbledy> is
    misleading, since it announces some text that follows,
    but there is no text.  (It so  happens that the formatting
    effect of the <p> tag is to leave some vertical space in
    the printed output.  But you aren't supposed to be thinking
    about formatting, right?  I know, you DO end up thinking
    about formatting, especially when the output doesn't look
    like what you had in mind.)
    
    I think if  you are inserting <p> tags in order to get some
    desired formatting effect, you have to ask yourself 
    
      . do I really need this formatting effect?
      . if yes, what is it about the text that comes next that
        requires this special formatting and why don't I have a
        tag to properly label this special text?
    

    I'll second the wish for a threshold under which TEX does not report
    line too long errors.
    
    jack

RE: .5


Well, I've just tried reproducing the problem to get several more
LINE-TOO-LONGs then "fixing" them with <P>, but I'll be darned if I can 
do it.  I know I'm not crazy; I know it happened the way I described it 
and that (most) of the problem went away after I added <P> as described 
in earlier notes.  What can I say?  I did modify some tables in the 
file, and deleted the originals yesterday; that could be the reason.  Or 
maybe I am crazy...

I'm experimenting now to see what happens with <P> only just before
figures and tables, then again with <P> only just after them.  If
there's anything worth reporting, it will show up here. 


Thanx for the interest.


Rose

RE: .7

Determining what that threshold should be is not a straightforward task:
3 points might not be noticeable in the middle of a ragged right paragraph,
but it could be noticeable in a line of text which immediately follows a
page-wide rule.

--Brian

How about making it user-settable?

M

Hmm...it's possible to set the threshold on a doctype-wide basis, but
I'm not sure that would make life easier (because you'd want a higher
threshold for drafts than for final output, and you wouldn't want to switch
doctypes). For what it's worth, though, putting the following line into
your local DTP file will set the threshold to 1 pica (that is, DOCUMENT won't
issue a warning unless a line is more than 1 pica long):

\hfuzz=1pc

You can set the value as high (or low) as you want. We have it set to 0pt for
all standard doctypes.

--Brian

    
    I'm no TeX fan, but I have heard of a few ways to increase
    its tolerance for imperfection, in addition to \hfuzz.
    I assume DECTeX is just an extended copy, so it should support them,
    too.
                                                  
    TeX does have a notion of degree-of-badness, ranging from 0-10000.
    Check out the TeX Book for things like
     \tolerance
        The claim is that \tolerance=10000 is infinite tolerance, which
        "will never produce an overfull box, unless something strange
         occurs like an unhyphenatable word that is wider than the column
         itself."
     \hbadness                         
        \hbadness=500 sets the largest permissible horizontal badness
        to 500
     \hfuzz
        as mentioned in .11 "allows you to ignore boxes that are only
        slightly overfull."
     \raggedright
        can probably be used in a pinch
     I seem to remember something about a \sloppy, but couldn't find
        it.  Maybe that's in LaTeX.
    
    (I just ran into some of those annoying "line too long" messages,
     too.  DOCUMENT reached its limit on warnings, and wouldn't generate output.
     sigh.)
    

    Overfull line messages terminated the job? Nothing else in
    the listing file?

    Re: .13
    
    I've had jobs terminated just by a lot of overlong line messages,
    too. Alright, you can "force" DOCUMENT to continue by doing another
    pass with /NOTEX but it upsets my users...
    
    I've set \hfuzz to 2pc - keeps everyone happy!
    
    Gavin

    Yes, apparently it doesn't care about individual lines that are
    too long, but it has some threshold for total number of warnings
    of any kind that it will issue before stopping.  I believe I remember
    seeing that somewhere, and that the number is around thirty.
    This is *most* annoying when converting an existing document, since
    the early stages of that process almost certainly involve lots of
    warnings.
    
    I like the way DOCUMENT is set up, and would not propose introducing
    new doctypes to solve this problem.  Instead, I would like to see
    it accept a qualifier for all doctypes (I think this was suggested
    by someone else earlier):
        document/draft[=Draft_warning_string] ...
    which:
        * increases badness tolerance
        * puts the Draft_warning_string somewhere that doesn't interfere
          (much?) with the normal layout -- like at extreme top or bottom.
          That way anyone who gets a draft copy will be reminded that
          it's a draft.  If the draft warning is on every page, it helps
          ensure that anyone photocopying or extracting a portion of
          the document also receives that message.
        * provides a hook for tags representing notes to the author
          or similar annotation that gets stuffed someplace like the
          horizontal or vertical margins where they won't interfere
          (much) with the printed document, but will be very useful
          for the writer/proofreader/...
    
    This last point is something I would appreciate in some form,
    especially for OVERHEADS, where the annotation can be words/phrases
    serving as reminders about what to say about the slide as you present
    it.  A normal run of DOCUMENT would produce the un-annotated slides,
    ready to feed to the slide machine;
    but a run with /draft or whatever would produce the annotated version
    that the author/presentor can work from.
    ... sure would beat penciling in the annotation or replicating&annotating
    slides on-line ...
    
    Any chance of getting this kind of functionality?        
    I believe the customer satisfaction would warrant even a substantial
    development effort.  Anyone (dis)agree?

%TEX-W-LINETOOLONG warnings will *not* cause DOCUMENT to stop, no matter
how many of them you have. However, if you have a lot of them, it might
make it easier for you to overlook some other error which causes DOCUMENT
to stop. (The threshold of 30 warnings is for the Tag Translator in
DOCUMENT; LINETOOLONG warnings are generated by the Text Processor). If
anyone has an example that proves me wrong, send it in (maybe we'll offer
a "stump the devos" prize (-:).

Also, do not fool around with \tolerance. By doing so, you're essentially
circumventing the Text Processor's paragraph-making algorithm, and you may get
very                             loose                                  lines.

--Brian

    
    I was a little baffled by this, since I'd never seen TeX stop for
    warnings, but I fortunately had such a case yesterday (and gave
    Brian the LOG file, so *I* get the prize). The good news is that
    this is changed. LINETOOLONG is now an -I- level, as are all
    TeX messages that produced unhelpful messages.
    
    
    re: .15 and coments in 90: suggestion is noted.

      RE .17
    
    re line-too-long:
       Sorry I didn't reply with a log file, but I had already evolved
       the thing I was working on past that point.
    
    re draft,annotation requests:
       Thanks for your response (and I hope you decide to do some of
       that).  I was beginning to feel quite ignored...