[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxuum::document_ft

Title:DOCUMENT T1.0
Notice:**New notesfile (DOCUMENT.NOTE) now available (see note 897)**
Moderator:CLOSET::ADLER
Created:Mon Feb 09 1987
Last Modified:Thu Oct 31 1991
Last Successful Update:Fri Jun 06 1997
Number of topics:897
Total number of notes:4397

561.0. "including files" by DELNI::COLELLO () Thu Jun 25 1987 18:42

    I have something strange happening with an included file.
    My source file has an <include> file that includes a table file
    (coded <table>(title\symbol name)
           <table_setup>(4\14\14\14)
           <table_row>
              .
              .
              .
           <endtable> 
    
    (not the <table_file> tag)
    
    When I process the table file alone no problem.  When I process
    it with s.h no problem.  (looks the same) When I process it with
    a local design, (as I did when processed alone) the columns overlap.
    Any ideas?
    
    thanks,
    Bette JEan 
T.RTitleUserPersonal
Name
DateLines
561.1Also seen the problemBUNSUP::LITTLETodd Little NJCD SWS 323-4475Thu Jun 25 1987 19:009
    I don't think it has anything to do with being "included".  I've
    seen a similar problem where columns overlap in some doctypes and
    not others.  I can't say whats causing it, but in my case, its always
    been the doctype that has wider margins, i.e. less horizontal space
    to set the table in.  Have you tried WIDE or MAXIMUM on the table
    attributes tag?  If the offending doctype has a gutter, one or both
    of those tags will allow DOCUMENT to set the table into the gutter.
    
    -tl
561.2Diff the doctypesCLOSET::SEGALFri Jun 26 1987 09:4411
    You might also check whether your local doctype makes modifications
    to \uchyph, typeface point size (larger the size, harder it is to
    format narrow columns), or any of the numerous hyphen parameters.
    If you've restricted double hyphens, club lines, etc., you could
    have left very little flexibility when things get tight. TeX does
    NOT permit letterspacing, so the only place to make adjustments
    is    between   the     words or with hyphenation. Most of this
    nasty stuff doesn't happen if you're using \raggedrightspacing for
    the document text.
    
    Lee
561.3uhmmmm DELNI::COLELLOFri Jun 26 1987 10:5615
    Your explaination makes a lot of sense, especially where I have
    justified text for my \normaltextfontspecs and \raggedright for
    tables. BUT why do I get 2 different outputs using the SAME design
    when 1 is processed by itself and the 2nd is processed as an included
    file. The <table_attribute>(wide) is set, but that just pushed it
    to the left margin instead of a \blockindent of 2pc...
    
    I've used the <line> to ensure correct output, but I just thought
    it was peculiar.
    
    Bette JEan  
    
    I do not have \uchyph set in my .dtp file and I don't want to start
    fooling around with hyphenation parameters... as I do not understand
    them and what they all do...
561.4use DIFFCLOSET::ANKLAMFri Jun 26 1987 12:145
    
    you could start to see what the difference is by running DIFF over
    the .TEX files. 
    
    
561.5no diffDELNI::COLELLOWed Jul 01 1987 15:0112
    There was absolutely no diff between the 2 .tex files --
    1. When processed by itself 
    2. When included into the source file, but the output was 
       extremely different.
       
    The way it handled column widths, is the difference. When processed
    alone it is much more readable, the columns do NOT overlap. When
    included into the source file, the columns and rows are formatted
    differently...
    
    
    
561.6change in context?VAXUUM::SEGALWed Jul 01 1987 18:297
    Does the table cross a page boundary? And if so, do you lose
    ragged right after that? You can't use (even though some older
    doctypes had this spec) raggedright tables with justified doctypes
    sucessfully. V1.0 will also contain this restriction, but the
    item is on the wishlist.
    
    Lee