Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!ucla-cs!sdcrdcf!trwrb!cadovax!keithd From: keithd@cadovax.UUCP Newsgroups: comp.sys.amiga Subject: printer.device from HELL Message-ID: <1377@cadovax.UUCP> Date: Tue, 3-Feb-87 14:28:14 EST Article-I.D.: cadovax.1377 Posted: Tue Feb 3 14:28:14 1987 Date-Received: Thu, 5-Feb-87 03:48:39 EST Reply-To: keithd@cadovax.UUCP (Keith Doyle) Organization: Contel Business Systems, Torrance, CA Lines: 155 References: Keywords: Ok gang, Here's the latest in the printer saga. After further exploration, I've discovered that indeed the 'printer.device' DOES do the re-sampling, and not the application as I previously thought. >>My guess is that it is spending most of it's time in the 'printer.device' >>re-sampling the image to fit whatever is selected as margins in the >>preferences. >The printer.device does not re-sample the image. >And you can get no scaling just by making the right call to >the DumpRPort function. >All you have to do is either write a screen dump program, or modify >one of the ones on the fish disk. > andy finkel Well Andy, DumpRPort does a DoIO to the 'printer.device' to do this, and IS doing the scaling (i.e. re-sampling). I discovered this by wandering through the RKM and writing a test program that does a screen dump. While doing this, I also discovered, after comparing notes with a friend, that the Addison Wesley RKM manuals have a couple of extra notes under 'printer.device' and most notably under the PWD_DUMPRPORT section. Where the 'special' flag is discussed, the Addison Wesley RKM has several extra notes that are not even in the latest (that I've got ) Gamma 1 Autodocs, though the date on the Addison Wesley manuals is June '86. And, since I never got either release 1.2 Autodocs OR ANY NOTICE OF THEIR AVAILABILITY, I'm kinda wondering what's going on (I know, I'm a low-class developer, I didn't make it to the last developer's conference). I haven't heard squat since Gamma 1 about any kind of updates except the bits and pieces here on the net. I've also been wondering what ELSE is not in either my original RKM or the Gamma 1 Autodocs that might be in Addison Wesley or somewhere else. At any rate, here is what I found about the 'printer.device'. There is a sample program to do a DumpRPort, that does a DoIO to the printer.device with the PWD_DUMPRPORT command. This causes the printer.device to do the print based on several parameters passed with the command. You pass it the source height and width, destination columns and rows and the 'special' flag. The printer.device will re-sample (maybe I should say 'scale', but it 'scales' the image basically by re-sampling) the source to fit the destination size, and do the print via the printer driver. It's the 'scaling' or 'resampling' distortion that I find so objectionable particularly when printing text as graphics, which is the only way you can get special fonts and proportional spacing etc. Note however, that with higher resolution printers such as the LQ-800 or any laser printers, the scaling distortion is not as noticeable, it's just with the lower FX-80 resolution printers that it sticks out like a sore thumb. There are various special cases available. If you set DestRows and DestCols to 0, it will print a 'full size' image based on preferences margin width. Of course this is based on character size, which seems pretty meaningless when character size varies from font to font and within a font if you are using proportional spaced fonts (how 'wide' is a character on my laserprinter when I've got font X selected?). If you set DestCols or DestRows to either -1 or -2, you get half or double size. If you turn on the ASPECT, FULLCOLS, and FULLROWS in the 'special' flag you seem to get pretty much the same thing if you set DestRows and DestCols to 0, that is a 'full size' image based on preferences. You can also set flags in 'special' to tell it to use 'mils' or 1000th of an inch values instead of 'pixel' type values. You also send it the color map, but have no other control over dithering, or color/b&w/greyscale selection, that's out of preferences. In addition, since the example programs use DoIO instead of SendIO, the command will go off and print until finished, not allowing the calling program to regain control and to check for an operator abort of the print job. This is probably why many of the earlier versions of programs that print out there don't allow you to abort the print. I did some experimenting, and if you do a SendIO to do the rastport dump, you can subsequently do a CMD_FLUSH to kill the print later with another SendIO. Though I didn't receive a return message from the CMD_FLUSH at that point, I did get a message returned from the original PWD_DUMPRPORT command (or was it the other way around? I'm not sure. I only got one message back anyway). Unfortunately, what happens, is many of the applications don't do a DumpRastPort of the entire screen, they divide it up and do it in smaller sections, probably to save on the memory usage. When you take the printer offline in an attempt to kill the print job, the printer.device detects that. If it does tell the application that you 'canceled' the requester (which I'm not even sure it does) then most applications are not paying attention, figure that the printer was done with the previous section, and then proceeds to send a PWD_DUMPRPORT command for the next section, which you have to 'cancel' again and again and again etc. The bottom line? The 'printer.device' does TOO MUCH without giving the operator control over what it's going to do. It assumes that the application is going to feed it what it needs. Unfortunately, I only know of 1 applicatin that bothers to ASK THE OPERATOR what he wants out of it, and that is DPaint II. What I want for most packages that I use (Dpaint I, NotePad, PageSetter) is to 'force' DestCols and DestRows to either 640x400 or equivalent (they may be printing in sections, so the 400 vertical may need to vary based on the size of the sections). I think the printer.device should 'Go Directly To TRASH, Do Not Pass Go, Do Not Collect $200'. I'm going to investigate either 1) a total rewrite, or 2) a 'patch' program (a 'new' preferences) that allows one to intercept and modify the parameters being sent the device driver from the application. In the meantime, we here have hacked out a little program youse out there may find useful. It's a version of ScreenDump that allows you to set the DestCols, DestRows, and Special parameters explicitly, which provides a little better control over what kind of output you get. You can make it any size you want then, and try all of the options documented in (at least the Addison Wesley version) of the RKM. After we finish tweaking it to reasonable satisfaction, I'll post it. It would be nice if we could get some support from Commodore on this one, to ENCOURAGE us to come up with a better printer.device by perhaps making the source available, rather than having to hack out one on our own, or worse, getting lazy (this is not really why I bought an Amiga, to re-write the printer.device) and just hacking out a 'patch' program. Or maybe THEY (C/A) would sign up to make it better. So far, 'better' seems to be the ScreenDump program. Besides, 1.2 is out, we're DONE now. (?? or so it seems??) I'd like to see the 'printer.device' pop up it's own requester and ask the operator what it wants it to do. Since many applications call it to print 'sections', it would need some kind of 'first-time', 'time-n' flag that would allow you to either set the parameters for the entire print process, or stop at every PWD_DUMPRPORT call and allow adjustment depending on the task at hand. In addition, a better 'cancel' mechanism that would continue to signal 'done' or 'cancelled' or whatever until the calling application is done with all it's sections (and hopefully does a 'close' on the printer device). And, leaves a requester available to 'cancel' print if the application dosen't bother to give you that option after you've started it up (which wouldn't require you to drop the printer offline to get the requester). In addition, I'd like a means to experiment with 'alternate' dither patterns (random vs ordered dithering etc.) within the context of some of the existing programs I have (Dpaint, PageSetter etc.) which are going to talk through the 'printer.device' to do their output no matter WHAT collection of fancy ScreenDump programs I may have on hand. I can't see having to re-write everybodies output routines (expecially PageSetter) that may not be using IFF or standard screen size just to get the kind of output I want. So far the ONLY program that can print PageSetter output files is the PageSetter program itself. Andy, am I expected to write my own ScreenDump program for them too? Sorry for the flames, I'm just trying to get from point A to point B. Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa