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.