Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!esosun!net1!sdcsvax!hutch
From: hutch@sdcsvax.UCSD.EDU (Jim Hutchison)
Newsgroups: comp.sys.amiga
Subject: (~long) Print Problems (was:  The trouble with the Amiga)
Message-ID: <2373@sdcsvax.UCSD.EDU>
Date: Thu, 18-Dec-86 04:43:49 EST
Article-I.D.: sdcsvax.2373
Posted: Thu Dec 18 04:43:49 1986
Date-Received: Thu, 18-Dec-86 23:52:16 EST
Reply-To: hutch@sdcsvax.UUCP (Jim Hutchison)
Organization: UCSD EMU Project (Educational Microcomputer Unix)
Lines: 63

<>
Why? Why? Why?

Oh no!  Please no more insults about lack of testing or silly innuendo
about programmer lazyness!

Your printer is trying to print an image of what is on the screen.
This seems reasonable, atleast at first.

Q.  Now what if your printer is not the same size/quaility as the screen?
A.  The image is degraded.

    How much or little depends on rendering tricks.  Dithering is one such
    trick.  Thresholding is another.  Theses techniques can be done in both
    color and b&w.

    Text which is not aligned with the scanlines in the printer will look odd.
    Thin lines may disappear, or waver in and out of existance.
    Fine details like fine lines, will become less clear.

Q.  What if my printer is higher resolution (e.g. a good laserprinter), and
    I still have lousy images (compared with the screen)?
A.  If they are B&W images from the screen, then it is the drivers fault.
    If they are color images, then it is a fault in one of the rendering
    techniques (which have known flaws).

    ordered dithering:  If it is ordered dithering, you may get hatching of some
			sort (depending on how fancy they got).

    error dithering (Floyd-Steinberg,etc.): daggers from high gradient regions.

    thresholding:  the purple grapes in a white plastic bag look (try it :-).

    clamping:  intentional noise is lost (e.g. a picture of a yozer in front of
	       a dead TV would have funny looking static). Atleast in the quick
	       implementation I did which is not an end-all.

Q.  How does this relate to this stuff about square pixels?
A.  Sadly, many printers do not have square pixels.

    That is a major bummer.  How do you force them to become square?  You
    apply a rendering technique to map the source bitmap onto the funky
    destination bitmap.  Apparently it is not a simple thing :-).

    Can you think up an easy way to fix it?  Please write me.  Honest!
    If you draw the N scan, using error correction based on N-1, you
    get close, but text will look spotty/jaggy.

    If you order dither based on the color of the source pixels and how
    much of the is in the destination pixel, you also get close, but can
    lose fine lines all together and the text is still not all that hot.


Note:  these a answers to the problem of rendering.  I have not written a
printer driver, and will be unlikely to write one anytime in the near future.

I certainly help this clears up a few problems, sorry if I offended anyone.
As usual, I only represent my own semi-humble self, "but for a few dollars...".

-- 
    Jim Hutchison   		UUCP:	{dcdwest,ucbvax}!sdcsvax!hutch
		    		ARPA:	Hutch@sdcsvax.ucsd.edu
Fig is a 5 stage concept.