[comp.windows.x] Can anyone xpr to a LaserJet out there?

DEG41560@UA1VM.BITNET (Rob) (01/13/89)

Well, I think I've tried everything.

 I've tried hpxpr from the distribution and xpr.jet from expo/contrib,
both of which compile, but give me "Cannot read window name" when I
try to print an xwd file.

 I've tried xwd: xwdtopbm :pbmtolj, which gives me a garbled image.
(Note that this worked under Xten!)

 I'm running under Ultrix 2.2 on a VAXstation 2000...

So, what's the deal?  I'd at least like to understand what the problem is.


                                         Thanks for any Info,

                                               Rob.

ler@hpfclm.HP.COM (Larry Rupp) (01/18/89)

I think you're seeing a problem the DEC server has with getimage.  Here is
a note I posted about this last August. (Never got any responses.)

I'm stumped on the window name length anomaly.  You could try dumping an
unnamed window with xwd; this will force the name in the file to "xwdump",
bypassing XFetchName.  If XFetchName is not correctly setting the null byte
for string termination it could explain the behavior you've seen.

Larry Rupp	(ler@hpfcla.hp.com)


Text of note posted 8-31-88:

> While testing some work I've done on xpr I have run into a problem with xwd
> files created using the DEC GPX server that came with the R2 distribution.
> 
> The xwd file header (and XImage structures too) contain the image's width
> and bytes_per_line.  Bytes_per_line may be >= width.  I believe that the
> DEC server is correctly setting these values and then proceeds to ignore
> bytes_per_line when shipping out the image bytes.
> 
> 	Example:	(ZPixmap format, pixel = 1 byte)
> 
> 		width = 6, height = 2, bytes_per_line = 8
> 
> 		I = image pixel,  P = padding pixel,  ? = unknown
> 
> 	    image seen:		IIIIII
> 				IIIIII
> 				????
> 
> 	    image expected:	IIIIIIPP
> 				IIIIIIPP
> 
> 	(The Sun and HP servers produce the expected image.)
> 
> From reading xpr it looks like the code that handles the DEC and postscript
> printers *also* ignore bytes_per_line!  This would explain why nobody has
> noticed this before.  The xpr code for the IBM page printer appears to
> observe bytes_per_line so I would expect the DEC-server/IBM-printer
> combination to produce strange hardcopy, kind of like a display that has
> lost horizontal sync.