Conference vaxuum::document_ft

    Wow.  I don't know where to begin.  But since VAX DOCUMENT output
    is my job, I'll get in touch with you directly.
    
    Also:  I'll take this to the REGENT::LN03 notesfile.
    
    In the meantime, if any of you know about the communications problems
    inherent in this type of installation, please jump right in.
    
    Thanks,
    Mark

    Well, here go the usual questions, since what you want to do is
    should work, and does work in other locations.
    
    1)	Is the LAT connected LN03 set up properly, i.e., proper setting
    	of the switch pack for things like character length, flow control,
    	etc.?  Is the LN03 at the proper rev level (although I think
    	all LN03+'s are.)
    
    2)	Do you get any error light flashing on the LN03 while the job
    	is printing?  Does a summary sheet requested after the job show
     	any errors?
    
    3)	Are the queues set up identically between the working and
	non-working LN03's (other than the obvious difference of the
    	processor being LATSYM and not PRTSMB?)  Do other files, i.e. 
    	non DOCUMENT produced, print OK on the LAT connected printer?
    
    4)	Is the port on the terminal server set properly to recognize
    	such things as flow control, etc.?

    5)	How far away from the terminal server is the LAT connected printer,
    	i.e. how long and what type of cable is used to connect the
    	printer to the server?
    
    -tl

 Equally unwanted is the reverse: printing the manuals of BL7 or BL8
 I sometimes get 2 pages instead of one. Always when a piece of 
 graphics (like the apples) is printed, an unwanted <FF> is given.
 Using DVI2LN3 with LaTeX this problem is prevented using /E (for
 A4 sized paper), but how to do this in Document?

Theo

    
RE: .2

BUNSUP::LITTLE "Todd Little NJCD SWS 323-4475"       25 lines  30-MAY-1987 00:45
                            -< Standard questions >-
--------------------------------------------------------------------------------

    
>    1)	Is the LAT connected LN03 set up properly, i.e., proper setting
>    	of the switch pack for things like character length, flow control,
>    	etc.?  Is the LN03 at the proper rev level (although I think
>    	all LN03+'s are.)
 
    As far as I know, everything at the ln03 is set up the way it needs to 
be. We've been using the lat driven ln03 for 2 months now for various types
of printing applications, and using various font styles. The only difference
between the lat ln03 and the conventional ln03 is the memory available for
fonts (lat ln03)=28kb (conventional ln03)=283kb, and the lat ln03 is set
no-wrap.  Note: I've tried placing memory cartridges in the lat ln03, No-fix.
   
>    2)	Do you get any error light flashing on the LN03 while the job
>    	is printing?  Does a summary sheet requested after the job show
>     	any errors?

     The print process seems to be just fine, Font characters are loaded,
and the printing operation runs without error codes.    How do you get
this summary sheet you are referring to? 
    
>    3)	Are the queues set up identically between the working and
>	non-working LN03's (other than the obvious difference of the
>    	processor being LATSYM and not PRTSMB?)  Do other files, i.e. 
> ---   non DOCUMENT produced, print OK on the LAT connected printer? -- Yes.
    
Sh que/full (on lat ln03)= 
     Terminal queue LN03$TEMP, on LOKI::LTA1:, mounted form LN03
  /BASE_PRIORITY=5 /DEFAULT=(FLAG=ONE,FEED,FORM=LN03) Lowercase
  /OWNER=[GROUP_1,SYSTEM] /PROCESSOR=LATSYM /PROTECTION=(S:E,O:D,G:R,W:W)
  /RETAIN=ERROR /SEPARATE=(RESET=(ANSI$RESET))

 SET UP OF LTA1:  Set terp/perm/device=ln03/width=255/page=66/nowrap/ttsync-
               /nobroadcast/noform/noecho/hostsync LTA1:
               SET PROT=(S:RWLP,O,G,W) /DEVICE LTA1:
               SET DEVICE/SPOOLED LTA1:

Sh que/full (on conventional ln03)=
    Terminal queue HQ, on CARINA::TXB2:, mounted form LN03
  /BASE_PRIORITY=5 /DEFAULT=(FLAG=ONE,FORM=LN03) /NOENABLE_GENERIC Lowercase
  /OWNER=[Y4R,HAYAKAWA] /PROCESSOR=LATSYM /PROTECTION=(S:E,O:RWED,G:RW,W:W)
  /SEPARATE=(RESET=(ANSI$RESET))

>    4)	Is the port on the terminal server set properly to recognize
>    	such things as flow control, etc.?

Yes, Flow control is set at the DS200.

>    5)	How far away from the terminal server is the LAT connected printer,
>    	i.e. how long and what type of cable is used to connect the
>    	printer to the server?   
 
    The ln03 is App. 250 ft. away from the DS200. We are using a six wire flat
telephone cable, with a customized connector (MOD-TAP) that adapts to the EIA 
(RS232) connector on the ln03.  Note: I've included an explanation of the MOD-
TAP connector that I used to solve an Xon/Xoff problem I had earlier.
  
            <<< REGENT::SYS$SYSDEVICE:[NOTES$LIBRARY]LN03.NOTE;1 >>>
