Conference vaxuum::document_ft

    I agree that the margins for the MAIL destination are way too wide.  I
    think the margins used by Eve from within Notes (as I'm currently
    using) are just fine.  But this makes me wonder whether the margins for
    screen output need to be different than the margins for line printer
    output. 
    
    I disagree about right-justified text.  There is a long discussion on
    this subject in the TPU notes file, but the bottom line is that even
    though it may look prettier, it is harder to read (because the lack of
    a variable-width space character can cause very uneven spacing).
    This assertion is backed up by empirical evidence, although there
    might still be some individuals for whom it isn't true.
    
    DOCUMENT can do a much better job at right-justification than TPU,
    since DOCUMENT will hyphenate, whereas TPU won't.  Since I imagine many
    customers will expect it, then perhaps it should be provided as an
    option.  However, I would urge keeping the current behavior as the
    default, perhaps with a paragraph in the documentation citing current
    research and readability. 
    
       Gary

    I just submitted my "monthly" report using MEMO to my boss and he returned
    it to me with the comment:
    
I made several changes
o  re-filled  -- (for future - either use RUNOFF or you do the hand re-filling)

    Now, being a good corporate citizen is one thing and I'd really
    like to use this product, but if MEMOs aren't fixed, its back to
    RUNOFF.
    
    BobW
    

    Rose Johnston has given me a work-around to alleviate the pain I'm
    getting.  Thank you, Rose!
    
    Basically, the work-around is to tweak tex.  I'm not sure of the
    impact on other outputs, but if you <INCLUDE_TEX_FILE> a file that
    contains
    
\hsize43pc
\hoffset-1pc
    
    LPR class output looks more reasonable.
    
    As a workaround, it does the trick.  However, it is very ugly with
    a capital UG.
    
    'Hope this is really "fixed" soon.
    
    Thanks,
    BobW

    Just what are the LINE_PRINTER/TERMINAL/MAIL destinations for, anyway?
    
    You can look at the interaction of design and destination in two ways:
    
    	1. The design (doctype) completely describes the layout: vertical
    	   spacing, horizontal indents, places where emphasis is needed,
    	   etc., and the destination means "implement that design as
    	   faithfully as possible on the named device".
    
    	2. The design describes the formatting of the structural elements
    	   that make up the page, and the destination takes on a greater
    	   meaning: not just "do it that way on the target device",
    	   but "juggle some design variables to make it look 'best'
    	   on that device".
    
    Number 1 has been the DOCUMENT model thus far.
    
    I agree -- the memo you cited in the base note has an awful lot
    of wasted space and I, too, would like to see it formatted differently.
    Please be aware, however, that you are talking about a different
    DESIGN, not just a different destination.
    
    The monospaced destinations were originally supported for the purpose
    of providing readily-accessible drafts of documents.  As such, it
    is appropriate for them to approximate the white space inherent
    in the design.  Then, too, in some documents, that "extra" white
    space is taken up by change bars, deletion marks, wide tables and
    figures, etc.  (Change bars and deletion marks are not currently 
    implemented for monospaced output, but they are "on the list".)
    
    So the real beef is with the DESIGN of the memo, not with the
    DESTINATION.  And what looks good on the terminal may not be so
    hot on the LN03, with its extra density of text because of proportional
    spacing.
    
    I do not dispute the validity of your contention that your memo
    wastes an awful lot of space, and ought to have less white space
    on the lines.  I agree completely.  I just wish to bring out that 
    this is part of a much more complex set of tradeoffs, design decisions,
    and implementation challenges, and suggest that "Fix it now or I
    quit" simply is not going to get the job done right.
    
    Your needs and opinions are very important, however, and we urge 
    you all to keep speaking out.
    
    Thanks very much,
    Mark

    I would argue that there is no "design" parameter.  The parameters
    are doctype and destination.  These two, taken together, should
    determine the layout of the document.  The doctype specifies what
    the document is (eg, memo, letter, specification, etc.), and which
    tags are meaningful in that document. The destination, on the other
    hand,  specifies something about the capabilities of the target
    device.

    
    The monospaced output has always been a bit of a hybrid design/doctype.
    We have made it possible for local sites or individuals to
    modify line printer output by tweaking designs in two ways:
    
    1. you can create (as was mentioned in an earlier note) a local
       doctype that sets the page width, horizontal offset, and depth
       to something that pleases you
    
    2. Each doctype itself (including locals) can contain a definition
       that overrides what the line printer destination imposes, by
       defining \setlpdesign. This makes for only one design file to
       maintain, with the appropriate changes for monospaced output.
    
    Mark is correct, we need and appreciate feedback. We are, however,
    at a point in the development cycle where such changes are not
    very high priority (especially since we have provided ways to 
    modify and correct externally). Highest priority goes to things
    that cannot be easily overridden.
    
    patti