Conference vaxuum::document_ft

    TeX doesn't know about the SDML (GNC) source file's line numbers.
    Are you willing to look at the TEX file?
    Are paying customers willing to look at the TeX file?

    Pointers to the line numbers in the TeX file would be okay. A display
    of the offending word or phrase that went over the edge would be
    even better.
    
    Are paying customers will to thrash their way through TeX? I doubt
    it. Am I? You bet. Not only will I wander through TeX, but I'll
    also live in a house where there are teenagers.
    
    kh 

    Another vote for at least displaying the line that causes the problem.
    
    I'm not particularly impressed by getting a line number in the TeX
    file.  (After all, DOCUMENT is supposed to let us pretend TeX isn't
    there, isn't it?  If not, why don't we just use TeX directly and
    save all this bother?)  However, if it's a line number in the TeX
    file or nothing, it's probably better than nothing.

    
    I guess I don't see the distinction. If it tells you what page,
    then you can see from the output what's too long. The line number
    in the TeX file won't necessarily be the right line (i.e. TeX may
    be on a line containing the last word in a paragraph when it
    discovers that an output line 4 lines back was too long....)
    

    Let me suggest a technique for passing in the line numbers: simply
    output a special \xxxxx TEX command with one or more arguments
    detailing line number, file name, etc for each line readin during
    PASS 2.  Then adapt the error reporting mechanisms of TEX to use
    this data to pass back more info to the user.
    
    I can believe that administrators and others that will be playing
    around with new document styles will be reading .LIS files alot
    and could use all the help they can get figuring out exactly where
    things are going wrong.
    
    This is sort of like the way BASIC programs signal line numbers
    to their error handling code.
    
    Jack

    That's the way to do it, but it would involve a lot of changes.
    
    Currently the tag translator is trying to operate as a fairly
    general macro processor so it just reacts to TAGs in the source
    and passes everything else on to the output.  So the only
    intelligence at tag translator time that knows that the destination
    is TeX, rather than Pascal, RDB, the Message Utility, the HELP
    file, etc, is the actual tag definitions.  But the tag definitions
    don't see changes in the input files and lines as they occur, only
    as the next tag is found.  For example, if you <include> some
    pure text into your GNC file (no tags in the included file) no
    SDML tag will get executed and no TeX-knowledgeable code will
    know enough to output some \xxxx macro that says "here is a filename"
    and another \xxxx macro that says "here is line 1", etc.  And at
    the end of the included file, no SDML knowledgeable code will be
    triggered to output the \xxxx macro that says "Hey, EOF on that
    one and we're dropping back to the earlier file."  When this 
    block of pure text gets to TeX, however, it may have something
    in it that will trigger a TeX error...
    
    So, that means that the tag translator itself will probably have
    to be told to go into "TeX output mode" and the tag translator
    will have to have the smarts to pass on in the output the necessary
    information to tell TeX about the line numbers and file names of
    the source file to the tag translator.
    
    That's what we would have to do to get the info to TeX.
    
    Then, TeX would need to set up some line/file data structures to stash this
    stuff away as it came in, with links to the actual text and
    formatting macros.  SO when it found an error it would trace back
    into the line/file data structure in order to know how to report
    the location of the error.  Once it had output a page it would
    flush all the line/file data that it had for that page and start
    fresh on the next page.
    
    All of this is do-able.  But it will have to be a wishlist item
    for now.
         

    I'm confused. I've been ignoring this whole discussion on line too
    long warnings, because I thought it was informational and indicated
    that TeX made some adjustment. I see the warnings a lot, but never
    see any too long lines in the output. I thought this was all a function
    of ragged-right vs justified and hyphenation penalties, etc.
    Admittedly, most of the excessive lengths are usually too small
    to be easily noticed, but some (e.g., 94.+ points) would be obvious
    if the line is output that way. The next question is, supposing
    I knew what the offending line number is. What do I do about it?
    Rewrite it? Add a carriage return? Force hyphenation? I must be
    missing the point of this whole discussion.
    
    Joe

I get LINE-TOO-LONG messages in every file I process.  In my case, they
have been strictly informational 100% of the time.  I've yet to
encounter output that I had to modify in any way.  However, I use the
SOFT.SPEC doctype almost exclusively; it has a ragged edge which may
be part of the reason I've never had to make adjustments--or it could
be just luck.  As an earlier note stated, more or less, "adjustments are 
in the eye of the beholder."

I have noticed that processing a file for terminal output will generate
LINE-TOO-LONGs *significantly* more times than processing for other 
output; but again, no adjustments have been necessary.

Has anyone out there *actually* had to make adjustments as a result of
this error?  If so, please explain the circumstances (doctype, etc.).
If no one has, I think we can all be satisfied that the error is merely
irritating. 

Rose

    Several of the example tables in Step-By-Step: Writing with VAX
    DOCUMENT result in line to long errors. For example, the example
    on page 3-6 gets this error and the second column overwrites the
    thrid column (very strange, since TeX could move the last word
    to the next line to solve the problem). In fact, trying to
    increase the size of the second column results in TeX adding
    another word to the first line, still overwriting the next column!
    
    This example is processed with the MANUAL doctype for LN03 output.
    
    --Andrew

    I think customers are likely to want to know the context in which
    the LINE TOO LONG error happened, especially if they are translating
    an existing document (as I am) and get so many of the !@#$!@#$ things
    that DOCUMENT doesn't generate output for them to see.
    As someone suggested in an earlier reply, surrounding text would
    be great.  TeX source line numbers would be acceptable.