Conference vaxuum::document_ft

    I'll second .0; and in addition, the footnote superscript needs
    to be separated from the referenced text... the number frequently
    jams the word it's appended to. Is it possible to "fine-tune" the
    postscript output? it seems necessary.

    The shapes of PostScript characters are built into the printer.
    The software does not control that.  However, we should be able do 
    something about the spacing issues.  I imagine the font metrics are 
    set up so that adjacent underlines and dashes will join into a continuous
    line.  We'll put that work on the wishlist.
    
    In which doctypes are these particularly objectionable?
    
    --Mark

    I'll jump in here as well.  There does seem to be quite a few glitches
    with PostScript output.  Some more include: bullets that are
    used with small text in the OVERHEADS doctype are too large (that
    is, they are the same size used for the regular size text, LN03
    output uses two different sizes), and the either the large brackets
    (or was it braces, can't remember which) output as "blobs".  Many
    of the math and MCS characters print as blobs also, but I think
    you DOCUMENT folks already knew about those.
    
    Would it be possible to give us PostScript users an update on
    fine-tuning DOCUMENT's output to this destination, and perhaps what
    priority this work has?  With the new high res. plain paper PostScript 
    printers coming out, and as more DEC folks get DIGITAL's new
    PostScript printers I think this is going to become a *very* popular 
    destination. 
    
    Thanks,
    
    -- Craig  

>    either the large brackets (or was it braces, can't remember which) 
>    output as "blobs". 
    
    In test baselevels, the MCS characters as well as the extensible braces
    and brackets (which live in the same fonts) were prone to becoming
    "blobs".  That's fixed in V1.0.  (Please say you weren't referring
    to the SDC software.)
    
>    Would it be possible to give us PostScript users an update on ...
>    ... what priority this work has?
    
    <PARTY_LINE>
    We are just beginning to funnel all those wishlist items into one
    place so we can assign priorities to them.
    <ENDPARTY_LINE>
    
    <PERSONAL_OPINION>
    PostScript is the wave of the future for DEC and VAX DOCUMENT, and
    it's the one we've had the least chance to fine-tune.  As a general
    statement, PostScript development rates very high on my agenda,
    and others express the same view.  But we can't begin to say which
    specific items will get addressed first.  (LN03-users, don't be
    alarmed.  TBU is continuing to support the LN03 protocol, and VAX
    DOCUMENT will continue to develop those capabilities as well.)
    <ENDPERSONAL_OPINION>
    
    --Mark

    Great!  Thanks for the quick update Mark.  The problems I mentioned
    were in baselevel 8 (is that a sigh of relief I heard?).  We will
    have V1.0 installed next week.  Looking forward to trying it out.
    
    -- Craig

    Re: .1
    
    I agree. The hyphens look wrong. They seem to be en-dashes.
    
    Re: .2
    
    I looked into this problem by poking around in the PostScript prolog I
    found in my output. It turns out that PostScript output does not print
    the glyph named /hyphen for hyphens, it prints the one named /minus.
    Adobe includes the characters /hyphen, /endash, /emdash, and /minus in
    all of their fonts. /hyphen is encoded at 8#055, /endash at 8#261,
    /emdash at 8#320, and /minus is normally unencoded. In DOCUMENT's
    PostScript prolog, the encoding vectors created for use with PostScript
    fonts put /minus at 8#055. I think this should be changed. 

    Yes, the character encoded at 8#055 is /minus, and that *is* wrong.
    That code is copied directly from the LPS40 device control library.
    The problem is that the MCS definition calls that character minus,
    since minus and hyphen were the same thing when all the world spoke
    VT100.  But the thing Adobe calls minus is NOT the same as hyphen.
    In fact, their minus seems to be the same as endash.
    
    This fix was identified after the V1.0 release, and a new DVC$PROLOG.PS
    was announced to the world in note #775.4, which says
    
    	Copy {VAXUUM,CLOSET}::KITS_:[DOCUMENT.V10]DVC$PROLOG.PS
    
    into your
    
    	DOC$PS_FONTS
    
    directory.  That fixes the obvious hyphen-too-long problem as well
    as some subtly-dependent alignment problems as discussed in 775.*.
    Note that this fix is not part of the V1.0 kit or internal kits.
    You have to explicitly copy this prolog to get the fix.
    
    --Mark
    

    See note 775.* 
    
    Lee
    

    Mark and I replied at the same time ... .7 is the result of
    the reports (and subsequent solution) in 775.*   
    
    Lee