Conference vaxuum::document_ft

Imagine the OTHER possibilities, if it is not the LN03 buffer size!
    

    >Does this mean that the LN03's buffer is too small and I need an upgrade ?
    
    There is no "upgrade" for the LN03 font memory (except the plug-in
    RAM cartridges that have been around for years).  The PLUS board
    upgrade buys you additional space for graphics storage (essentially)
    and some other features, but not more text or font capacity.
    
    
    >Anyone ever get an LN03 finished result with a mixture of Russian
    >and English?
    
    I assume that, in the context of this note, "English" means "the
    right characters" and "Russian" means "the wrong characters".
    
    Yes, it is possible for the document to carry more font data than
    the LN03 (of any flavor) can handle, and this could cause you to
    get the wrong characters for certain fonts.  However, the BL08 version
    should "never" do this.  If you were using BL08, please contact
    me at VAXUUM:: or CLOSET::DEVRIES.  I'd like to look at your files.
    (And if you weren't using BL08, contact me anyway.  It would be
    nice to prove that this file *works* in V1.0.)
    
    Thanks,
    Mark

    We've encountered situations which caused garbage (aka Cyrillic)
    on fully RAMmed LN03s. The cases I've seen have been when a) there
    has not been a reset sequence between print jobs and b) whene there
    has.
>                           . . .                However, the BL08 version
>   should "never" do this. 
    
    Does this mean that a LN03 reset sequence is sent with each job
    that's been produced under bl8? Or something even better?
    
    All for world peace ... 

    I may be mistaken, but I think the LN03 files produced by DOCUMENT
    already do reset the font memory.
    
    I also thought that if you overflowed the RAM font memory, that
    you typically got output that looked as though someone had used
    white-out all over the place, i.e. missing characters etc., and
    not "bad" characters.  This sounds more like a printer or communication
    line problem.
    
    -tl

    Yep. A reset is included in ln03 output produced by earlier editions
    of Document.
    
    Oh, well, back to sprinkling garlic on the ln03.

    My problem has been cleared up.  I currently have 0 RAM cartridges
    and I was told for DOCUMENT you need at least 1 maybe 2 for the
    large files.  The cartridges are at 128K each while, without them,
    the LN03 is at 28K.
    
    Mike
    

    if you had no RAM cartridges, you should have also seen the 24 error
    MISSING FONT.
    
    jack

    RE: When is a RAM not a RAM?
    
    I have seen a case in which an LN03 had both RAMs in its mouth(s),
    but they were not properly seated and so were effectively not there.
    When you push the (T) button on the back of the printer, the test page 
    will tell you how much font memory the LN03 thinks it has.
    __________
    
    RE: this should "never" occur... [where "this" is "too much font data 
    for an LN03 with both RAM cartridges"]
    
    The LN03 converter has always checked for a maximum number of different
    characters in different sizes in different fonts, and in rare cases
    that the threshold was reached, aborted the job (because the threshold
    was intended to mean that you'd already run out of space, and the
    program had no way to output part of a job).
    
    As of BL08, the threshold is now considerably lower, but once the
    software detects that complexity, it continues to read to the end 
    of the current page; at that point it writes a font load into the 
    output file, then writes out the contents of the document since the 
    start (or since the last font load), then continues with a "clean
    slate" at the next page.
    
    So the goal is that you should "never" have too much font data for
    an LN03 with 2 RAMs to swallow.  But the predictors are not precise
    so, while encountering even this threshold should be pretty rare,
    I cannot absolutely guarantee that this problem will never occur
    again.
    
    Please send me details if you get the LN03 error "24" for MISSING
    FONT with BL08.  (First, please press the (T) button on back of
    the LN03 to see that it "sees" both RAMs.)
    
    Thanks,
    Mark
    

    Excuse me if this is ignorant but I'm assuming that DOCUMENT does
    not use the LN03 font cartridges CG TIMES & CG TRIUMVIRATE for the
    extra small and large font settings.  There is only 2 slots so they
    would have to be removed for the RAM cartridges.
    
    Mike
    

    That is correct.  DOCUMENT does not use any LN03 font ROMs -- it
    downloads its own fonts.
    
    Mark

    re: .4
    
    " I may be mistaken, but I think the LN03 files produced by DOCUMENT
      already do reset the font memory."
    
    I think not, and this has caused numerous problems for us.  After
    sending DOCUMENT output through the LN03 (yes, with both RAM's firmly
    in place), certain OTHER software (non-DEC) output gets screwed
    up.  And hitting the test button to see how much memory is available,
    it is NEVER full memory after DOCUMENT output gets printed.
    
    Is there some better way for us to set up the LN03 queue or ?
    
    Thanks,
    
    	Penelope

    The Document files reset the printer before starting the print job,
    not after. So, it's the responsibility of the print queue (or the
    next file) to clear out the buffers.
    
    A reset module of some sort needs to be specified in the separator.
    (See below under /separate.) This module need only contain an <ESC>c,
    the LN03 reset sequence. It can contain other things, if you desire,
    to set up the page for other non-Document jobs.
    
$ show que /full sys$print
Terminal queue SYS$PRINT, on CUPOLA::$PRINTER, mounted form DEFAULT
    /BASE_PRIORITY=4 /CHAR=(52) /DEFAULT=(FEED,FLAG,FORM=DEFAULT) /NOENABLE_GENERIC /LIBRARY=LN03CTL Lowercase /OWNER=[SYSTEM] 
    /PROTECTION=(S:E,O:D,G:R,W:W) /SEPARATE=(RESET=(LN03$RESET))
    

    The last things written into the LN03 output file are
    
    <esc>c	RIS (reset internal state), which resets everything
    		except fonts
    
    <esc>P0;1;0y	DECLFF (load font files), with these parameters:
    			Ps1 = 0 means Digital format
    			Ps2 = 1 means do not print summary sheet
    			Ps3 = 0 means delete all fonts
    
    <esc>\	ST (string terminator) for the DECLFF sequence
    
    
    The DECLFF ... ST sequence is the one recommended in the LN03
    programmer's reference manual (except that they use Ps2 = 0 to get
    a summary sheet at the same time).
    
    My LN03 is broken right now, so I can't check this -- but at the
    time I implemented this (several months ago), I checked several
    jobs and got the desired results.  This has been distributed at
    least as long as BL07 (first field test version) -- longer, I think.
    
    Are you referring to baselevel 06?
    
    Mark

    By observation baselevel 8 includes those escape sequences mentioned in
    .13 at both the beginning AND the end of the .LN03 file.  Seems little
    doubt about DOCUMENT clearing the fonts out and leaving the printer in
    a reset state. 
    
    -tl