[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

3566.0. "Postscript printscreen to non-DEC printers?" by PEACHS::MITCHAM (Andy in Alpharetta (near Atlanta)) Thu Nov 01 1990 13:35

DECwindows supports doing printscreen to DEC postscript printers; do we support
this function going to non-DEC postscript printers?  Let me explain...

A customer has two postscript printers:  an LN03R and an HP-Laserjet III 
with postscript cartridge.  He can printscreen to the LN03R but not the HP
printer.  Indication on the printer is that it's processing the data but it
stops eventually and nothing is printed.  I've seen two things happen at this
point:  1) the printer may clear the indicator and wait for the next print
job, or 2) the printer may get an error (error 16 to be specific).

Customer can do capture screen to DDIF of identical data and CONVERT/DOCUMENT
this file to postscript, then print it to HP printer without problem.

Looking at the postscript code generated by printscreen and convert/document,
there appears to be a bit of difference.  Without getting into the bits and 
bytes of it, I'd venture to guess the problem is related to the postscript
code being generated by printscreen.

(I'm grasping at straws, here)

I assume that all generated postscript code should be done to some Adobe 
standard.  Could it be that printscreen doesn't meet this standard completely?

The HP printer is operating properly.  They can consistantly print other 
postscript files without fail.

Comments? Pointers?

-Andy

FWIW:  I've seen this occur with Apple LaserWriter printers as well.

T.R	Title	User	Personal Name	Date	Lines
3566.1	more info needed	CVG::PETTENGILL	mulp	`Fri Nov 02 1990 22:40`	8
	Since DECwindows does NOT support PRINTING, we have no idea how you are printing to the printers. If you are using CPS, then you are more likely to find answers in the hannah::postscript_printing conference. If you are not using CPS, then I hope you are using some sort of print symbiont that returns the error messages that are being returned by the postscript interpreter in the printer. These will tell you what it is having problems with.
3566.2	Maybe try asking DECimage	AIRBAG::SWATKO		`Mon Nov 05 1990 16:28`	15
	DECwindows PrintScreen relies on DECimage to generate it's postscript from the screen capture. Here's a guess... At one point in time, DECimage-generated PostScript used binary data (as opposed to ASCII characters) in the generation of the images. If DECwindows PrintScreen is still using the version of DECimage that uses binary data, the problem could be that the HP printer is choking on the binary data. Adobe recommends in the "Red book" that software developers not use binary data but DECimage did anyways. Also, DECimage used to write out its data in a weird record format that could also cause problems with data transmission. Good luck. -Mike
3566.3	Here's how CONVERT/DOCUMENT works	DDIF::MUNYAN	Steve Munyan, ZK2-2/O23, DTN 381-2264	`Mon Nov 05 1990 23:31`	13
	CONVERT/DOCUMENT to PostScript uses DECimage to generate the PostScript output. My guess is that .2 has the right idea. Note also that the CDA PostScript Converter will reformat the output returned by DECimage such that it fits within the width specified in the Options File (if any). If no options file is used a default value of 132 columns is assumed. Steve CDA Viewer CDA PostScript Converter
3566.4	Not really a DECmumble software issue. More likely an SPD/SSA issue anyway.	IO::MCCARTNEY	James T. McCartney III - DTN 381-2244 ZK02-2/N24	`Mon Nov 26 1990 15:48`	18
	My cut on this problem is that it is identical to those we experience when asked by customers: "My DECforms/FMS/TDMS application won't run on my mumbly- fratz-VTxxx clone. What's wrong?" Our answer is always the same, check the SPD and SSA documents and see if we list "mumbly-fratz-VTxxx" as a supported terminal. If not and the problem is reproducable on one listed in the SSA, the the bug is in our code, otherwise the bug is in your terminal/printer. I'm pretty sure that we (Digital) take(s)s the same position regarding Postscript printers. We can't be resposible for all the (partial) implementations of Postscript that might be embedded in who-knows-whom's printers. This is especially true of the Apple boxes. Last time I looked in the Postscript red book, there was a special section devoted to how Apple differs/extends the standard. Nor would I be supprised that your customer might be running into a memory/resource exhaustion in the HP box. James