Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!cbmvax!andy From: andy@cbmvax.UUCP Newsgroups: comp.sys.amiga Subject: Re: printer.device from HELL Message-ID: <1342@cbmvax.cbmvax.cbm.UUCP> Date: Wed, 4-Feb-87 17:07:24 EST Article-I.D.: cbmvax.1342 Posted: Wed Feb 4 17:07:24 1987 Date-Received: Sat, 7-Feb-87 07:30:29 EST References: <1377@cadovax.UUCP> Reply-To: andy@cbmvax.UUCP (Andy Finkel) Organization: Commodore Technology, West Chester, PA Lines: 261 In article <1377@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >Ok gang, Here's the latest in the printer saga. Warning...more flames on printers ahead...haven't hit 'N' yet ? OK, you've been warned... >After further exploration, I've discovered that indeed the 'printer.device' >DOES do the re-sampling, and not the application as I previously thought. >Well Andy, DumpRPort does a DoIO to the 'printer.device' to do this, and >IS doing the scaling (i.e. re-sampling). > Are we agreed, since the printer.device reads pixels once, that we should call it scaling, or adjusting the size, or ? Re-sampling is a really misleading term for the operation. I never said that the printer.device isn't sc22zaling. Only that it reads pixels once. But enough of this. We have more interesting arguments ahead. >I discovered this by wandering through the RKM and writing a test program >that does a screen dump. I am pleased that you have decided to read the manual. Our further discussions are much more likely to be more profitable. From your previous postings and tales of experimentation and assumption I had the impression you did not have access to the manuals, or developer information. >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 < text shortened > >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). This is a seperate complaint than the ones about the printer driver. But I think its been mentioned here on usenet in the past, as well as discussed on Bix. Anyway, the basic story is, we have a mailing ready to go out to all those on our developer list, and those who've asked about the developer program in the last few months about the new developer support program, and about details like the new autodocs/includes and how to get them. (Basically, soon you will be able to send about $20 to Kim Montgomery, Commodore Technical Support, 1200 Wilson Drive, West Chester, PA 19380, and get the disks sent to you. Watch this space for the official announcement. Or watch Bix. Or wait for your information packet. >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. There's probably other things. The Addison-Wesley manual was the completed version of the Rom Kernal Manual. And, there were reasons that those Gamma disks were marked Gamma, instead of Release. (And I hardly ever say squat. I rarely comment on one's posture. :-) >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 It reads each pixel ONCE. Once. Once. It does not re-sample. It scales. This scaling can be turned OFF if that's what you want. Anyway, the point here is that the printer.device itself is more versitle than the example in the manual. >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. BUT THE APPLICATION MAKES THESE CHOICES. < stuff from the manual deleted> > >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. Nothing says that an application can't use SendIO(). The printer.device is a device. There are a defined list of commands for dealing with devices. The examples choose one way, to illustrate the printer.device. (Perhaps there should have been more examples. There is only a limited amount of time in the day; And, even with its flaws, it was available way back then! I suspect that SendIO wasn't used in the applications for similar reasons...it would have taken longer to program. However, nowhere in the manual is the implication that SendIO() doesn't work with a device.) > >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). CMD_FLUSH causes all pending I/O requests to return with an error. (that's what it says in the manual) It doesn't return an error itself. >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) A false assumption. If you cancel, the printer.device returns an error to the application in the IO error field of the IORequest block. If the application chooses not to respond to this error, that's a different problem. >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. Sounds like a problem with the applications, right ? >The bottom line? The 'printer.device' does TOO MUCH without giving the >operator control over what it's going to do. ATTENTION: The control is in the hands of the programmer of the application. I'm not convinced that all those controls need to be under user control. Some things, like scaling, should be under application control. At some point we have to decide that the people writing the applications have to make the decisions about how their package makes use of the system. They, and not the OS should be ones best informed about what features are appropriate for their package and what features are not. If they get it wrong, let them know. But please don't complain that the operating system is allowing them to make the wrong choices. >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). Well, that's different than what you've been asking for before this. I thought you wanted a way to have no scaling ? Unless you only want it to only work with your 640 dot printer... >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. Strong words. Unjustified, also, IMHO. Well, I'll tell you how to do 2) if you've got the programming skill to pull it off. If you do option 1), you'd probably like to be on your own. >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. Great. Or you can use the one on the Fish disks, the one Carolyn Scheppner posted to Usenet, the one that Perry Kivolowitz posted, or the one on the on the DPaint art disks. (one is on mod.amiga.sources, article id <1733@pucc-j>, the others were posted to net.micro.amiga) >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, Based on your above comment (ie TRASH) it would seem unnecessary (and unwise) to let you have the source. (guess I assumed wrong, up there. Oh well, no one's perfect.)) >(C/A) would sign up to make it better. So far, 'better' seems to be the >ScreenDump program. No, the ScreenDump program is to give you 2 things: 1) it will show you what is actually going on. (and it did cause you to read the manual; certainly a win there!) 2) it gives you, as a user, the ability to make different choices with the printer.device than those made by application program. (So you can see what non-aspect ratio corrected text looks like, for instance) > Besides, 1.2 is out, we're DONE now. (?? or so it seems??) What makes you say this ? Just curious. We (Commodore & Commodore-Amiga) are committed to supporting the Amiga. I've got no idea why you've decided we're done. Nothing I've said, I hope. >I'd like to see the 'printer.device' pop up it's own requester and ask the >operator what it wants it to do. Wait, I thought it was doing too much already ? I could swear I read that earlier... :-) > 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. Major disagreement here. I don't agree that this belongs in the province of the printer.device. That sort of thing is best left to the application. I'm sorry if the applications aren't doing it the way you think is right. > 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). If an application wants to do SendIO calls it is free to do them. And check for a cancel. Having the printer.device decide when the application is finished sounds inappropriate to me, actually. I can see it now...someone would then complain that the printer.device refuses to accept more data after any cancel. Look, the printer.device really has no business having this kind of I/O with the user anyway. (The offline/out of paper requester was added after a LOT of thought) Not only is it big enough already, but that's not its job. > 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 I have this belief about what an application should do. I don't accept the argument that, just because the application doesn't do something, the OS should somehow wedge it in anyway, after the fact. > >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. Wrong! see below for an answer... >I can't see having to re-write >everybodies output routines (expecially PageSetter) that may not be using >Andy, am I expected to write my own ScreenDump program >for them too? No, you don't have to. see below... BTW, have you talked to them ? Found out why they made the decisions they did ? You might find it interesting. And, they might appreciate your input, if you approach them in a friendly manner. It sounds like you are really only looking for a solution for your printers. So maybe writing screen print programs for your applications might also be a solution. but... Look, if you really want to get in there, for any application, but not have to rewrite the printer.device, here's two possible paths: 1) write a printer dependent portion that, on initialization, grab the IORequest block off the stack, and take those parameters and ignore them in whatever fashion you've decided to ignore them. This isn't that hard. This would have to be done for each printer, naturally. 2) make your own skeleton device, call it the printer.device, and change the name of the real printer.device to something else. Your device will get the call, and the IORequest block, and everything. You then change the parameters into anything you want, then call the real printer.device to do the printing. This will work with all of the current printers. > >Sorry for the flames, I'm just trying to get from point A to point B. No problem, sorry for my flames, too. >Keith Doyle andy finkel -- andy finkel Commodore/Amiga {ihnp4|seismo|allegra}!cbmvax!andy /or/ pyramid!amiga!andy Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors. "Never make anything simple and efficient when it can be complex and wonderful."