Conference vaxuum::document_ft

    I'd like an answer to that question as well.  I seem to recall reading
    somewhere that the numbers indicate a number of characters.  Kind
    of silly since we are using proportionally spaced fonts.  Might
    I suggest that the units be something we could measure with a ruler?
    That way, it should only take two passes to get table columns to
    be spaced perfectly.  The first pass would be a guess (like it is
    now), and then the user could lay a ruler on the printed output
    and figure out exactly what the numbers should be.
    
    -- Craig
     

    I believe the column width is measured in tenths of inches.  For example,
    a column width of 10 is one inch wide.  Can anyone verify this?

    It is a little more complex than that...
    
    The column width measurement is not a fixed unit: I believe it is a 
    relative length based on the font used for tables.  What's more, if TeX
    finds that there is not enough room for all of the columns at the
    width you specify, it automatically reduces the font size, thereby
    reducing the unit measurement and shrinking the column widths.
    
    So, the unit is set at *approximately* one character width. Obviously,
    if you have all uppercase letters, you won't fit as many on a line.
    But then measuring in inches or picas wouldn't help you there anyway.
    What DOCUMENT is doing is making the measurement generic. If you
    process the file with a doctype that uses a larger font for tables,
    the columns are made proportionally larger. 

    I can understand the desire to know what the units are. But personally
    I can put up with a little not-knowing to have DOCUMENT do the 
    extra work for me...

    Besides, if you run the table once, and see that a column needs to be 
    20% wider, you can increase the value by 20%. It doesn't matter what 
    the units are, does it?
    
    --Andrew

    
    The answer lies in history. I admit that it's not the best way to
    justify or explain an engineering decision, but it's what we have
    to live with for a while ...
    
    The earliest version of DOCUMENT supported only DSRPLUS output for
    the back end. In order to get tables even reasonably correct, it
    was necessary to require that the table setup information specify
    a character count (i.e. the maximum number of characters that would
    appear in a particular column).
    
    As work progressed on the TeX back end, we had (for quite a while)
    to continue to support the DSRPLUS back end. Therefore, the
    implementation of table support had to use the numbers that were
    based on the DSRPLUS monospaced output. Our TeX expert decided on
    an algorithm that would do a reasonable thing with this number in
    most cases: the number specified is multiplied by a variable called 
    \tblcolwdunit. The value of \tblcolwdunit is by default .7em,
    which is about right when the table font is 9pt. This can be varied
    in different doctypes to get slightly different results.
    
    That answers what the numbers mean and why they are the way they
    are. It doesn't answer the question of how we explain to users what
    they are, and I believe we say something to the effect of
    'the numbers provide information about the approximately widths
    or proportions of the table columns.' Although I am prejudiced,
    I also happen to believe that using 'approximate' and 'proportional'
    is accurate. Even if the table column values took real dimension
    values (i.e. 3pc), a table still probably won't come out correct
    the first time. And, as a document progresses through its life
    cycle, the table units will have to be adjusted as text is inserted
    in particular columns. You just start out with a best guess as to
    the type of information in each column and specify values that
    weigh the proportions. A list of keywords and explanations in which
    the keywords are usually less than 10 characters? use 10. etc.
                                            
    As a said at the start, it is something we have to live with for
    a while, but it's certainly worth looking at for future modification.
    
    -patti anklam

    I agree that one can "tune" the table by repeatedly adjusting the
    column widths and looking at the resulting document.  However, that's
    a pain in the neck.  I think the numbers should be somehow meaninful
    so that users can at least make a reasonable first estimate of desired
    widths.
    
    I vote for percentage of the text width.  If the values in the
    parameters for <TABLE_SETUP> total more than 100, an error gets
    issued.  Otherwise, the rightmost column is the remaining width
    after the other columns have been allocated.

    I agree with .5. Put percentage on the wish list. Asking for number
    of characters is like asking how many characters are in a line.
    While I'm at it, what determines the whitespace between columns?
    Seems to me it sometimes gets ignored, and text from a preceding
    column will overwrite the next column. I think this whitespace should
    also be some very minimum value like the width of a number character.

This is hands-down a case where WYSIWYG beats markup.  I have made perhaps 10
or more passes over the document and *still* cannot get either the columns
widths correct.  I either end up with unreadable 6- or 8-point type or I get
TeX errors about lines being too long.  I dislike warning messages. To put up
with them is to endure insults without recourse.  I can just hear the little
man in the CPU taunting "Nyah-nyah, the goose can't layout a table!" 
       
Whatever units or method you settle on for V1 has to be made explicit so users
can predict the outcome reasonably quickly.  The word 'approximate' without any
means of measure is only accurate in Newspeak (11th edition). 
       
Some suggestions: 
   
