ravi@mcnc.org (Ravi Subrahmanyan) (08/31/89)
I have a question re. dumping a window on a color display to a postscript printer. The window is a black on white window. I've tried doing something like (with suitable options) xwd | xpr -device ps | lpr I've tried the various options for Z and XY pixmap formats, etc., but what ends up happening is that by the time my color window shows up as a postscript file (if I look at the file instead of piping it to lpr) the file's bitmap definition has all 0's or all 1's, which gives me a black black square, or a fully white square on the page. I was able to use the recently posted "xwps" program, after changing it to output "00" for black, and "FF" for anything else, which is Ok for black and white windows. However, "xwps" dumps out 2 bytes for each pixel, which produces rather large PostScript files. "Xpr" produces much smaller PostScript files, but I don't understand enough of what it is doing to modify it suitably. I think what would really help is a utility that will take a color image and convert it to a monochrome image (say with user supplied thresholds for r,g,and b, like the sun rastfilter8to1 program which takes a sun screendump from 8 bitplanes to 1.) Does something like this exist for X? I thought I'd try to write one, but I got stuck right away because XCreateImage wants to know the display type, and I didn't know how to tell it that I have a monochrome display instead of what I really have. I'd appreciate any tips or pointers to existing code anyone could pass on. Thanks, -ravi ~
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (08/31/89)
I think what would really help is a utility that will take a color image
and convert it to a monochrome image
xpr will have color-to-grayscale conversion support in R4.bchen@esvax.berkeley.edu (Benjamin Chen) (09/01/89)
However, "xwps" dumps out 2 bytes for
each pixel, which produces rather large PostScript files. "Xpr" produces
much smaller PostScript files, but I don't understand enough of what
it is doing to modify it suitably.
I originally wrote the X10 version, and since been "ported" (mangled,
acutally) by a friend of mine to X11. The PostScript *image* facility
accepts values from 0 to 255, so only a byte is really necessary for
each pixel. The X10 version does this precisely. Are you certain that
the X11 version insists on outputing a two-byte image? I'm looking
at the source right now, and it looks like it takes only one byte of
info. I guess you could mean that the two hex characters which describe
one byte is two-bytes, but I don't see another way around this.
What might be a good optimization technique is to have an option
for using a scanline algorithm on "simple" windows, i.e. windows with
only a few shapes or lines drawn in them. Oh well, I guess R4 will
have reasonable support for this, so the program may become somewhat
useless.
BC
Benjamin Chen
Office: 550-A4 Cory Hall, 2-4332
UUCP: !ucbvax!esvax!bchen
HEPNET: LBL::"bchen@esvax.Berkeley.EDU"