Conference vaxuum::document_ft

    While we are on the subject of POSTSCRIPT figures, can you point
    me to documentation that describes the conditions/restrictions,
    etc. that have to be applied to a POSTSCRIPT "program" that is to
    be included in a FIGURE tag?
    
    jack

    
    I need help with this also. We have an editor that our hardware
    engineers are using that generates postscript output. Their drawings
    print fine, but they do not work when included in SDML files with
    the <figure_file> tag. We really do need some info on what document
    expects in a postscript file. Who is the person that knows about
    this stuff? Can you shed some light?
    
    We really do need this to work soon.
    
    Ken Serack
    DECwest Engineering

    I generated a figure with GRED and converted it to both SIXEL and
    POSTSCRIPT format.  Then I tried to include it in a document using
    <figure_file>, one for each device type.  Processing for the LN03
    produces a document with the correct figure, processing for POSTSCRIPT
    results in a failure in POSTSCRIPT. the faulting element is IF,
    of all things.  I can supply files when you are ready to take a
    look at it.
    
    jack

    Well, I'm no expert (but that never stopped anybody, right?) I did
    however just finish rewriting a program to make the PostScript
    output compatible with DOCUMENT. 
    
    One thing I noticed about RENDER output is that it does an initgraphics.
    DOCUMENT goes to a lot of trouble to set up the graphics environment
    for your figure, setting the origin (0,0) just above the following
    text and aligned with the left text margin. The initgraphics will
    blow away all that work. So you'll probably want to start by commenting
    out the initgraphics. 
    
    Also, beware of the image operator. I found that it (in conjunction
    with readhexstring) chews up more hexidecimal data than expected.
    What happens is it starts reading the following DOCUMENT code and
    trying to use it as hex. This will cause some (fairly random) error
    from the remaining DOCUMENT code. (One example might be the error
    for the if operator you encountered.) 
    
    --Andrew

    I have the files from SARAH and the DECgraph PostScript maker and
    I am looking at them.
    
    I would like files from the editor at DECwest --- is that Auto-Trol
    by any chance?
    
    I am very suprised that the PostScript from RENDER operating on a GRED
    metafile causes trouble. Is that V3.0 of HCUIS you are using or
    the field test of 3.2?
    
    In general, Mark DeVries is the one who REALLY understands the insides
    of the PostScript translator, but he's preoccupied at the moment with 
    getting our field test update done. Therefore, I am doing the
    debugging.
    
    I will post something as soon as I can.
    
    								jp
    

Here's the quick and dirty assessment in answer to .2.

The files there were produced from a VALID to PostScript translator.    
    
The problem is in the EndV2PS macro used by the translator to clean up at
    the end.

By defining that macro to be null, I get the VALID PostScript file into
the document.

Do you have any control on the size of the graphic? Can you scale it?
(That is, before we think of hand editing the PostScript to scale the figure,
the preferable thing is to get the application to do the scaling.)

In any case, if you edit a VALID postscript file and search for EndV2PS,
you will find something that looks like this:

/EndV2PS { clear initgraphics
	   saveobj restore % restore the VM
	 } def

If you delete all the stuff between the curly braces so that it looks like
this:

/EndV2PS {  } def

you will get the graphic into your file.                

Let me know what your experience is and whether this meets your short term
needs. 


							jp
    
    

    Well, we got the valid files to run in document, but now our marketing
    people are looking at other application for generating postscript
    for inclusion in document. 
    
    Are we going to have problems with every new postscript application?
    What, in general, will we have to watch for in postscript files?
    Is taking out the showpage enough? initgraphics? Are there any
    guidelines?
    
    It seems that as document gets closer to being shipped as a real
    product, these questions become more important. All those people
    out there who will buy document, but are not running vaxstations
    and gred -- what are they going to do? I suspect that some of them
    anyway will be using macintoshes to generate their postscript graphics.
    What needs to be done to a macdraw or Adobe illustrator postscript
    file to include it in document? We are evaluating a bunch of business
    graphics packages that run on PC's or VAXmates and generate postscript.
    Should I expect a lot of trouble getting this stuff to work?
    
    It would be great to have some sort of guideline or spec stating
    what is expected by document in the postscript file, how document
    treats that file, whether or not document redefines any standard
    postscript operators, etc
    
    Lots of questions --
    
    Ken Serack
    DECwest Engineering

There are, indeed, guidelines:

From:	BAXTER::24799::HASTINGS "Tom Hastings TBU.Prog.Off.223-8109  25-Mar-1987 2138" 25-MAR-1987 21:48
To:	@H:HIP_ARCH_MEMBERS
Subj:	Encapsulated PostScript File Specification

From:	VIDEO::HASTINGS     "Tom Hastings TBU.Prog.Off.223-8109" 24-MAR-1987 21:29
To:	@H:HIP_PRINTING_SYSTEMS_MODEL_STEERING,HASTINGS    
Subj:	Encapsulated PostScript File Speciifcation 

The Adobe standard for Encapsulated PostScript Files is available in: 

REGINA::HIP$:ENCAPSULATED_POSTSCRIPT_FILE_SPEC.PS

It contains rules for generating a PostScript file that represents 
a self contained piece, like a figure or picture, that is intended
to be included in a document.

Please read it and put any comments on it in the PostScript notes 
file. (REGENT::POSTSCRIPT, I believe).

Thanks,
Tom