(1) The percentage idea is good.  (1a) Require all columns to be specified.  If
they total to over 100% then either shrink the font or consider it a wide table
(requiring two adjacently bound pages).  This would also allow for less than
full page width tables (which can then be centered or placed flush left).  (1b)
Continue to default the last column to the remaining percentage left (an error
if not enough). 
   
(2) Make the dimensional units relative.  On indicates the relative sizes of
each column to the other columns.  Thus the narrowest column would be size 1, a
column twice its width would be size 2 and so on. 

(3) My most outrageous suggestion: Make a table editor procedure in TPU, then
it could be integrated into LSEDIT and invoked by command or keystroke. It
would have to know your doctype so it could look up the fonts and sizes. Then
it would provide a crude representational visual layout (that's the trickier
part). 

I like number 2 above suggestion best.  It means I can change doctypes and not
have to fiddle with my table column sizes all over again. 
   
Several ideas should be experimented with before committing with V1's release.
Perhaps a hastily put together human factors study would be appropriate to
decide what algorithm you should use to implement a markup-style table. 

A wish:  Allow an option to disable the resizing of the typeface if things
don't fit.  I would prefer word wrap instead for this table. 
   
\bob
/\peterson

p.s.
   While I'm on the subject, the notion of the <ALIGN_CHAR> is based on the
   same faulty idea of monospaced fonts.  When I first read this I was
   expecting that DOCUMENT would take the alignment character as a
   non-printing, non-spacing marker.  It would then make sure all markers like
   it above and below in the table (or list) would line up vertically. Very
   nice for printing tables of dollars and cents: 
       
	<ALIGN_CHAR>(^)
   	<TABLE_ROW>(VS215-A2\VAXstation II\$4,160.^00)
   	<TABLE_ROW>(MS630-CA\8-MB memory card\$530.^00)
\b

    Re .7-
    
    A vote here for #2. DSRplus's TABLE utitlity offered a way of handling
    proportional specifications. That, in turn, allowed support for
    DSRplus and TMS output.
    
    There's no question in my mind but that WYSIWYG systems walk all over
    markup when handling tables. A TPU table editor might be able to
    fashioned from the rectangular cut-and-paste features of EVEplus. For
    simple tables it could probably do alright. Pretty soon, though, as
    folks start nesting lists, other tables, etc., we'd reach the limits of
    a monospaced, non-structured editor.
    
    kh

    In order for the WYSIWYG editor to be able to help in this case,
    won't it have to have the same fonts in the same point sizes,
    follow the same hyphenate and wrap rules, do the same kerning,
    leading, etc?
    
    If it doesn't then it still isn't telling you what the paper
    output will look like, so won't it still be a question of
    "trying it one more time?"

.9  No, even if your product doesn't show correct fonts and sizes, you 
    don't need to guess at line endings.
        
    I started at Digital 3 months ago.  Before that I used XyWrite, a text
    processing product for IBM PCs.  XyWrite doesn't display different
    fonts and type sizes, but it does show correct line endings.
    
    
    XyWrite is an excellent product.  When DOCUMENT goes WYSIWYG, I
    recommend looking at XyWrite and incorporating many of its features. I
    should add that DOCUMENT, too, is a good product.  XyWrite could
    benefit from some of DOCUMENT's features, as well.

    >No, even if your product doesn't show correct fonts and sizes, you 
    >don't need to guess at line endings.
    
    That works fine when you're only concerned with one break per line,
    and don't care how wide the line appears on the screen.
    
    In multicolumn tables you are also concerned with horizontal
    formatting -- showing the relationship of adjacent columns on the
    same line -- and any representations that differ from final output 
    mean you still have to play with it iteratively.  (That is NOT to say 
    that you wouldn't benefit from some fairly close approximations,
    just that you couldn't get it completely right until the editor
    and text formatter were singing off the same sheet of music.)
    
    

    And there's the perennial problem of being too specific in a generic
    document.
    
    The table you prepared so carefully for output on your (LN03, LN01,
    LPS40, terminal, lineprinter) may look just awful when Graphic Services
    prints it on their (APS �5, Linotronic 300) and somebody else processes
    it for online documentation using (VOILA, VTX, whatever).
    
    DISCLAIMER: I'm not saying there is no place for WYSIWYG -- just
    that, in the Digital publications environment, the issue is MUCH
    more complex than simply "How do I get my draft to look good."
    (Of course, if you are the one producing the final copy, WYSIWYG
    can be great.)
    
    Mark

Re: .6

The question was lost, and I too am interested in the answer:

What determines the amount of white space between columns?  Does the 
number you specify for each column include white space?  Or is actual 
text all I need to worry about?

RE: .7

