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: Re: printer.device from HELL Message-ID: <1384@cadovax.UUCP> Date: Thu, 5-Feb-87 21:47:04 EST Article-I.D.: cadovax.1384 Posted: Thu Feb 5 21:47:04 1987 Date-Received: Sat, 7-Feb-87 18:35:07 EST References: <1377@cadovax.UUCP> <1342@cbmvax.cbmvax.cbm.UUCP> Reply-To: keithd@cadovax.UUCP (Keith Doyle) Organization: Contel Business Systems, Torrance, CA Lines: 210 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"