================================================================================
Note 573.7                   XON/XOFF & cable/wiring                     7 of 20
HYDRA::CHICOINE                                      48 lines  20-MAY-1987 10:18
                            -< MOD-TAP EXPLANATION >-
--------------------------------------------------------------------------------




      Hello everybody, 

      Some clarification on MOD-TAPS  and  What to do if you don't use
  them.
      MOD-TAPS are a eight pin telephone wire cable adapter that connects
  to the DIGITAL  EIA (RS232) standard terminal receptacle. These connectors
  allow our com people to use six wire flat telephone cable for all our
  communications wiring throughout the plant. 

Re: 573.5:
{    My specific problem was that the MOD-TAP connector on the LN03 didn't
{  have pin 2 (transmit) wired so that it would be able to send the XON/XOFF
{  signal back to pin 3 (receive) at the DS200. 

     Basically: all anybody needs to know is what pins on the LN03, need
  to be connected to what pins on their DS200.  

     NOTE:   I am not a communications specialist!  Please excuse the
  unprofessional terminology.

ON THE LN03:
         pin 2       pin 3                    pin 7
       transmit     receive                  ground
              \    /                           |                              
               \  /                            |
                \/                             |
                /\                             |  
               /  \                            |
              /    \                          pin 7    
         pin 2       pin 3                   ground                    
       transmit     receive   
ON THE DS200:

     There is also one other cable consideration, and that is length. It is
  my understanding, (through hearsay only) that as you approach the 325ft. to
  350ft. range, depending on gauge of wire used, you might begin to experience
  some problems. 

PS.     Sorry about my loose use of the MOD-TAP explanation in my last note. 
 It was my assumption that almost everybody was using them. I now understand
 that, with a few exceptions, only a small cluster of facilities in the 
 Littleton Mass area use them.

                             *** May God Bless ***
                                 John Chicoine

    There have been problems with LAT's using as a context switching
    character some rare code such as tilde (~) that *happens* to appear
    in Sixel codes. (Wish I had more information on LAT's!)
    
    	rmm
    

    RE: .5
    
    Not likely that the local or forward characters have anything to
    do with this problem.  Those character codes are only looked at
    in the terminal server on the receive data side of the terminal
    connecter.  So, unless your printer is spuriously generating the
    local/forward chars or there is sufficient line noise to have those
    show up, they probably aren't going to affect you.
    
    RE: .4
    
    To get the test page, press the little white button with the T on
    it on the back of the LN03.  Although if there are errors, the LED
    indicator on the front of the LN03 should flash some numbers indicating
    the number of the error.
    
    Also, although 250 ft is stretching RS232 a bit beyond the specs,
    it still should not be causing you problems.  I gather that you
    are positive that the XON/XOFF's are being generated, received,
    and obeyed?  Since you're in Littleton, can you find someone with
    a datascope and verify the XON/XOFF's are being handled properly?
    
    Another obvious question, are you printing the file with the
    /NOFORM/PASSALL qualifiers?

    Have you tried swapping the two LN03's?
    
    -tl
    

    re: .3
    
    I've gotten unwanted extra pages several times, usually with
    back-to-back large figures and the KEEP attribute. For example,
    back-to-back <FIGURE_SPACE>(FULL_PAGE) generates a blank correctly
    numbered page between the figures everytime I've tried it.

    
    re .7 (extra numbered figure page)
    
    what do you mean by 'blank correctly numbered page' ? We are
    working on a bug in an extra page with a continued caption. Do
    you get the caption? Or is it an unnumbered figure?
    
    

    
          Thank you all!
    
                Re: .6    /NOFORM/PASSALL  =  problem fixed.
    
                            *** May God Bless ***
                                John Chicoine

    re: .8 -- blank, numbered page, no caption. Here's the input:
    
    <FIGURE>(Pedestal Chassis Front Section\F4_PCFS)
    <FIGURE_ATTRIBUTES>(KEEP)
    <FIGURE_SPACE>(FULL_PAGE)
    <ENDFIGURE>
    <FIGURE>(Pedestal Chassis Front Section Leg\F4_PCFSL)
    <FIGURE_ATTRIBUTES>(KEEP)
    <FIGURE_SPACE>(FULL_PAGE)
    <ENDFIGURE>
    
    I meant to write a note on this some time ago, but time is tight
    and instead got rid of the glitch by making sure some text is input
    between figures. This is using BL07 and LYNX doctypes.

    
    This bug has been swatted. Note that you would not get an extra
    page if you didn't specify KEEP. There is no reason to specify KEEP
    for a single-page, full-page figure, since that will never be broken
    across pages.
    
    -pa

    yes, but, but, but, splutter.... I used keep to maintain text position
    not prevent a broken figure. I thought <LINE_ART>(KEEP) was to prevent
    brokrn figs. Seems idiosyncratic to me. Oh, well....

    You are correct, of course, KEEP means don't float in the context
    of the <figure_attributes> tag. Sorry for the confusion.
    
    The segment in .10 and the extra page is in fact a bug, which we
    have now fixed for V1.0. 
    
    -patti