Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!dog.ee.lbl.gov!ucbvax!agate!stanford.edu!leland.Stanford.EDU!elaine18.Stanford.EDU!dhinds
From: dhinds@elaine18.Stanford.EDU (David Hinds)
Newsgroups: comp.sys.sgi
Subject: Re: Fooling with 'tops' and 'imgexp' utilities
Message-ID: <1991Apr13.013820.1528@leland.Stanford.EDU>
Date: 13 Apr 91 01:38:20 GMT
References: <1991Apr10.010515.19951@leland.Stanford.EDU>
Sender: news@leland.Stanford.EDU (Mr News)
Organization: Stanford University - AIR
Lines: 28

In article <1991Apr10.010515.19951@leland.Stanford.EDU> dhinds@portia.Stanford.EDU I wrote:
>I'm curious about the parameters for the 'tops' program.  I remember reading
>that the default halftone screens on Laserwriters were very nonoptimal; are
>there some values that work better with 'tops', or are its defaults as good
>as they can be?

To answer my own question, there is an article in the July 1990 BYTE on how
to choose the halftone screen parameters.  The screen set by 'tops' isn't on
their chart, but by extrapolation, it looks like it might even be worse than
the default on the Laserwriter.  They recommend several sets of parameters:
106-spot-per-inch/35-degree, 85-spot/35-degree, and 135-spot/25-degree.
These offer fewer grey levels than the default values, but they look so much
smoother than the defaults that there is no comparison.  These parameters
should work well on any 300dpi printer.

>Also, I can't seem to get a plain white background with my
>printed images.  I used the 'invert' program to flip the screen black to
>white, but it comes out as a sparse dot pattern on our laser printer.

The 'tops' program doesn't seem to want to produce images with plain white
areas.  When I convert an 8-bit greyscale image with values 0..255 according
to 'istat', I get a Postscript file with pixel values 0..254.  If I invert
the image and repeat, I still get a file with values 0..254.  There doesn't
seem to be any way to get plain white (255), though if I simply edit the
image files and look, they clearly contain pixels with this value.

 -David Hinds
  dhinds@cb-iris.stanford.edu