Conference vaxuum::document_ft

    At Patti's suggestion, I tried raising my page file quota.
    Specifically, I raised it to 2000 (from 8124).  That did solve the
    problem in .0.
    
    However, I'm having a problem with the POSTSCRIPT queue.  Neither
    the IVP nor this latest job have appeared, although both were
    supposedly queued.  They're not stuck in the queue anywhere.  They're
    simply gone.
    
    The default qualifier of /PARAMETER:DATA_TYPE:POSTSCRIPT conflicts 
    with the syntax I had been using (/PARAMETER=(DATA_TYPE=POSTSCRIPT),
    but there's no error on the queuing.  It's just that the job
    disappears.  I'm trying to queue these to an LPS40, and I did not
    specify any additional qualifiers during the installation.
    
    Thanks.
    -pd

    Just to let you know you're not alone Peter, we're having exactly
    the same problem.  We were thinking it might have something to do
    with the LPS40s, but perhaps not.
    
    --Craig

    I am not using baselevel 8 and don't know about the default queues
    it establishes during installation.
    
    If an LPS40 queue is established using /PARAMETER:DATA_TYPE:POSTSCRIPT,
    you may want to change it to the standard LPS40 syntax, which is
    /PARAMETER=(DATA_TYPE=POSTSCRIPT).
    
    I suggest this because using the syntax with colons 
    (/PARAMETER:DATA_TYPE:POSTSCRIPT) from the command line gives you a 
    syntax error and aborts the job.  However, you are not notified of the 
    abort unless you have included /NOTIFY or /PARAM=MESSAGES in the command.

    Kathy Murphy    

    The /PARAMETER qualifier seems to be going on the PRINT/QUEUE command,
    not on the actual queue startup.  Is there a way to change the
    qualifier that document uses?  It doesn't seem to be in DOC$STARTUP.COM
    anywhere.
    
    Thanks.
    -pd

    
    it's in DOC$DESTINATIONS.DAT, which should be in 
    DOC$LOCAL_FORMATS. The program AUTODEST, described in the release
    notes, should be used to update it. However, the version of
    AUTODEST in the kit is broken; we are working at fixing it.
    Meanwhile, you can (very carefully) edit that file. I say
    carefully because the syntax in the file is strict and there's no
    error handling.
    
    

    I've fixed the KITINSTAL.COM for the upcoming SDC kit to 
    create the right qualifier in DOC$DESTINATIONS.DAT.

    I just tried <EMPHASIS>(carefully) editing DOC$DESTINATIONS.DAT (which
    is in DOC$ROOT:[TEX.FORMATS], by the way) and changed the PostScript
    print qualifier.  Specifically, I changed 
    
    	/parameter:data_type:postscript
    
    to
    
    	/parameter=data_type=postscript
    
    That seems to have solved the problem.
    
    Thanks.
    -pd

    thanks for the bug report, the fix, the test, and the result.
    

    Actually, it's somewhat more complicated than that, if you really
    want to give the user complete control of the PostScript.  The current
    LPS40 symbiont (at least, I think it's in the symbiont) allows several
    parameters to be specified.  If there's just one, you can get away
    with
    
    	/PARAMETER=DATA_TYPE=POST
    
    but if there are more than one, you need a construct like
    
    	/PARAMETER=(DATA_TYPE=POST,PAGE_ORIENTATION=LANDSCAPE, ... )
    
    In other words, you can have several parameter settings, enclosed
    in parentheses, as an argument to the /PARAMETER qualifier.  Check
    the LPS40 client software manual for more info.
    
    -pd

    You can always provide the parameters you want on the DOCUMENT command,
    such as
    
    	$ DOCUMENT file doctype dest /PRINT=(COPIES=3,NOTIFY)
    
    and the design of the destinations file would allow you to put those
    additional parameters there, if you want it to be the DOCUMENT default.
    (Of course, the AUTODEST program we recommend you use to do that
    is not all there yet.)
    
    Mark

    Well, just for grins, I tried putting my thesis through BL08, with
    REPORT as the doctype and POSTSCRIPT the destination.  I was
    disappointed to see that some of the problems I reported for BL07
    (probably in the DOCUMENT notes file) are still there.
    
    In particular:
    
     -	the type for body text is too small, making the pages harder
    	to read than LN03 output.  This also makes text done with the
    	<EMPHASIS>( \SMALL_CAPS) too cluttered.
    
     -	in <MATH> and <MATH>(DISPLAY), certain characters are printing
    	as blobs of ink instead of readable characters.  Specifically,
    	"Y" (but not "X"!), <MATH_CHAR>(DELTA), and "p".  Other characters
    	seem to work ok.

    
    I'm not sure there's much we can do about the font. The
    problem with the blobs was listed in the Release Notes; we will
    fix this.
    

    I really don't think the font is smaller (that is, a smaller point
    size).  What I think has happened is that the PostScript fonts are
    just "different".  The white space around characters is a bit less
    in, and it seems that the characters are a bit more condensed.
    
    One thing I'd like to try would be switching to Century Schoolbook
    for the PostScript text font.  The readability of this font is much
    better than Times at the same point size.
    
    Is it possible to have DOCUMENT use Century by just slightly twidling
    with the doctype, or is it much more complex than that?  We would
    like to run some tests on this and see what it does for our
    readability.  I realize that if we went for this option we might
    loose "device independence", but we plan on using PostScript
    exclusively so this would not be an issue.  Would going to Century
    create major doctype maintenance problems?
    
    Of course, if DOCUMENT offered kerning....
    
    -- Craig

    Well, we ran some tests using New Century Schoolbook and compared
    it to the same file run out using Times.  Everyone who's seen it
    so far has selected Century as the hands down winner for readability.
    As an aside, not long ago I worked in a design firm and created
    *many* format designs for our documentation clients.  I usually offered
    them a choice of three fonts for their text face, Times, Century,
    and something else.  Without fail, every client chose Century.  
    
    I'd recommend giving it a try.  Unless it looks like we'll run into
    maintenance probelms, we're going to have all our doctypes use Century
    for the text face. 
    
    -- Craig

Is CENTURY available in the LN01 and/or LN03 fonts?

Thanx

Rose

    
    no. they are not.
    

    CENTURY is available in DECpage font kit or separately from
    CompuGraphic.
    
    	rmm
    

    RE: Note 395.17 
    
    >                        -< "available" ?  Yes. >-
    >
    >CENTURY is available in DECpage font kit or separately from
    >CompuGraphic.
    
    What you get that way is 1/2 the solution.  (Okay, maybe 3/4. :-)
    
    VAX DOCUMENT also needs a TeX font metric (TFM) file (which we generate
    from the CFFF-format font file); and the DOCUMENT character set is a 
    superset of the DEC MCS that you might find in these external files.  
    That is, we use all of MCS plus a handful of publishing marks 
    (bullet, daggers, etc.).
    
    Mark

    The DECpage fonts (also available via CG) also have many publishing
    characters.  There are enough, in fact, to make up a 94-character file.

    							Ann B.

    > Mostly 
    
    I don't doubt that the DECpage fonts are good and rich fonts.  But
    the VAX DOCUMENT macros expect to find a bullet at #129, and a
    registered mark at #134, and the 'fi' ligature at #137, etc.
    
    If you use a font from some other source that does not provide these
    characters at the positions required, you may not like the results.
    VAX DOCUMENT fonts *do* correspond to the DEC Multinational Character
    Set *plus* 10 characters in the 129-138 range, so documents that
    use only the MCS would still work.  But you still need a TeX font 
    metric file.
    
    I don't mean to imply that these problems are insurmountable --
    just that the solution may be more involved than you would guess
    at first glance.  And "mostly" is not usually good enough.
    
    Mark