franco@bbn.com (Frank A. Lonigro) (02/14/89)
Hi: I need a PostScript previewer to view the PostScript files produced on the Mac with the "clover-f or clover-k" command keys. I need a PostScript previewer that works on a VaxStation2000 running X11R3 and hopefully supports 4 planes of color. I currently have this package from edmoy@violet.Berkeley.EDU called MacPS which takes a PostScript file from the Mac and allows me to convert it so I can print the file from my unix machine to my postscript printer. This works just fine and the output to the printer is perfect and is as if I printed it directly from my Mac through the AppleTalk. But I would like to view these converted PostScript files on my VaxStations color screen without sending them to the printer. Does anyone know how I can do this? Thanks in advance, -franco PS. I'm running Ultrix3.0 on my VaxStation2000 with DECWindows included and the "dxpsview" program complains that it doesn't know about the command "serverdict" which is in the converted PostScript file produced by MacPS, so "dxpsview" won't work. What I don't understand is that the printer can print the file and understand all the PostScript commands that are in the file, but the dxpsview'er doesn't understand all the commands. Isn't the pspreviewer suposed to be a complete PostScript interpreter? Just curious! =================================== === ========= ===================== = Frank A. Lonigro = === ========= ===================== = franco@bbn.com = === === === === = franco%bbn.com@relay.cs.net = === === === === === === === = ...!harvard!bbn!franco = === === === === === === === = BBN Inc., Cambridge, Mass. = === === === === === =================================== =======================================
greid@adobe.com (Glenn Reid) (02/23/89)
In message <35953@bbn.COM>, franco@bbn.com (Frank A. Lonigro) writes: > Hi: > I need a PostScript previewer to view the PostScript files produced > on the Mac with the "clover-f or clover-k" command keys. I need a > PostScript previewer that works on a VaxStation2000 running X11R3 and > hopefully supports 4 planes of color. > PS. I'm running Ultrix3.0 on my VaxStation2000 with DECWindows included and > the "dxpsview" program complains that it doesn't know about the command > "serverdict" which is in the converted PostScript file produced by MacPS, so > "dxpsview" won't work. What I don't understand is that the printer can print > the file and understand all the PostScript commands that are in the file, but > the dxpsview'er doesn't understand all the commands. Isn't the pspreviewer > suposed to be a complete PostScript interpreter? Just curious! Here is an explanation of why PostScript(r) programs generated by existing Macintosh and PC applications may not work immediately on Display PostScript(tm) systems, including the DEC previewer, dxpsview. Some PostScript language code to work around the common problems is appended to this message. PostScript language programs that are written according to the PostScript Language Reference Manual are guaranteed to be portable across all Adobe PostScript interpreters for both printers and displays. Period. In practice, it is desirable to be able to change certain aspects of a printer's behavior under program control, and this means using PostScript language programs. An example of such printer specific behaviour is the use of a specific paper tray if it is available on the particular PostScript printer. To accomodate this requirement, the PostScript interpreter in each printer may have system-specific operators that are defined in special dictionaries. Applications that can take advantage of special features of a printer, or that just want to avoid the overhead of sending their particular library of procedures to the printer before every document, can use the system-specific operators to do so. However, application writers must take great care when using operators that are defined outside the PostScript Language Reference Manual. To avoid writing custom drivers for specific printers and thereby losing all portability of the PostScript programs they generate, applications typically include a prolog of PostScript language code at the beginning of a document description both to test for special printer features and to store a library of procedures semi-permanently in the printer (they are stored until the printer is powered off). The problem that is encountered when giving a PostScript program generated by the popular applications to a Display PostScript system, is that the PostScript prologs that are prepended to the document descriptions often use some system-specific operators without first testing whether they are defined in the interpreter. The most obvious situation arises when an application tries to store its library of procedures so that they are available to subsequent jobs: In printers, document descriptions are executed one at a time in sequence by a PostScript program referred to as the "server loop". The server loop executes the PostScript operator save before starting each job and executes the restore operator at the end of the job. Any definitions made by a document description are discarded by the restore operator. To keep a library of procedures for subsequent jobs, the procedures must be defined outside the server loop's save/restore protection. This is accomplished by sending a special job to the printer that executes a system-specific operator, "exitserver", which is defined in a system-specific dictionary, "serverdict", and then executing the procedure definitions. After the job completes, the server loop is restarted and the definitions are available to the next job to arrive at the printer. The Display PostScript System has no notion of a sequence of jobs. It simply provides the PostScript imaging model to applications that want to draw on displays. Therefore it has no server loop and none of the system-specific operators and dictionaries to support the server loop. All Adobe PostScript printers to date have had a server loop and so it is understandable that the authors of PostScript drivers for applications have overlooked the fact that serverdict and its operators are system-specific. This is why the PostScript drivers in the most popular applications simply try to execute the "exitserver" operator from "serverdict" without checking first that the dictionary and operator are both defined by the interpreter. Consequently the PostScript programs generated by these applications encounter an error when executed by the interpreter in a Display PostScript System. Because it is impractical to expect application vendors to issue corrected, system independent drivers, the appended PostScript language procedures may be prepended to documents before giving them to a Display PostScript system, including DEC's dxpsview. These procedures make documents that use Apple's Laser Prep prolog and the Microsoft Word prolog work on DEC's previewer. Just concatenate these procedures, the application's prolog, and the document description (in order) to the previewer as a single file. The same file, including the appended prolog, may be sent to a PostScript printer, of course. The prolog provided here contains a minimal set of definitions. Other definitions may be needed by drivers used by other applications. There are sufficient examples in the appended prolog to show how to add definitions as necessary. For further advice on writing system independent PostScript device drivers, please refer to the book "PostScript Language Program Design" by Adobe Systems, published by Addison-Wesley. -------------------------------- Cut Here -------------------------------- %! %%Title: dpsdummyprinter.ps -- DPS prolog to emulate some printer features. % % Copyright (c) 1989 Adobe Systems Incorporated. All rights reserved. % % This file makes a number of definitions that are technically system specific % but are used by many existing PostScript language drivers that were written % without sufficient attention to the specification. % % This prolog ensures that serverdict, exitserver, and assorted statusdict % operators are defined as expected. The flushfile operator is also redefined % to allow Macintosh files with a prepended Laser Prep file to work properly. % % There is one special "feature" definition. The ASCII character \004 % (CTRL-D) is defined as a no-op operator in case the prolog contains % one to indicate end-of-file in some contexts. % %%BeginProcSet: DPSDummyPrinter 1 0 /serverdict where {%if pop } {%else /serverdict 1 dict def } ifelse serverdict /exitserver known not { % NOTE: We let the usual invalidaccess error occur if serverdict is not % writeable and exitserver is not known. This is unlikely because % either serverdict was just created (above) or it already existed % in which case exitserver should have been defined. serverdict /exitserver % int exitserver -- { 0 ne { /exitserver errordict /invalidaccess get exec } if {{end} loop} stopped pop % Clear dictstack clear } bind put } if statusdict /execjob known not { statusdict /execjob {exec} bind put } if statusdict /legal known not { statusdict /legal {} put } if statusdict /letter known not { statusdict /letter {} put } if statusdict /pagecount known not { statusdict /pagecount 0 put } if statusdict /printername known not { statusdict /printername (DPS) put } if statusdict /setjobtimeout known not { statusdict /setjobtimeout {pop} bind put } if statusdict /setrealdevice known not { statusdict /setrealdevice {} put } if statusdict /waittimeout known not { statusdict /waittimeout 600 put } if % The Mac Laser Prep file executes the flushfile operator to get to the end % of the prolog. When documents are saved with the prolog attached, the % flushfile consumes the document and nothing is printed. To get around this % problem the definition of flushfile is changed below to consume bytes of % input until a PostScript language comment (%) character is found. The % rest of the line is then consumed before the revised flushfile terminates. % This only works correctly when there is a PostScript language comment % where an end-of-file would be expected, which is usually true, luckily. /*flushfile /flushfile load def /flushfile % file flushfile -- {%def {%loop -- search for next percent character in file dup % Copy file parameter read { % Consume character 8#045 eq { % Check for ASCII percent character exit % Leave loop } if } if } loop {%loop -- search for newline character at end of comment dup % Copy file parameter read { % Consume character 8#012 eq { % Check for ASCII newline character exit % Leave loop } if } if } loop pop % Discard file parameterp } bind def (\004) cvn {} def % To ignore ^D at the end of prologs. %%EndProcSet