keithd@cadovax.UUCP (02/03/87)
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
andy@cbmvax.UUCP (02/05/87)
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."
keithd@cadovax.UUCP (02/06/87)
Ok, first I'd like to thank both Andy Finkel and David Berezowski for being EXTREMELY patient and helpful with my printer frustrations. David mailed me his phone number (he wrote the printer.device), and I had a fruitful conversation with him that enlightened me on the printer.device's (and the applications) 'role' in life. And Andys last message seems to have arrived at a similar conclusion on how to 'get to point B' in the most effective manner. >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. Ok, I'll buy that. Though I don't believe 're-sampling' strictly implies that the program 'reads the pixels more than once', I'm prepared to change my terminology in the interests of better communication. But for reference, there are terms such as 'down sampling' and the like functions that 'scale' a waveform (can you tell I'm working on a sound application?) in a way that does not necessarily mean scanning the input at the output rate, though achieves the same effect ultimately. Oh well, on to bigger and better things: >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. Yeah yeah, I know, if in doubt, RTFM*. But remember, "Comments lie, CODE never lies". I tend to try to find out what it really does before I look into what it is supposed to do. I usually do get around to looking at the manuals eventually, it is not always my first response though (as you have seen). I suspect from what I have seen of the applications we are discussing here, that many of the applications writers have that approach as well (maybe I'm somewhat typical there?). > (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'm ready, where do I sign. Actually, I do remember that Carolyn had posted a message to the effect that she was working on some kind of information packet or something to let all of the 'sleeper' developers in on how to upgrade their Lattice, and the like. I just ran into a situation where I noticed I was getting a little behind (now that I finally got around to RTFM) and thought I'd see if anyone else was having similar problems. >Anyway, the point here is that the printer.device itself is more >versatle than the example in the manual. Yes, after talking to David, I came to the same conclusion. The printer.device itself is VERY flexible. It seems that Commodore expected the applications writers to RTFM, understand fully what the role of the printer.device is, and make sure they provide user access to the flexibility found there. Unfortunately the only applications writer I have been able to identify who has actually done that is Dan Silva, author of DPaint II. It would seem that most of them simply copied the DumpRPort() sample routine out of the RKM without taking the time to understand what 'printing on the Amiga' is all about (or was intended to be all about). Except for a few even more bizzare cases (Printmaster Plus) where they bypassed the printer.device completely and provide their own printer drivers (and good luck getting a driver for any printer that's not in their package, they don't have an 'RKM' equivalent to even tell you how their drivers work). > 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. Yes, but unfortunately, it IS a problem. >Sounds like a problem with the applications, right ? Yeah, and maybe a just a little bit a problem with Commodores expectations of the developers (to pay attention and do it right). Me... >>The bottom line? The 'printer.device' does TOO MUCH without giving the >>operator control over what it's going to do. Note: Based on what I now know about the printer.device, I no longer feel this way. >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. Well, I'm not sure I agree that scaling should be exclusively under application control, this is the one thing that most of the applications (and in my opinion, that includes NotePad) are doing WRONG. Scaling is fine, but with may of the lower-resolution printers, the only way to get decent looking text is to turn it OFF or make it strictly 2:1. For my favorite example, try this experiment: Set the printer preferences Left Margin=1, Right Margin=80, and 10 CPI. Use the standard Amiga supplied Epson driver (and an Epson compatible printer. This experiment will probably work with any other lo-res printer {around 80 dpi}). Using NotePad, select Topaz 8 font. Open up a full screen window, and fill a screen with capital H's. Now print it. Stand back from the printout about 2 feet. See the white vertical lines about every 7 characters? Now take a closer look at some of the H's. Look at the right vertical line on the first two H's on the page. Notice the difference in thickness? This is caused by the scaling that the printer.device is doing. I've also discovered, that no matter HOW you set the margins, set the CPI and patch the printer driver's x and y dpi (dots per inch), you can't always get what you want. I found that I needed to set the y dpi somewhere BETWEEN 65 and 66 in order to get no vertical scaling (or rather strictly 2:1 scaling) and eliminate objectionable scaling distortion. >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. Ok, you give them enough rope, and they hang themselves. I'll buy that, I don't want to trade away the OS flexibility either. And the printer device/driver section of the Amiga certainly does have the flexibility to be much better than what you get with the Mac or PeeCee. So you guys have decided that the applications writers have to make the decisions about how their package makes use of the system. Unfortunately, it seems that they could use a little help in a couple of areas where they may not even realize they need help (and so haven't been asking for it). >>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... No, actually I want to 'force' DestCols and DestRows in order to do NO scaling or aspecting (i.e. strictly 2:1). That's just one way I determined that it might be done. talking about screen dump programs... >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) I musta missed that one, either that or its on one of my 30+ disks of various public domain/bbs/usenet/fish stuff somewhere (just don't ask me where, does anyone know if the disk cataloger in the fish library is any good?) >> 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. All the reports of burning 1.2 into PROM in the new versions of the Amiga. But then maybe I mis-interpreted them. >> 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. I don't think it really belongs in the province of the printer.device either, but there's only one of them, and countless applications that are doing it wrong. From my point of view, it's easier to modify one printer.device than umpteen application programs. Practicality and need takes presidence over 'elegance' in this case. >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. I have this belief that if you need to get a job done, you do whatever it takes. If there are multiple options, you pick the best one (and the definition of 'best' depends on the context) and get on with it. If that means 'wedging' something after the fact, so be it. >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: >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. Last night I pretty much came to this same conclusion. This should do the trick without having to either munge the existing driver, or hack out a new one from scratch. Sounds pretty easy and relatively clean to implement too. AND, I don't have to have a whole series of oddly patches drivers floating around to get confused with. I think we have a winner. I am going to further investigate. > andy finkel >"Never make anything simple and efficient when it can be complex and wonderful" Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa "Less is More"
andy@cbmvax.UUCP (02/07/87)
In article <1384@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > >Ok, first I'd like to thank both Andy Finkel and David Berezowski for >being EXTREMELY patient and helpful with my printer frustrations. David >mailed me his phone number (he wrote the printer.device), and I had a >fruitful conversation with him that enlightened me on the printer.device's >(and the applications) 'role' in life. Well, I'm glad we're all in agreement here. (And I'm surprised you thought I was being patient; I'd come to the conclusion that I was getting a bit too acid, especially with someone who is trying to understand the stuff. well, anyway, as long as the tone was ok...) Anyway, I'm glad Dave explained the logic behind the graphics portion of the printer.device; that third of the device was essentually his 'baby' so you got the straight scoop. Good luck on your interception.device. >Keith Doyle >"Less is More" -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore/Amiga /or/ pyramid!amiga!andy } "Do not meddle with the affairs of wizards, for it makes them soggy and hard to light." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
wagner@utgpu.UUCP (02/10/87)
In article <1384@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > >The printer.device >itself is VERY flexible. It seems that Commodore expected the applications >writers to RTFM, understand fully what the role of the printer.device is, and >make sure they provide user access to the flexibility found there. This point was made some time ago in this discussion. The printer.device is under-documented for the level of sophistication that is in it. It is only now somewhat documented in the Rom Kernel Manuals, and it seems that most developers didn't have/didn't read the RKMs beyond the stupid overly simplistic examples. >Unfortunately the only applications writer I have been able to identify who >has actually done that is Dan Silva, author of DPaint II. And he sure didn't in DPaint I! >It would seem >that most of them simply copied the DumpRPort() sample routine out of the RKM >without taking the time to understand what 'printing on the Amiga' is all >about (or was intended to be all about). Actually, the part that seems the most unfortunate to me is that many unsophisticated users will see the lousy results that the combination of Amiga+expensive.printer+stupid.developer produces and go get a mac. Remember, Andy, while you and Keith are arguing over whether it is the printer, the driver, the .device, the application or the OS that blew a particular screen dump, the fact remains that the end user neither knows nor cares...he didn't get the results he can now get from decent packages on other machines. Most auto buyers just notice that the car is too slow or too awkward...they don't wonder if the fault is in the engine division or in the transmission division of the auto company. And a transmission that can accept many different engines and provides flexibility for the future isn't a feature for any but the most sophisticated buyer. Most buyers are just buying a package. It either all works together or it doesn't. I agree that the problem is (mostly) with the applications not using the power of the printer.device properly. But I feel that C-A has not done enough to keep the developers informed in this area. You guys had style hints on using Intuition in the manuals. How about a 'how to use the printer.device to get the best results' section? I do think, however, that there is no great sin in allowing the user access to features. You warn him that his picture may look different if he plays with these sliders, but you let him do it. ITS HIS DATA, DAMN IT! I designed and built (from, basically, off-the-shelf parts) a mainframe system where one of the philosophies was borrowed from micro land...don't get in the way of a user with a job to get done. We relaxed quite a number of stupid restrictions that the original system had. Some new features didn't seem like they would be a lot of use. Some of them we put warnings at the entrance to. But we let the user do it. I'd like to see the printer driver allow touch-up of the colour map before the output went to the printer. I complained months ago that the colour dithering was wrong on my OKIMATE-20. I've gone to the trouble, in the mean time, to look up references and buy a text on the subject. I now am starting to understand why this is a complex problem. Given that the text gives 4 competing algorithms for doing this, and claims that none of them work properly for all pictures, how can you claim that an algorithm with no parameterization is doing it right? Actually, I'm glad that Keith was more persistent than I was. Perhaps it's because he's actually trying to develop something, while I'm only here to play. I'm glad Andy suggested that the printer.device could be front-ended. I was thinking about doing this, but lacked the knowledge to determine, a priori, that it is technically feasable. I've written some ugly application-level code to get the results I wanted out of my dot-matrix printer. I was thinking of posting it, and letting other, more systems-oriented heads insert it in the right places in the driver code. Perhaps this would be a good place to talk about enhancements I would like to see for the printer support on the amiga. 1) Printer spooling in the printer.device. User selectable choice of spool file naming (so it could go in ram or hard-disk, if those were available). Tunable buffer-size options so that seeking back and forth to the spool files could be minimized. 2) Support for port expansion devices on both the serial and parallel ports. A preferences item (submenu) would let you set up the strings used to select the various ports of your port expansion box. Support at the DOS level would be multiple, virtual printer devices. In fact, other devices hung off the parallel and serial ports could also be represented as virtual hardware, I suppose. 3) It should be possible to output to the printer using the same (type of) calls used to send graphics output to the screen. In fact, I do (almost) this in one application. You open a virtual printer page, render into it, and then print it. There are problems if a complete page takes more memory than you have (or can BLIT in), but they can be solved using multi-pass algorithms and the support already in LAYERS for superbitmaps and redrawing damaged (unrendered) segments. 4) The application should be able to determine various device-dependent information (like vertical and horizontal resolution, colours available, and so forth....most of the stuff in the printer.tag would be a good start) in a structured way...i.e., a call to the printer.device. 5) The printer.device should understand dot aspect ratios of the printers, and the various special things that can be done with specialized printer drivers. This should include such things as overstriking on impact printers, and the ability to position dots close enough together to overlap. Half-tone algorithms should use overstrike when available. 6) The printer drivers should (perhaps optionally, perhaps tied to the draft/final flag) use higher resolution modes when available. For instance, the Epson driver should use the 216DPI resolution. It's REAL slow compared to the supplied version, but the results look MUCH better (and my driver is still nothing like the 30 minutes Keith was talking about). 7) The printer drivers should all compress out large sections of white space. This could be done with a supplied piece of code in a library, to cut down on the amount of reinventing of graphics wheels that needs to be done. This can be expected to be a win, because every byte sent is an interrupt. 8) The printer drivers should probably allocate their buffer storage in CHIP ram, and use the blitter to clear it after each use. If you have expansion memory, you surely can afford the CHIP ram and would like the speedup. And if you don't have expansion memory, you haven't anything except CHIP ram, so you're already doing it. 9) If the supplied code in the RKM is production, the printer drivers should probably be corrected to not set every bit twice using two slightly different codings of the same algorithm. 10) Perhaps some performance analysis of the printer.device/printer driver interface is called for. I suspect that one or two more calls to handle cases where significant amounts of redundant information is being sent might speed things up a fair bit. For instance, a call which says to set positions x=10 to x=900 in the same scan line all to one colour would save 890 function calls, with all the overhead involved. Instead, a tight loop of a few instructions per bit. Hmmm...I had some more ideas, but I can't seem to recall them at present. Well, after all, it is 4 in the morning. And this article is getting long enough already. More later, if I remember any more. Oh, actually, a few comments for people trying to write printer drivers from the RKMs. They forgot to tell you a few things. You must compile the code with stack checking turned off. Neither the Fish CC nor the Lattice LC front-ends let you specify this. You have to call the phases yourself. You don't really need c.o (or [AL]startup.obj, as they used to be called). You do have to supply a few funny things that I stole from c.a just to get it to link. I don't remember them off the top of my head. And I couldn't find any good reason to keep data.c separate from dospecial.c, so I put them together. I found that the initialization code (which was all I really needed dospecial for, anyways) merely chose to send strings that were already defined in data.c; it made sense to combine them for readability and reduction in data size. Dospecial seems to be able to perform all sorts of magic with setting the return code... never figured out what they all meant. Some documentation in this area would be really handy. The render.c entry codes in the code are numbered differently from the text description, and master initialization is not described in the text. The only example that uses master initialization uses it to clobber values in printertag.asm. This practice begs the question of when those values have meaning, and who is allowed to look at them, and when they have to be kept consistent, and so on. Need more doc here too. It also would have been handy to have, somewhere, a list of what the preference settings related to printing are supposed to mean, and who is supposed to honour them. For example, the margins settings seem to be honoured by some applications and not others. Seems like the drivers don't implement that feature. Which means that a plain, ordinary AmigaDOS application using the PRT: device won't honour them (I sent a paper through PROFF three times before I figured out that the knobs weren't connected to anything). I could go on and on (I already have! :-) ). Enough for one night. Michael