[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

532.0. "\if<device> test not global" by 57609::LONG () Fri Jun 19 1987 13:26

    
    	All .DESIGN document destination tests appear to fail outside of
    tags such as <FIGURE> and <TABLE>.  In trying to conditionalize
    EDUOVER for LINE|MAIL|TERMINAL output, I discovered that none of
    the destination tags were set to TRUE.  For example, the following
    code fails to crash TeX when placed at the beginning of the
    EDU$EDUOVER.DESIGN file and MAIL, LINE, or TERMINAL destinations
    are selected:
    
    \iflp
      \crash_tex %an obviously undefined element
    \fi
    
    	EDUOVER calls the following files: EDU$EDUOVER.STT,
    TAG$OVERHEADS.STT, and TAG$SDML_TAGS.STT.  In reviewing SDML_TAGS,
    it appears that device output is only tested within specific
    document elements and not as a global condition.
                                                
    	Note that this also imples that all device tests in the
    standard designs will fail if placed outside of a device-sensitive
    element.  While device condition testing is not discussed in
    the DOCUMENT manual set (including the Designer's guide),
    system administrators may imply from our use of such tags that
    they can be used for other purposes.
                                        
    	It also means that I cannot tweak EDUOVER to produce mailable
    drafts of overheads...
    
    
    
T.RTitleUserPersonal
Name
DateLines
532.1use \setlpdesignCLOSET::ANKLAMFri Jun 19 1987 18:2113
    
    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.2But what about non-lp destinations?57609::LONGSat Jun 20 1987 12:0716
    
    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.3ok, on wishlistCLOSET::ANKLAMSun Jun 21 1987 19:259
    
    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.4an insect in a tux?57609::LONGMon Jun 22 1987 16:2514
    
    	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.5You both winCLOSET::SEGALMon Jun 22 1987 17:0311
    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.6Another possibilityBUNSUP::LITTLETodd Little NJCD SWS 323-4475Tue Jun 23 1987 18:437
    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.7Re 532.5 & 532.657609::LONGTue Jun 23 1987 20:4611
    
    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.8possible alternateCLOSET::ANKLAMTue Jun 23 1987 21:0024
    
    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::LONGTue Jun 23 1987 21:2212
    
    	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