<ALIGN_CHAR> and <ALIGN_AFTER> don't work as I would expect them to.  
I haven't yet figured out how to use these tags to get numbers to align 
on decimal points, for example; assuming there is another method than
coding hard spaces thus:  ###23.00\##323.34\4456.2345
                          43236.00\#5555.553\2454.00

Seems to me that I should be able to code 23.00\323.34\4456.2345 etc.
and have them all line up on the decimal point:

           23.00    323.34   4456.2345
        43236.00   5555.553  2454.00

Or maybe <align_char> and <align_after> work exactly as they should, and 
what I want is a wishlist item?

Or maybe I'm using the tags incorrectly?


Rose

.11 XyWrite handles multiple columns (of varying length) and multiple
    point sizes.  The best example I can give is that of a three-column,
    troubleshooting table where the first column usually contains a one-line
    description of the problem, the second column contains a few one-line
    descriptions of possible causes, and the third column contains lengthy
    explanations for each entry in the second column. 

    Simply put, there is *no* guesswork involved if you have to set
    up a table.  (Column widths are measured in tenths of inches.)
    
    I have the feeling that this isn't the proper place for this
    discussion.  If anyone has a question about the WYSIWYG capability
    of XyWrite, feel free to send me mail.
    
    Eric

    >I haven't yet figured out how to use these tags to get numbers to align 
    >on decimal points, for example; assuming there is another method than
    >coding hard spaces thus:  ###23.00\##323.34\4456.2345
    >                          43236.00\#5555.553\2454.00

    I assume you ought to be able to put phantom characters AFTER the
    decimal point, too, to align numbers with different decimal places:
    			###23.00\##323.34#\4456.2345
                        43236.00\#5555.553\2454.00##

This one keeps getting lost, buried among other questions.  Back to .6 and .13:

What determines the white space between columns?


Rose

Here's a good example of column widths that resulted in itty-bitty type.  Only
after half-a dozen tries at increasing and decreasing column widths was the
"normal" font achieved.  It's not real clear that you can increase a font size
by decreasing the column width.  In fact, the first time you look at
an itty-bitty font you think "Oh, DOCUMENT wants more space."  But my brief
experience with 06 has shown me that DOCUMENT really wants *less* space, 
specified in the <table-setup>.

As noted above, the table below results in incredibly small type (processed with
Soft.Spec).  Decreasing the column widths by 5 resulted in a pleasing table.


<table>(Tools Requirements\tools_table)
<table_attributes>(multipage\wide)
<table_setup>(6\30\5\10\10\10)
<table_heads>(Tool\Refer\Prior\Group\Source\DSRI)

<table_unit>
<table_unit_heads>(DBA Tools)
<table_row>()
<table_row>(Unload Copy\x.x\1\CX/ZK\DB2\yes)
<table_row>(Merge Copy\\1\CX/ZK\DB2\yes)
<table_row>(Journal and Log Inventory\\1\CX/ZK\DB2\no)
<table_row>(Load\\1\CX/ZK\DB2\yes)
<table_row>(Backup and Restore\\1\CX/ZK\DB2\no)
<table_row>(Database Reorganization\\1\CX/ZK\DB2\no)
<table_row>(Database Definition\\1\CX/ZK\Ingress\yes)
<table_row>(Roll Forward and Roll Back\\1\CX/ZK\Ingress\no)
<table_row>(Journal Analyzer\\1\CX/ZK\Ingress\no)
<table_row>(Display Database Information\\1\CX/ZK\Ingress\yes)
<table_row>(Checkpoint\\1\CX/ZK\Ingress\no)
<table_row>(Convert\\1\CX/ZK\Ingress\no)
<table_row>(Performance Tuning\\1\CX/ZK\Oracle\yes)
<table_row>(Triggers\\1\CX/ZK\Oracle\no)
<table_row>(Run-time Control\\1\CX/ZK\Oracle\no)
<table_row>(Log Analyzer\\1\CX/ZK\Ingress\no)
<table_row>(Database Audit\\1\CX/ZK\DBMS\no)
<table_row>(Database Fix\\1\CX/ZK\IDMS\no)
<table_row>(Dump\\1\CX/ZK\IDMS\no)
<table_row>(Archive\\1\CX/ZK\DBMS\yes)
<table_row>(System Installation and Upgrade\\1\CX/ZK\IDMS\no)
<table_row>(Database Analyzer\\1\CX/ZK\DBMS\no)
<table_row>(Data Migration and Placement\\2\CX/ZK\IDMS\no)
<table_row>(Calculate Database Key\\2\CX/ZK\DBMS\no)
<table_row>(Schema Mapper\\2\ZK\DBMS\no)
<endtable_unit>

