Conference vaxuum::online_bookbuilding

    I know of no improvements over the methods outlined in note 50, but
    perhaps other readers do (but I wouldn't get my hopes up). However, the
    next version of the Bookreader (V3 now in external field test) will
    display EPS files. A writer's toolkit for VAX DOCUMENT support for this
    version of the Bookreader is in the planning stages to be released
    internally in the spring. (Watch this notes conf and the DOCUMENT notes
    conf for announcements/details.)
    
    Mary

    Thank-you very much for the good news, will await developments with
    keen anticipation.

    Some clarification:
    
    1. The V3 Bookreader support for EPS assumes that you are displaying
       one-page graphics. That is, you cannot use this to display your 
       400-page .PS manual: Bookreader will only display the first page.
    
    2. Bookreader also assumes that Display PostScript is installed on
       the server: Display PostScript is not bundled with the base system.
    
       This is why CUIP writers will not be shipping documents with EPS
       graphics: they cannot assume that Display PostScript will be on
       customers' systems.
    
    Mary

    I imagine there must be a good reason (something to do with
    copyrights?) why Display Postscript (is that a new or an old name
    for the CDA Viewer?) isn't bundled.  But it seems to me that -
    as EPS graphics would make life immeasurably easier for writers
    with either no Art Department or an Art Department that doesn't
    (horror!) use RAGS - there are two options:
    
    	o	a simple documentation change. Say, in the Installation
    		Guide, that Display Postscript is a pre-requisite for
    		reading this product's docs on Bookreader.  As this is
    		text, it _will_ be readable by everyone, and the people
    		who _do_ have Display Postscript won't be hobbled by a
    		restriction aimed at people who don't.
    	
    	o	get Bookreader to display a useful error message, saying
    		the same thing.
    
    Maybe these two amount to only one option really - do both; but I
    realize that changing code that works may not be very popular. 
    Bundling looks to me like the preferable solution to the EPS problem.
    
    Is this completely wrong-headed?
    
    b
    

Display PostScript (DPS) is not a new name for the CDA Viewer -- it is a
completely separate facility which is actually a DECwindows server
extension.  The VMS V5.4 (and later) CDA Viewer uses the Display PostScript
extension to view PostScript files.  The Display PostScript extension is
also bundled with ULTRIX.  However, as a server extension, DPS is optional;
applications should not rely on its existence to function.  If an
application does use a server extension, it should have some fall-back
mechanism to provide the same functionality on a server that does not have
the extension.  Unfortunately, the only "fall-back mechanism" for the
Bookreader is not to use EPS graphics, as there is currently no other way
of displaying these graphics without the DPS extension.

There are a number of reasons why we cannot assume that the extension
exists on every server.  On pre-VMS V5.4 versions of VMS and pre V4
versions of ULTRIX, the DPS extension does not exist.  The DPS extension is
currently not supported on DECwindows terminals.  Also, customers run
DECwindows applications on a variety of vendors' hardware; we cannot
guarantee that every vendor's server will have DPS.  All this means that
applications such as the Bookreader must play it safe and not use it.  This
position may change if DPS becomes a more standard part of X windows server
implementations.

Adrian

> All this means that
> applications such as the Bookreader must play it safe and not use it.
        
Strictly speaking, the application program called Bookreader must "use" DPS,
since it is very important and will reside on *most* Digital platforms.  It must
also have a user-friendly way of denying a request for DPS on a platform
that doesn't have it.

On the other, Digital products that *require* DPS in *all* platforms must be
prepared to deal with the tradeoffs.  If you are preparing documentation that
must be readable on *all* DECwindows/X platforms (i.e., everywhere the
Bookreader lives), you will have to avoid including PS graphics for the
foreseeable future.

Mark

The V3 Bookreader does both:
  o  It will display the EDPS graphics if the display workstation has
     the DPS extension.
  o  It will give an error message if you try to disply a PS graphic 
     on a machine without the DPS extension.  It will then draw a box
     with diagonals to indicate that something is missing (it will also
     do this if it doesn't recognize a datatype--this allows forward
     compatibility with future Bookreaders):
          +------+
          |\    /|
          | \  / |
          |  \/  |
          |  /\  |
          | /  \ |
          |/    \|
          +------+

The problem is that our Online Documentation Program (thus Digital's
online documentation) is required to display on the least common denom-
inator display device.  Currently, this is a Black and White X workstation
or PC.  In the not too distant future, this LCD display device will 
become a character cell terminal, further limiting our ability to take
advantage of workstation technology, as we look for a graphics type that
will display on CCTs as well as X displays.

This is also why we don't have any real color support (Note that
you get the Postscript color model with XDPS).

    Does anyone know how IBM handles this issue with InfoExplorer?
    
    Since InfoExplorer has two interfaces--one cct and one for the
    RS/6000, IBM must have come to grips with this issue of
    "least-common denominator." 
    
    I would hope that we will not be limiting graphics to those that display 
    on a terminal...That would pretty much cut out any hardware or other
    graphics designed with a 3-D tool--CAD/CAM, AutoTrol, for example.
    
    I went to the CUIP Competitive Lab to take a look myself, but the
    RS/6000 was down that day.
    
    Joyce

    We never saw any graphics on the InfoExplorer. From what I could deduce
    from the online docs, you only get graphics if you get the CD. Which we
    didn't have. 
    
    In some cases in the docs, I saw references to figures but they were
    not available. This strikes me as a poor solution, and suggests that
    maybe they *haven't* come to grips with the problem. Maybe they figure
    that the 'least-common-denominator' folks, like the non-CD-buying
    folks, can just live with no graphics or shell out the necessary $$$.
    
    (But that's just an opinion, I don't really know.)
    
    Mary

    
    I am actually referring to the problem mentioned in note 394.0 on
    display .eps files within bookreader.
    
    I just wonder if we could simply use the capture screen option within the
    session manager to capture the graphics required, and keep it in ddif
    format. I believed that bookreader understands ddif ('coz bookreader
    accepts images that are scan using DECimage Scan) and we could now read
    the captured images. However these images may somehow be distorted but
    it could be a temporily solution.
    
    Pi.

    I think I'd better set the record straight here. BOOKREADER does not
    understand DDIF. The various converters that output Bookreader format
    files converts the DDIF IMAGES(and ONLY images) to bitmaps. 
    
    
    Mike

>    I am actually referring to the problem mentioned in note 394.0 on
>    display .eps files within bookreader.
>    
>    I just wonder if we could simply use the capture screen option within the
>    session manager to capture the graphics required, and keep it in ddif
>    format.

Yes, this will work.  As Mike in -.1 explains, the Bookreader doesn't
understand DDIF directly - the authoring tool (DOCUMENT or DECwrite) must
convert the DDIF file into the proper format behind the scenes.  I know that
DOCUMENT will.  I think that DECwrite will as well.

-Mike