ralph@mit-atrp.UUCP (Amiga-Man) (12/13/86)
The question of why many programs do an exceptionally bad job of printing
out things like fine line graphics and fonts has come up again.
I'm sure the people at CBM can give you the actual details and answers
but I figured I'd just jump in and tell you how I get around this all.
It turns out that the printer driver is mighty smart and capable and
can do everything we need. The problem is that it almost always get passed
the wrong parameters by programs which call it (like DPaint). It seems
the people that write these programs think all we want to do is print
out pretty images with PERFECT aspect ratios. Mind you, I appreciate
the fact that such a thing is very hard to do and thank you for providing
such capability, but, jeese, GIVE ME AN OPTION TO SHUT IT OFF !
--
||
/ \
/~~~~\
The Solution |______|
I use the screen dumper program posted by C Scheppner(sp?) which allows
you to grab any screen or window and dump it to the printer after asking
you all the right questions about "number of input pixels" and "output pixels"
and "printing modes". This indeed gives the cherished 1:1, or 2:1 or whatever,
types of printing that fine line graphics and fonts require. It works.
I suppose I could send out a uuencoded executable.....or just the source...
Heck, is this thing archived somewhere ?
Ralph...a gradual student
"The future's so bright....I gotta wear shades"daveb@cbmvax.cbm.UUCP (Dave Berezowski GUEST) (12/15/86)
In article <569@mit-amt.MEDIA.MIT.EDU> ralph@ATRP.MEDIA.MIT.EDU (Amiga-Man) writes: >The question of why many programs do an exceptionally bad job of printing >out things like fine line graphics and fonts has come up again. etc. etc. etc. >such capability, but, jeese, GIVE ME AN OPTION TO SHUT IT OFF ! > -- > || > / \ > /~~~~\ > The Solution |______| > >I use the screen dumper program posted by C Scheppner(sp?) which allows >you to grab any screen or window and dump it to the printer after asking >you all the right questions about "number of input pixels" and "output pixels" >and "printing modes". This indeed gives the cherished 1:1, or 2:1 or whatever, >types of printing that fine line graphics and fonts require. It works. >I suppose I could send out a uuencoded executable.....or just the source... >Heck, is this thing archived somewhere ? > > Ralph...a gradual student > "The future's so bright....I gotta wear shades" The other thing you MAY want to do here is select 'B&W' mode from Preferences (as opposed to COLOR or GREY-SCALE). COLOR and GREY-SCALE both DITHER the image to get the desired effect, HOWEVER B&W does NO dithering what-so-ever and thus preserves all the pixels. B&W mode can be thought of like a photo-copier with the 'THRESHOLD' value acting like the contrast (or darkness) control. It simply decides which colors will print as white and which colors will print as black. IF one selects an inverted image (ie. black is white and white is black) then the threshold value will flip accordingly. Hope you find this info useful. PS. I agree with you totally re programs not giving the user the chance to 'play' with the printer input values. I've passed my 2-cents worth on to EA, AEGIS, etc re having some sort of printer requestor come up BUT no one has done it yet. Tis a shame. Regards, David Berezowski
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner) (12/15/86)
In article <569@mit-amt.MEDIA.MIT.EDU> ralph@ATRP.MEDIA.MIT.EDU (Amiga-Man) writes: >I use the screen dumper program posted by C Scheppner(sp?) which allows >you to grab any screen or window and dump it to the printer after asking >you all the right questions about "number of input pixels" and "output pixels" >and "printing modes". This indeed gives the cherished 1:1, or 2:1 or whatever, >types of printing that fine line graphics and fonts require. It works. >I suppose I could send out a uuencoded executable.....or just the source... >Heck, is this thing archived somewhere ? It's still in mod.amiga.sources here. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
wagner@utcs.UUCP (12/20/86)
Of course, a lot of the problem seems to stem from the fact that no one really seems to understand how the printer.device really works (aside from Carolyn). It's documented, in a badly worded piece of fine print, in the RKM. Printing is important, guys, even for a video machine. I use DPAINT to draw things. I can't hang the resulting video on the wall. I want to hang the printed output on the wall. I can't. My OKIMATE 20 colour printer can't get the shades even close! No where is the half-toning and dithering of the printer.device adequately described, and I'm convinced it's NOT WORKING! Grrrr..... Michael
daveb@cbmvax.cbm.UUCP (Dave Berezowski GUEST) (12/22/86)
In article <1986Dec20.150147.5558@utcs.uucp> wagner@utcs.UUCP (Michael Wagner) writes: > >Of course, a lot of the problem seems to stem from the fact that no one really >seems to understand how the printer.device really works (aside from Carolyn). >It's documented, in a badly worded piece of fine print, in the RKM. Printing >is important, guys, even for a video machine. I use DPAINT to draw things. >I can't hang the resulting video on the wall. I want to hang the printed >output on the wall. I can't. My OKIMATE 20 colour printer can't get the >shades even close! No where is the half-toning and dithering of the >printer.device adequately described, and I'm convinced it's NOT WORKING! > >Grrrr..... > >Michael As the author of the graphic side of the printer device, let me assure you that the dithering IS working on your OKIMATE-20 printer. You must understand that the final color produced by your printer will depend on the type of paper you use (waxed vs non-waxed), variations in the ribbbons, etc. Also, depending on your monitor and how you have the contrast, brightness, tint, color, etc(wht ever color controls) set, the colors on screen may or may not appear to correspond perfectly to the colors in the printout. Another factor to consider is the medium itself. You view an image on a monitor by the light it gives out, whereas a printed printure is viewed by the light it reflects. Also, there are two types of color mixing going on here (r+g+b) vs (y+m+c and sometimes b). Anyhow, enough of this background stuff, on to the meat. The dithering works on a 4x4 dither matrix which produces 16 possible shades per base color (yellow, magenta, cyan, and black (maybe)). (Your printer doesn't have black, so black isn't used). These base colors are then mixed to produce 16 possible shades of red (y+m), green(y+c), blue(m+c). Since the Amiga's colors have 16 intensity levels (0-15), the translation works very smothly. THE FINAL OUTPUT COLOR IS A RESULT OF HOW WELL YOUR PARTICULAR PRINTER MIXES THE COLORS. Ink jet printers seem to be the best at this as the ink tends to mix before it dries on the paper. The okimate-20 printer can't really mix colors, it simply overlays them. I suppose that since the color is being melted on, that the colors may tend to melt (ie. mix) together, BUT certainly not as well as an ink-jet printer. Your okimate-20 is doing the best it can to represent the colors you see on your monitor (really it is)! I hope that this sheds some light on the subject. Regards, David Berezowski PS. Your okimate-20 produces black by mixing y+m+c. PPS. Another reason cheap (ie. less than several tens of thousands of $$$$) printers can't reproduce colors as well as you'd like is due to a technical limitation. There isn't a 1-1 correspondence between rgb and ymc. That is to say that red may really be yellow + 1.1 * magenta. Since 'cheap' printers don't have the ability to produce variable amounts of the same color, we are stuck at using the 1-1 relationship. I have spoken to serveral printer manf. and they tell me that it will still be years before you see a printer with the above capabilities in our price range.
hutch@sdcsvax.UCSD.EDU (Jim Hutchison) (12/23/86)
In article <1157@cbmvax.cbm.UUCP> daveb@cbmvax.UUCP (Dave Berezowski) writes: > The dithering works on a 4x4 dither matrix which produces 16 >possible shades per base color (yellow, magenta, cyan, and black (maybe)). > (Your printer doesn't have black, so black isn't used). > These base colors are then mixed to produce 16 possible shades of > red (y+m), green(y+c), blue(m+c). Since the Amiga's colors have > 16 intensity levels (0-15), the translation works very smothly. This raises a question in my mind, which way to you push it? 4x4 is 0-16. On a screen I have always favored the lighter image (which means making 15 and 16 full white). Here in the subtractive world of CYM (Oh no, no black!), I presume you lean this way since you can't get real black anyway. Note: CYM mixed is dark grey, not black. 4 bits is 17 distinct values. Not to besmearch your driver, I presume your were just glossing over this common technical problem with the unexpected perversity of powers of 2. How is the dot pitch? You use an ordered dither, I presume. This will result in dotted lines for off-tone text/fonts with narrow charastics. Have you considered applying a clamping algorythm to your dither for cases where people refuse to loose the fine detail, and would rather loose some of the color replication? It's just a thought. -- Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch ARPA: Hutch@sdcsvax.ucsd.edu "The more you drive, the less intelligent you are." - "Repo Man"
daveb@cbmvax.cbm.UUCP (Dave Berezowski GUEST) (12/24/86)
In article <2384@sdcsvax.UCSD.EDU> hutch@sdcsvax.UUCP (Jim Hutchison) writes: >This raises a question in my mind, which way to you push it? 4x4 is 0-16. >On a screen I have always favored the lighter image (which means making >15 and 16 full white). Here in the subtractive world of CYM (Oh no, no >black!), I presume you lean this way since you can't get real black anyway. >Note: CYM mixed is dark grey, not black. 4 bits is 17 distinct values. > >Not to besmearch your driver, I presume your were just glossing over this >common technical problem with the unexpected perversity of powers of 2. > No besmearchment taken. When I wrote the driver I realized that that there were 17 possible combinations but only 16 choices. It works this way: 0 to 14 selects 0(ie. none) to 14 dots in a 4x4 dither pattern, 15 selects 16 (ie. all dots on) in a 4x4 dither pattern. This choice was made as during the development we discovered that the printed pictures tended to be darker than the screen image. Thus (as you suggested) we went for the lighter side of things. >How is the dot pitch? You use an ordered dither, I presume. This will >result in dotted lines for off-tone text/fonts with narrow charastics. > The dot pitch is up to the individual printer driver. The raw color info is fed to the printer dependent drivers and its up to them to decide what do do with it. Regards, David Berezowski