Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!snorkelwacker.mit.edu!stanford.edu!agate!ziploc!eps
From: eps@toaster.SFSU.EDU (Eric P. Scott)
Newsgroups: comp.sys.next
Subject: Re: Postscript output resolution - again
Message-ID: <1411@toaster.SFSU.EDU>
Date: 8 Mar 91 08:53:31 GMT
References: <1991Mar7.134221.4577@investor.pgh.pa.us>
Reply-To: eps@cs.SFSU.EDU (Eric P. Scott)
Organization: San Francisco State University
Lines: 61

In article <1991Mar7.134221.4577@investor.pgh.pa.us>
	rbp@investor.pgh.pa.us (Bob Peirce #305) writes:
>Specifically, I am modifying Eric Scott's iwf program to drive an Epson
>LQ-510 under 1.0.  The output resolution is about 60-80 dpi.  In looking
>through the function calls, I have been unable to find any place where
>this resolution is set.  If it is not set, why isn't it 150 dpi? 

iwf images to an off-screen window.  "By definition" that's 72dpi
(even though MegaPixel displays are 92dpi).

>                                          if I understand Eric
>correctly, there are 2-bits/pixel, which determine four levels of grey. 
>Eric assumes any grey is black, so the two bits are converted into a
>black or a white pixel for printing.

You missed a very subtle point... (iwscript fell into this pitfall)
Off-screen windows under 1.0 are always 2 bits deep.  If there was
some way to get 1-bit, PostScript would do all the hard work for me.
Fortunately, there's an easy way to do this: I use a linear
transfer function to map the whole range of gray values to the
range of the least significant bit:

BLACK		DKGRAY		LTGRAY		WHITE
|		|		|		|
0		1/3		2/3		1
	.	      .	     	    .		.
		.	   .	      .		.
			.	.	.	.
				LTGRAY		WHITE
				|		|
				2/3		1
"blacker than black"		black		white <-- on paper

If you look at the file iwwraps.psw you'll see some lines that
say "for debugging" that are commented out--if you build iwf with
those uncommented, you'll see exactly what's going on.

>As a result, I have a program that works, but I do not understand why it
>generates the specific resolution it does.  The output resolution is not
>sufficient, but I don't know how to get more.

The same way you "zoom in" on something--with a scale operator.
The only catch is that the hand-tuned bitmap fonts will no
longer be used (you're presumably doing an anamorphic scale?);
this will affect speed and the appearance of small type.

>When I go to 2.0 I have the potential to get very good resolution but I
>don't know what I will have to do to get it.  For that matter, I don't
>even know what I will have to do to make this program work under 2.0.
>Certain threads in this group suggest it won't work at all.

I still haven't investigated exactly WHY it doesn't work (I
suspect it's related to the variable resolution stuff that
"broke" lpr to non-NeXT printers in general).  In any case,
there are some nifty new features in 2.0 that (1) let me
render 1-bit deep with the correct PhotometricInterpretation
at a chosen resolution (2) provide more robust handling of
PostScript errors.  The program gets more complex, but also
more efficient since there's less data manipulation.

					-=EPS=-