🚀 go-pugleaf

vac@cs.cmu.edu (Vincent Cate) writes:

    >I want 1 bit on my bitmap to end up as one dot on a 300 DPI
    >postscript printer, but my printer seems to still mess with
    >the bits.

If you want to address the pixels of the output device directly
you can change the CTM with:

	matrix setmatrix	% = [1 0 0 1 0 0] setmatrix

This sets up a 1 to 1 mapping between the user and device space.
At this point the device work space can be determined using:

	clippath initclip pathbbox

Leaving the llx, lly, urx and ury of the output device on the stack.

Another approach is to determine the resolution of the output device.
A simple way to do so is using the "dtransform" operator:

	72 72 dtransform	% (1,1) inch in device space
	abs /resy exch def
	abs /resx exch def

Using "resx" and "resy" you can scale the bitmap to assure a 1 to 1
mapping.

    >I have a pbm file that I am to printing on a 300 DPI printer.
    >pbmtops defaults to a times 4 scaling (one bit in the pbm file
    >goes to a 4 by 4 group of dots on the printer), and I want 
    >1 for 1, so I use "pgmtops -scale 0.25".  This does get my
    >1800 by 3000 bit pbm file to come out to 6 inches by 10 inches,
    >like it should.  However, there are all sorts of artifacts
    >as if the printer had to scale the image.  The printer is a 
    >DEC lps40.  

I looked at the PostScript file as generated by the command "pbm2ps 1"
and noticed some things which might cause (your) problems:

    %! PBM to PostScript
    0.24 0.24 scale
    /picstr 32 string def
    1142 1372.5 translate
    416 405 scale
    416 405 1 [ 416 0 0 -405 0 405 ] { currentfile picstr readhexstring pop }
    image
    ffffc01ffffffffffffffffffff007ffffffff803ffffffffc01ffffffffe00f
    [bytes deleted...]
    showpage

The idea of the ".24 .24 scale" is to create a 1 to 1 mapping for
a 300 dpi output device (.24 * 300 / 72 = 1).
An obvious drawback of this approach is that it doesn't make
sense for non-300dpi devices.
A simple fix would be to determine the resolution first (see above)
and then scale according to:

	72 resx div
	72 resy div scale

In this case the line containing the "translate" should be changed to:

	1142   resx mul 300 div
	1372.5 resy mul 300 div translate

The second reason why this prologue may not give the best results
is that the user space is not "snapped" on the device space.
This can be fixed by "snapping" before translating:

	1142   resx mul 300 div
	1372.5 resy mul 300 div snap translate

where snap is defined as:

	/snap {
	    %
	    % x y snap --> x' y'
	    %
	    transform
		round exch
		round exch
	    itransform
	} def

These changes should assure that the bitmap is printed without any
distortion on any output device.
An obvious drawback of the applied changes is that the image will
have different sizes on devices with a different resolution but
that can't be helped.

    Jan van der Steen
--
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
     Jan van der Steen                 jansteen@cwi.nl
     Centre for Mathematics and Computer Science (CWI)
     Kruislaan 413, 1098 SJ Amsterdam, The Netherlands