Conference vaxuum::document_ft

    
    \: is defined to be an \hbox (to avoid line breaks at the --).
    You can take it out, but don't be surprised if you get RT--
    11.

    Is there any other way around the problem?  Here's an example of
    what happens:
    
    Table 1: This Is A Title
    --------------------------------------------------------------------
    Argument	Description
    --------------------------------------------------------------------
    One		Here is the first paragraph of the descriptive text
    		about the first argument.  The second paragraph of
    		the descriptive text begins with "RT-11".
    
    		RT-11
    		begins the second paragraph, and DOCUMENT throws in
    		a totally unexpected line break right after it.
    
    Two		Now talk about the second argument, and so forth.
    
    -------------------------------------------------------------
    
    
    	

    Why not just remove the entire entry from TAG$$LOCAL_STRINGS?
    
    Lee

    re -.1
    
    Nah. I want RT-11 to be translated to RT--11. Also, I would prefer
    that RT--1 not be broken. So I would like to understand why that
    \hbox is interacting with <p> to cause the undesired line break.
    
    Marty

    
    There is a bug. There's nothing special about RT-11, only that
    you use in the following context:
    
    <table_row>( ....<p>RT-11 ...more text)
    
    Following the <P>, the text formatter is in 'vertical mode' and
    needs some text to get it started off in a paragraph. But it sees
    the \hbox for RT-11 and writes it out then goes off looking for
    another \hbox to tack underneath it. The same thing would happen
    if you said
    
    <table_row>( ...<p><keep>(anything) more text...)
    
    There isn't any easy workaround that I can think of. We will need
    to change the way we handle the <p> tag inside tables. 
    
    The amazing thing about this is that this bug has been there since
    probably Base Level 4 and maybe earlier, and this is the first time
    anyone's been bit. 
    
    patti
    

    .-1:
    
    Those are the kind of bugs we specialize in down here!
    
    Marty

    Here are some entries I have in tag$$local_strings BUT in some cases
    the product name, (when it falls at the end of a line) gets wrapped
    like this:
    
    BLah Blah Blah and so on and so forth when so and so does this DECnet/
    SNA stuff.
    
    This of course is unacceptable... What else can I do besides edit
    the .TEX file and add a ~ DECnet/~SNA...???
    
    thanks,
    Bette Jean 
    
    
    'DECNET{\slash}SNA'  'DECnet/SNA'            /* product name */
    'decnet{\slash}sna'  'DECnet/SNA'            /* product name */
    'decNET{\slash}SNA'  'DECnet/SNA'            /* product name */
    'DECNET{\slash}sna'  'DECnet/SNA'            /* product name */

    '\:{DECnet/SNA}'

    I thought the \: was to keep an en dash together or to tell tex
    NOT to hyphenate at that point... I don't know I'll give it a whirl.
    
    thanks Marty!
    Bette JEan

	Won't this work?:
        
        blah blah <keep>(DECnet/SNA)

    nope \: DOES NOT keep my product name DECnet/SNA together at the
    end of a line.  Yes, <keep>(DECnet/SNA) does BUT I thought the whole
    purpose of the TAG$$LOCAL_STRINGS was to prevent this kind of clean
    up!!!!  I will put this in a
    <define_symbol>(DECnet/SNA\<keep>(DECnet/SNA) ) and add it to my
    globaldefs file... It just seems like reading in the local_strings
    file would be more global and more efficient...
    
    sorry about the frustration...

    
    Can you let me look at your TAG$$LOCAL_STRINGS file ? I suspect
    that the \: isn't working because you are picking up the definition
    for {\slash} before your entry is translated. I just made the mistake
    myself in running a little test.
    
    patti