needed: working psview / dvi2ps

[Jean-Francois Lamy]

seth at miro.Berkeley.EDU (Seth Teller) writes:

>i am using 'psview' on a silicon graphics box to preview the
>output of the 'latex .. dvi2ps' process.  although the dvi2ps output
>prints perfectly to the laserwriter, it hangs the sgi previewer 
>software (for reasons unknown to me).

LaserWriter have many extensions that are used by several drivers; common
versions of dvi2ps (2.10 and 2.11) have that problem.

>as a workaround, it would be great to have either A) a working 
>previewer 

Now, now.  The previewer is likely doing just fine on real PostScript with
no LaserWriter extensions.  You can't even throw the book at the people
who wrote your dvi2ps, it was likely written before the Red Book came out...

>		or B) a dvi2ps which produces 'better behaved' postscript.
>(i don't know a whole lot about it, but from the looks of dvi2ps's 
>output, there seem to be a lot of printer-specific commands 
>generated; binary font specs and the like.  these are apparently
>the cause of the hangs.)

But Glenn Reid from Adobe posted some code a while back (after someonw whined
about Display Postscript not accepting LaserWriter PostScript code) that could
alleviate the problem.  See official party line from Adobe and the code
enclosed at the bottom

Having said that, I think that trying to preview PostScript generated from a
TeX document that uses the Computer Modern or other bitmapped fonts is at best
a good way to spend a lot of time waiting.  The "printer-specific" fonts you
allude to aren't really: they are the only easy way to encode the btmaps for
the characters in your paper.  They take a lot of time to process (the
Hexadecimal encoding used by PostScript to remain 7-bit-ascii sure doesn't
help).

I haven't seen it, but the previewer by Gigante et al. advertized in this
forum a while back should have no problem doing better, even if psview worked
on phoney PostScript.  Any "direct" solution will likely be better than
PosScript. TeX and PostScript just aren't a good match.

(before any PostScript bigot roasts me, I should add that the PostScript
translator in use here has been heavily beaten on by yours truly, and I wear
the battle scars of my encouters with PostScript trying to get it to do things
right on various printers and phototypesetters. I even used to like PostScript
:-).  It might even work with an R3000 in every printer :-).

Jean-Francois Lamy               lamy at ai.utoronto.ca, uunet!ai.utoronto.ca!lamy
AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4
-------------------------------------------------------------------------------

Here is the code and comment, which recently surfaced again when people here
complained about Imagen's UltraScript and whatever runs in Dec LN03s

Article 3846 of comp.windows.x:
Path: jarvis.csri.toronto.edu!mailrus!purdue!decwrl!adobe!greid
From: greid at adobe.com (Glenn Reid)
Newsgroups: comp.sys.mac,comp.windows.x
Subject: Re: PostScript previewer to view Mac PostScript files.
Message-ID: <514 at adobe.UUCP>
Date: 22 Feb 89 18:30:11 GMT
Sender: news at adobe.COM
Organization: Adobe Systems Incorporated, Mountain View

In message <35953 at bbn.COM>, franco at 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