| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 532.1 | use \setlpdesign | CLOSET::ANKLAM |  | Fri Jun 19 1987 17:21 | 13 | 
|  |     
    I think it's in the order in which things are done. The DESIGN file
    is read *before* the device-specific definition file which sets
    the destination \if statement. 
    
    However, there is a way to modify any design parameters for line,
    terminal, and mail output, and that is to add a definition of
    \setlpdesign to your DESIGN file. This macro is invoked by the
    line printer definition file to allow DESIGN files to override the
    default line-printer values.
    
    patti anklam
    
 | 
| 532.2 | But what about non-lp destinations? | 57609::LONG |  | Sat Jun 20 1987 11:07 | 16 | 
|  |     
    I may be all wet, but I thought the .STT files were executed during
    the TAG_TRANSLATION phase, and the .DESIGN elements brought in during
    the TEX_ phase.  For example, Greene can and does test for the use
    of <MOUNTED> and <LANDSCAPE> tags (used as qualifiers) in his
    .DESIGN file, and the value of these {TRUE|FALSE} are set in the
    .STT file processing.  If so, it seems to me that the destination
    tags could easily be made global variables.
                          
    While I could probably use \setlpdesign, and perhaps should, this
    approach does not satisfy the general case of needing to select
    particular design parameters based on destination.  For example,
    are there equivalent \set<device>design for POST, LN03, APS, etc.?
    
    Harold
    
 | 
| 532.3 | ok, on wishlist | CLOSET::ANKLAM |  | Sun Jun 21 1987 18:25 | 9 | 
|  |     
    I do see what you are getting at. We are looking at further
    extensive clean-up of the way we read in the TEX definition files
    (DESIGN and xxCHARS.TEX files) at V1.n. We should look at what
    you want. This would mean that the destination would have to
    be passed directly to the invocation of TEX, so it was read in
    before the DESIGN files. 
    
    -pa
 | 
| 532.4 | an insect in a tux? | 57609::LONG |  | Mon Jun 22 1987 15:25 | 14 | 
|  |     
    	It's not a wishlist item, it's a bug.  As far as I can tell,
    \iflp is never executed for any design.  For example, in the
    TEX$OVERHEADS.DESIGN, line 190 is \iflp {char111...  If I insert
    garbage after \iflp and select MAIL destination, TEX cheerfully
    processes the document and never complains about the junk I put
    there.  While I haven't exhaustively checked all destination
    devices, I suspect the other \if<device> conditionals aren't
    working either...
    
    	Comments?
    
    	Harold
    
 | 
| 532.5 | You both win | CLOSET::SEGAL |  | Mon Jun 22 1987 16:03 | 11 | 
|  |     re .1 and .4: both correct. The device characters file is read
    after the design file, and it's at that point that we set the
    destination device switch to TRUE. The problem here is that
    the device characters file neglected to test whether \bulletchar
    had been previously (in the DESIGN file) defined, and so the
    definition there simply replaced anything that preceded it.
    
    Fixed this for lineprinter (and related devices), plus
    \listhyphenchar, for V1.0.
    
    Thanks, Lee
 | 
| 532.6 | Another possibility | BUNSUP::LITTLE | Todd Little NJCD SWS 323-4475 | Tue Jun 23 1987 17:43 | 7 | 
|  |     Alternatively, you could place the required conditionalized TeX
    code inside a macro that doesn't get expanded until TeX actually
    starts processing the file.  This could be done by modifying some
    standard macro that you know will be invoked near the beginning
    of the run.
    
    -tl
 | 
| 532.7 | Re 532.5 & 532.6 | 57609::LONG |  | Tue Jun 23 1987 19:46 | 11 | 
|  |     
    Re 532.6:  I understand what you're saying, but don't know how to
    do it.  I think I'll have to wait for the internals document before
    trying anything that sneaky.
    
    Re 532.5:  Thanks for acknowledging the problem, Lee.  From your
    answer it wasn't clear to me if you were going to just fix the
    \bulletchar problem, or the more general one of making \if<device>
    tests globally available during .DESIGN processing.
                                                  
    Harold 
 | 
| 532.8 | possible alternate | CLOSET::ANKLAM |  | Tue Jun 23 1987 20:00 | 24 | 
|  |     
    I believe Lee fixed the bullet problem; the real cure (in a future
    release) will be to hand the information down to TeX startup from
    the command line. 
    
    Meanwhile, what Todd suggests isn't all that sneaky; we do it all
    the time.  For instance:
               
    \def\tablefontspecs{%
        \ninepointss
         \iflp\baselineskip=14pt\fi}
    
    Since \tablefontspecs is read each time a table gets started, the
    \iflptest is also made each time. This is in contrast to what you
    want, which would be
    
    \iflp
       \def\tablefontspecs{\ninepointss\baselineskip=14pt}
       ... other lp things
      \fi 
    
    or am I off base on this?
    
    -pa
 | 
| 532.9 | (a) & (b) help a lot! | 57609::LONG |  | Tue Jun 23 1987 20:22 | 12 | 
|  |     
    	Yep, we're in agreement on the issues.  I understand your examples,
    both (a) and (b);  (a) is what I found when I decoded the .STT files,
    (b) is what I wanted.  Ah well, that's why we have version numbers
    on our products...  Now that I understand how to use it thanks to
    your explanation, I can probably mung the EDUOVER design to properly
    handle lp's [but it won't look pretty, and feels wrong, but who's
    looking anyway?].  I just have to find a macro that's expanded at
    the right time.  Cheers.
    
    Harold
    
 |