seth@miro.Berkeley.EDU (Seth Teller) (09/14/89)
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). as a workaround, it would be great to have either A) a working previewer 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.) can anyone supply these things, or suggest a place to look further? thanks, seth teller seth@miro.berkeley.edu ucbvax!miro.berkeley.edu!seth
lamy@AI.UTORONTO.CA (Jean-Francois Lamy) (09/14/89)
seth@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@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@adobe.com (Glenn Reid) Newsgroups: comp.sys.mac,comp.windows.x Subject: Re: PostScript previewer to view Mac PostScript files. Message-ID: <514@adobe.UUCP> Date: 22 Feb 89 18:30:11 GMT Sender: news@adobe.COM Organization: Adobe Systems Incorporated, Mountain View 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
tps@chem.ucsd.edu (Tom Stockfisch) (09/19/89)
In article <89Sep13.211218edt.2356@neat.cs.toronto.edu> lamy@AI.UTORONTO.CA (Jean-Francois Lamy) writes: >seth@miro.Berkeley.EDU (Seth Teller) writes: >>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. Yes, the previewer does just fine with the postscript, but it does not have the features that are given in the man page. Specifically, it will not read input from stdin, regardless of whether you invoke it as "psview <file.ps" or "psview - <file.ps". "say" is supposed to work on stdin as well when invoked as "say -P": it doesn't. Is there any way to get a postscript file to be executed in a window? "psh" works on stdin (thankfully), but it just writes on the background -- you have to move all your other windows out of the way and damage is not repaired. -- || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu
msc@ramoth.esd.sgi.com (Mark Callow) (09/20/89)
In article <564@chem.ucsd.EDU>, tps@chem.ucsd.edu (Tom Stockfisch) writes: > Yes, the previewer does just fine with the postscript, but it does not have > the features that are given in the man page. Specifically, it will > not read input from stdin, regardless of whether you invoke it as > "psview <file.ps" or "psview - <file.ps". "say" is supposed to > work on stdin as well when invoked as "say -P": it doesn't. In IRIX 3.2, psview reads from stdin if no file is specified. I frequently use the command line psroff -me xyz.me | psview -F to preview documents. (-F gives me a page sized window so I don't have to stretch it out). say does work on standard input. You have to have a null string at the end as indicated in the man page. > > Is there any way to get a postscript file to be executed in a window? > "psh" works on stdin (thankfully), but it just writes on the background -- > you have to move all your other windows out of the way and damage is > not repaired. psview is your best bet. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."