Conference vaxuum::document_ft

    Re .0 -
    
>             The two words are considerably longer that the
>   defined column width and are all caps.
    
    That would appear to be the problem. Have you tried increasing the
    width of column three?
    
    I can't remember for certain, but I believe that all cap words are
    treated differently for hyphenation purposes. 

    Re .1 -
    
    Now that I think of it, this looks like a problem I encountered
    when using DECpage V2.0. The table definition passed to the text
    formatter included column widths defined as some number (characters,
    or some other unit of measurement?). Of course the number of actual
    characteres output in a column depends on the mix, or non mix, of
    lower and uppercase letters. In DECpage, a high percentage of caps
    expands more and when it exceedes the column boundry, the next column
    is pushed to the right as I recall. DOCUMENT seems to just keep
    on outputting characters and overwrites the next column.
    
    What I meant by "The two words are considerably longer than the
    defined column width" is that the total of the two words, not each
    word, was longer. It seems reasonable to me that the text formatter
    should simply output column characters based on the sort of undefined
    column width until it cannot output another full word and then wrap
    the text to the next line. I would even settle for acceptable
    hyphenation with wrap. Is the handling of cap letters an inherent
    problem with text formatters?
    
    I didn't try increasing the width of column three because that doesn't
    seem to be an acceptable solution to the problem.
    
    thanks again
    
    John
    

    I've experienced the same thing with the MANUAL.REFERENCE doctype.
    If the text in the column is all uppercase, one has to explicitly
    break the text with a <LINE> tag.  If the text is not all uppercase,
    DOCUMENT breaks the text across lines by itself (usually).

    I also have experienced this problem.  For some reason, words of
    all uppercase characters are not hyphenated in tables (that is,
    when using the MANUAL.REFERENCE doc type.  This means, long uppercase
    words go right across table column boundaries and overprint the
    first word of the next column... or print in the margin right to
    the edge of the page.  The column size seems to make no difference.
    

    
    I am looking at this. Lee is on vacation; she knows the mysteries
    of hyphenating uppercase words. There's also something we should
    be able to set in he table heading fonts that tell TeX to loosen
    up a little.
    
    

    Non-hyphenation of words beginning in uppercase was originally 
    a "design feature" of the MANUAL family. After wrestling with
    the very same problems described here, I removed the
    hyphenation restriction from the design file (it's in the
    update).
    
    If you have local doctypes built on the manual doctypes, you
    can override the hyphenation barrier by adding
    \uchyph=1 to your design (dtp) file after the \input for the 
    standard design file. 
    
    Lee 

Two of us here in Hudson have had a problem with table columns 
failing to wrap properly even when the words were not uppercase.
It seems to happen only on the first line of the output: all 
other lines did wrap.

Specifically, we were step-by-stepping through baselevel 7 and input
the "simple informal" table on page 3-6.  We got four or five
LINETOOLONG warnings and the last four characters of "peanuts,"
overprinted the text in column 3.  As I mentioned before, this was the
only failure to wrap.

Since the sample output on page 3-6 is correct, perhaps this is
a documentation error instead of a bug? I'm sure I typed in exactly
what was in the manual.

On second thought, I suspect that the sample input on page 3-6
did not actually produce the sample output. In my output, the
second entry wraps after "pumpkin" not "and" and the third entry
wraps after "kidney" not "and".

I managed to produce a table with no overprinting with 
     <TABLE_SETUP>(3\10\19)
instead of 
     <TABLE_SETUP>(3\10\15)
as specified in the manual, but I still got one LINETOOLONG 
warning and the table still didn't look like the one in the
manual.  My gutters seem smaller.

Could there be something wrong with our installation of BL07?  

Thanks,

Pilar.

    
    The problem with the table in the step-by-step is being handled;
    it was brought up in an earlier note.
    
    

I don't think that anyone has ever mentioned that the column-wrap 
problem appears to be related to doctype, uppercase letters or anything 
else aside.  At least that has been true in my experience.  

I have noticed, for example, that tables produced with soft.spec fail
have never failed to wrap.  However, tables produced with general almost
*always* fail to wrap.  Let me further qualify this with the note that
it does appear to be a problem with the first column only. 


Rose

    
    yes, we pretty much know that it's related to doctypes. It happens
    in the doctypes that have justified margins; the lack of wrapping
    occurs because the text formatter is trying to justify the text
    in the table columns and it think's its worse to have an overfull
    line than an underfull...
    
    

    re .10 	You're right -- I ran it again in LETTER doctype and
    		the columns wrapped perfectly.
    
    re .07	I spoke too soon.  If you run the step-by-step table
    		with <table_setup>(3\10\20) and MANUAL, you get a
    		too-long line in the *third* line of column 2.
    

    It isn't a real solution, but a kluge that I use when I have few
    enough columns to allow it is:
    
    I add an additional column between each of my other columns.  For
    example if I had a table that started out -- (4\15\10\12) I would make
    it (7\15\2\10\2\12\2).  Then I substitute a pair of "\\" for each "\"
    in my table.  This puts a bit of additional space between each of the
    original columns and gives somewhere for the text to go before it
    overwrites the next column. 
    
    It isn't applicable everywhere but sometimes it works.
    
    Dave P

    For local doctypes, you might want to try this or a variation. It
    will allow lots more line breaking.
    
    
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Tablefontspecs params
%
\def\tablefontspecs{\ninepoint\prelevskip=14pt\doublehyphendemerits=-1
\tolerance=4800\pretolerance=-1\hyphenpenalty=-9999\exhyphenpenalty=-9999
\linepenalty=-1\adjdemerits=-1\finalhyphendemerits=-1\hfuzz=8pt}
%
\def\tablesmallfontspecs{\eightpoint\ifaps\baselineskip=10pt\fi
\prelevskip=14pt\doublehyphendemerits=-1
\tolerance=4800\pretolerance=-1\hyphenpenalty=-9999\exhyphenpenalty=-9999
\linepenalty=-1\adjdemerits=-1\finalhyphendemerits=-1\hfuzz=8pt}

Well, much has been said about the wrapping problem in tables, but
I still managed to find some other "gotchas"; or rather my students did.

1. Columns won't wrap if the commas in a list of words are 
   followed by a space.  I guess DOCUMENT treats it as one 
   long word and gets confused about where to break it; just
   a guess from a user-level.  Anyway, there are apparently
   some users out there who might try something like the
   following:

  <table_row>(peanuts,cashews,macademias,pistachios\...)

   The above code fails, seemingly regardless of doctype.  I
   tried it in s.s, manual, report, soft.
   Someone commented that perhaps DOCUMENT should recognize
   commas as delimiters, at least outside of numerics.


2.  REPORT fails to wrap on occassion.  Sorry, I can't comment
    on whether it's related to uppercase letters or something
    else.  Is this a right-justified doctype?



Rose

By the way, does note .6 refer to BL8?

Note .14, by the other way, refers to BL8.


Rose

    
    yes, .6 applied to the update
    yes, REPORT is a justified doctype
    
    as for treating commas as delimiters -- we can't give DOCUMENT any
    such rules, it would be bound to cause problems somewhere else.
    
    

    I'm also seeing problems of this sort using BL8.
    
    The following two tables both have formatting problems when processed
    as SOFTWARE.SPECIFICATION to an LN03.
    
    <TABLE>(Forwarding Path Database Record\FORWARDING_PATH_RECORD)
    <TABLE_SETUP>(3\15\15)
    <TABLE_HEADS>(Element name\Size\Description)
    <TABLE_ROW>(ForwardingPath\array of AdjacencyDescriptor\Forwarding Path
    Adjacency Descriptor)
    <ENDTABLE>
    
    <TABLE>(Link State Database Record\LINK_STATE_RECORD)
    <TABLE_SETUP>(3\15\10)
    <TABLE_HEADS>(Element name\Size\Description)
    <TABLE_ROW>(NodeType\???\One of Level1Router, AttachedLevel2Router,
    UnattachedLevel2Router, LANpseudonode)
    <ENDTABLE>


    In the first table, "AdjacencyDescriptor" overlaps "Forwarding."
    In the second table, "UnattachedLevel2Router" overflows the line.
    
    Bill
    

    Given the problems I've been having recently with REPORT.TWOCOL, I
    decided to give REPORT a try.  I'm now having problems with a 9-column
    table which looked great in REPORT.TWOCOL but has wrapping/overlapping
    problems in REPORT.

    Like others have already reported, in REPORT format text in column 1
    is *sometimes* not being wrapped and is overlapping column 2 text.

    In addition, the column headers are being hyphenated strangely and most
    of the column headers overlap.  First, some samples of unnecessary
    hyphenation (which I assume result from REPORT being a justified
    design): 

	Program Pri-	Product Ver-
	ority		sion

    The overlapping problem is the result of REPORT's using a much larger
    font for column headings.

    -- Ward

 Tables still are good for a few surprizes. Not only do you experience the
 non-wrapping feature, but also the sizes of the columns as specified do
 not turn out the way they should.

 Using BL8, REPORT (hence justified) style, a table column definition as
 given below, turns out to be (13,10,remainder)pc in size instead of the
 specified 20,15,remainder.   The original (10,10,rest) turned out (7,7,rest).
 So...who's fooling who?

Theo


<TABLE>(PCAS in DPM termen)
<TABLE_ATTRIBUTES>(MULTIPAGE)
<TABLE_SETUP>(3\20\15)
<TABLE_HEADS>(DPM fase\deliverable\PCAS status)
<TABLE_ROW>(Phase 1 -- Design\Funct. Spec. goedgekeurd \Feitelijk afwezig -
    Func Spec. ASA als leidraad gebruikt)
<TABLE_ROW>( \ System Design Spec goedgekeurd   \ Feitelijk afwezig)
<TABLE_ROW>( \ Acceptance Test Spec goedgekeurd \ Afwezig)
<TABLE_ROW>( \ Project plan goedgekeurd         \ ?)
<TABLE_ROW>(Phase 2 -- Implementation, 2A: Detailed Design
            \  Detailed Design Spec goedgekeurd \ ?)
<TABLE_ROW>( \ Gebruikers documentatie opzet vastgelegd \ Afwezig)
<TABLE_ROW>( \ Acceptance Test Package goedgekeurd \ Afwezig)
<TABLE_ROW>(Phase 2 -- Implementation, 2B: Development
           \ Final baselevel gebouwd  \ programmatuur in 80% klaar stadium,
             technische documentatie deels aanwezig ))
<ENDTABLE>

 

Arguments to the <TABLE_SETUP> tag do not specify column widths in picas.
Rather, the units of measure are related to the character spacing associated
with the font used for tables. 
The best way to think of these units is as approximate character counts;
"approximate" because fine tuning is usually necessary.

--Brian

 That really is the weirdest way of measuring. Since you never know
 exactly what font will be used, how am I to know what width I need
 to specify. What's wrong with good old inches and centimeters
 (or picas, if we really want to play Home Publisher). I think we
 should seriously reconsider this funny way of measuring. Before you
 know it, the size of the titlepage fonts are related to the popularity
 of Oliver North - A4 will be too small.

Theo
 

    But if it is all on its way to the shredder, it won't matter...

RE: .21

Absolute measurements would destroy the doctype-independence of tables. One
alternative possibility would be to specify relative percentages for column
widths (e.g. for a three column table, the first column takes up 40% of the
horizontal space, the second column takes up 25%, and the third the remaining
35%). We'll be looking into that scheme (bearing in mind upward compatibility
issues which may arise).

--Brian