<table_unit>
<table_row>()
<table_unit_heads>(Application Tools)
<table_row>()
<table_row>(Debug\\1\ZK\Oracle\yes)
<table_row>(Checkpoint and Restart\\1\ZK\Ingress\no)
<table_row>(Query\\1\Current\Ingress\no)
<table_row>(Report Writer\\2\Current\Ingress\no)
<table_row>(Forms\\2\Current\IDMS\no)
<table_row>(Graphics\\2\Current\Ingress\no)
<table_row>(Application Generator\\2\Current\Ingress\no)
<table_row>(Batch Transaction Simulator\\2\Consultant\DB2\no)
<table_row>(Test Data and Database Generator\\2\Consultant\DB2\no)
<table_row>(Application Modeling\\3\Consultant\DB2\yes)
<endtable_unit>

<table_unit>
<table_row>()
<table_unit_heads>(Other Tools)
<table_row>()
<table_row>(Security\\1\CX/ZK\Oracle\yes)
<table_row>(Performance Analysis\\1\CX/ZK\DBA\yes)
<table_row>(Application Analysis\\1\CX/ZK\DBA\no)
<table_row>(Data Dictionary\\1\ZK\Oracle\yes)
<table_row>(Database Design Aid\\2\CX/ZK\DBA\no)
<table_row>(Capacity Planner\\2\CX/ZK\DBA\no)
<table_row>(Query-By-Example\\3\Consultant\IDMS\no)
<table_row>(On-line English\\3\Consultant\IDMS\no)
<endtable_unit>                  

<endtable>
                          

    
    I'm not sure how best to provide diagnostic information. The switch
    to a smaller point size was intended as an aid (avoiding those
    awful \parsetablecolwidths leaves no room for last column messages
    from TeX.) The size of the table is set from the <table_setup> values.
    If the sum, after the alorithm is applied, means that the table
    is too wide for the page, the smaller point size is selected. So,
    to make a smaller total width, you lower the numbers, no?
    
    

    I have a similar problem with the use of smaller typefaces in tables.
    Here is a typical table for one of my documents.  Column 1 contains
    tags and Column 2 contains text:    
        
     <TABLE>(LSEVE Template Tags\template_tab)                 
     <TABLE_SETUP>(2\24)                                       
     <TABLE_HEADS>(Template\Key Sequence)                      
     <TABLE_ROW>(<tag>(FRONTMATTER) Template\GOLD/{)           
     <TABLE_ROW>(<tag>(MEMO) Template\GOLD/')                  
     <TABLE_ROW>(<tag>(PROFILE) Template\GOLD/;)               
     <TABLE_ROW>(<tag>(QUALIFIER) Subtemplate\GOLD/INSERT HERE)
     <TABLE_ROW>(<TAG>(SUBCOMMAND) Subtemplate\GOLD/REMOVE)    
     <ENDTABLE>                                                
    
    The tags get printed in tiny boldface type while the regular text next
    to it gets printed in regular size type (using both the GENERAL and
    SOFTWARE.REFERENCE doctypes).   It looks a little silly. However, when
    I use tags in regular text in the manual, they get printed in
    regular size boldface type which is what I'd also like to see in the
    tables.  Is there an explanation for this behavior?  Or any way
    to get around it?
    
    Thanks.
    
    
    	-Helen

    RE .17,.18,.19

    I'd like to revive this issue.  I'm curious as to whether it was addressed
    in BL08 or whether it has been dropped.  If you print out the table given
    in reply .19, for example, you'll see that the table columns don't even
    come close to being too wide for the page in the GENERAL doctype (which is
    what I'm using). However, the first column gets output in tiny type and the
    second in a regular-size font. Changing the arguments to the <table_setup>
    tag doesn't seem to make any difference either. 
    
    So, my question is this:  should I try an ugly workaround for the
    first column [ e.g.
    <TABLE_ROW>(<EMPHASIS>(<LITERAL>(<FRONTMATTER>)\BOLD) Template\GOLD/{) ]
    or will the BL08 output look different?  Is this the same issue as that
    raised in .17, or is this a different problem altogether?
    
    	-Helen 

                                         
    This is two distinct problems. 
    
    1. is the units in <table_setup> which will remain unchanged for
       V1.0
    
    2. is the output associated with the <tag> tag. In bl7, we modified
       this to output 'small caps', meaning to use the definition of
       'small caps' in whatever way the 'current font' specifies them.
       In tables, in the SOFTWARE.REF style, the 9-point sans serif
       is the main font. The small cap font is set to 6-point (since
       we have no 7-pt font, the choice was between 8 and 6). 
    
       - I have modified (but this won't be in the update) the <tag>
         tag's output so that the font used for tags can be more closely
         controlled.
       - In the interim, it should be possible to modify a local DTP
         file's \tablefontspecs to include something like
    
         \def\sc{\eightss}
    
         that will switch it to 8 points.

    Thanks, Patti.  Will give it a try.    -hkc