keithd@cadovax.UUCP (Keith Doyle) (01/13/87)
References:
.........
A couple of friends of mine have recently bought Epson LQ-800's for their
Amigas. We found a driver on Compuserve, and the source to one either there
or somewhere else.
Come to find out that a graphics print takes a good 35 minutes.
I know that we are talking a 24 pin print head here, but that's a little
out of hand.
We also tried timing how long a print takes with a driver that has been
stubbed out to do nothing. It seems that it is not in the driver where
it is spending the majority of it's time.
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. While this is an important feature (and not found in the
MacIntosh, you only get x1 and x.5 and a hi-quality and draft mode) it
causes output to be incredibly slow in some instances.
Has anyone re-written a 'printer.device' to not try to re-size to fit,
but just assumes a certain minimum DPI and does a x1, x2, x.5 etc.?
This would be compatible with existing applications (which is important).
I know there are some packages (PrintMaster + for example) that bypass
the Amiga device drivers entirely and provide their own, where the
package will talk directly to the parallel port. Though this is certainly
faster, if your printer is not supported by the application then you
are SOL.
I realize the Amiga's best feature is it's video. And that is why I bought
an Amiga. However, I keep seeing my friends struggle with trying to get
decent print out in a reasonable amount of time. If it isn't DPaint forcing
screen-compatible aspect ratio on the image causing text to look terrible,
it takes days (30+ minutes to print an image is pretty bad, you have to
admit).
So what's the answer? Is it possible to come up with an alternate
'printer.device' that will bypass all of the nifty resize features in
the interest of speed (or text quality)?
And why isn't anyone else complaining about these problems? They seem
to me to be much more significant than the speed of the icon files on
the workbench. Is everyone just using the Amiga for games and video?
I'll admit I think printing and word processing is pretty boring myself, but
I kinda expect any self-respecting computer to do a decent job of it anyway.
Keith Doyle
# {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd
# cadovax!keithd@ucla-locus.arpawen@husc2.UUCP (wen) (01/13/87)
In article <1321@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > >A couple of friends of mine have recently bought Epson LQ-800's for their >Amigas. We found a driver on Compuserve, and the source to one either there >or somewhere else. >Come to find out that a graphics print takes a good 35 minutes. I'm not familiar with the LQ-800, but it sounds like your printer driver has serious problems. 35 minutes is ridiculous. Even the Okimate 20 does it in under 5. >And why isn't anyone else complaining about these problems? They seem >to me to be much more significant than the speed of the icon files on >the workbench. Is everyone just using the Amiga for games and video? We haven't had this problem. Have you looked elsewhere for a printer driver? A. Wen wen@husc4.HARVARD.EDU wen@harvunxu.BITNET
wagner@utcs.UUCP (01/14/87)
I've done some playing around with printer drivers, and it's true that certain combinations of output sizes make things very slow. Unfortunately, I've found out little that can be easily passed on. I gave some thought to re-writing the printer.driver, but it's actually a pretty complex piece of code, and it's not clear that rewriting it for performance alone is worth it. There's some extra function I'd like to see in it as well, and perhaps when I've thought my way through all of that, I'll take a run at it. In any case, I'm about to leave the net for several months, so I guess I won't have anything of interest for some time to come. Michael
acs@amdahl.UUCP (Tony Sumrall) (01/14/87)
In article <1321@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > ... >And why isn't anyone else complaining about these problems? They seem >to me to be much more significant than the speed of the icon files on >the workbench. Is everyone just using the Amiga for games and video? I dunno about anyone else but I'm *not* using it for games, video or as an RJE workstation (i.e. I don't *print* with it--I already have too much paper at my house! :-) >I'll admit I think printing and word processing is pretty boring myself, but >I kinda expect any self-respecting computer to do a decent job of it anyway. Maybe you're one of the few people that are doing those things with it? Maybe not. In any case, I don't think that "icon file speed" is "more important" than print speed nor vice-versa. I'd say that *both* of these things need to be fixed and the reason that you're hearing more about the icons is that it's easier to toss off a "put 'em all in one file" than it is to try and determine the bottleneck in printing. (No, I'm not flaming anyone here...I think it *is* easier to discuss an already open subject.) >Keith Doyle ># {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd ># cadovax!keithd@ucla-locus.arpa -- Tony Sumrall acs@amdahl.amdahl.com <=> ...!{ihnp4,hplabs,seismo}!amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
acs@amdahl.UUCP (Tony Sumrall) (01/14/87)
In article <5144@amdahl.UUCP> I write: >Maybe you're one of the few people that are doing those things with it? >Maybe not. (My mind must be going.) Maybe no one else is having the same problem. -- Tony Sumrall acs@amdahl.amdahl.com <=> ...!{ihnp4,hplabs,seismo}!amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
kaz@cadovax.UUCP (01/18/87)
In article <1128@husc2.UUCP> wen@husc2.UUCP writes: >In article <1321@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >> >>A couple of friends of mine have recently bought Epson LQ-800's for their >>Amigas. >>Come to find out that a graphics print takes a good 35 minutes. > >I'm not familiar with the LQ-800, but it sounds like your printer driver has >serious problems. 35 minutes is ridiculous. Even the Okimate 20 does it in >under 5. > > A. Wen > wen@husc4.HARVARD.EDU > wen@harvunxu.BITNET You missed the point of the original article. It is definitly not the driver that causes the printer to be so slow, it is the printer device. I created a modified driver that did absolutely *NOTHING* (it just did a return(0) in each function) and found that "printing" a simple notepad note using the RUBY font with this nop'd driver still took a super long time. Any graphics dump through the printer device takes much too long regardless of the printer driver you are using. Kerry Zimmerman # {ucbvax,ihnp4,decvax}!trwrb!cadovax!kaz # cadovax!kazd@ucla-locus.arpa
andy@cbmvax.cbm.UUCP (Andy Finkel) (01/18/87)
In article <1321@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >......... > >A couple of friends of mine have recently bought Epson LQ-800's for their >Amigas. We found a driver on Compuserve, and the source to one either there >or somewhere else. > >Come to find out that a graphics print takes a good 35 minutes. > >I know that we are talking a 24 pin print head here, but that's a little >out of hand. > >We also tried timing how long a print takes with a driver that has been >stubbed out to do nothing. It seems that it is not in the driver where >it is spending the majority of it's time. > >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. >MacIntosh, you only get x1 and x.5 and a hi-quality and draft mode) it >causes output to be incredibly slow in some instances. (Remember the Mac has 1 bitplane. We have up to 5) You can also send me the source to the driver, and I'll take a look at it to see if there's anything obviously funny, if you want. >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."
wagner@utcs.UUCP (01/19/87)
In article <1321@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > ... >And why isn't anyone else complaining about these problems? They seem >to me to be much more significant than the speed of the icon files on >the workbench. Well, while I think printer performance is bad, I don't think I've experienced anything near the 25 minutes you mentioned. If I had, I would complain too. Now, I must admit, I have a 64K print buffer, but I can't imagine that would make a difference. Michael
keithd@cadovax.UUCP (Keith Doyle) (01/21/87)
In article <1247@cbmvax.cbmvax.cbm.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >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. Screen dump programs work ok, but that dosen't help DPaint to print any better (or NotePad, or DeluxePrint, etc.) Ok, I think I am finally beginning to put the pieces together as to what is happening: 1) The application program (as in DPaint) does any required re-scaling of the image and passes it to the printer.device 2) The printer.device will: a) check preferences for driver name and related printer params b) do the dithering and/or b&w thresholding based on preferences c) opens serial or parallel device based on preferences d) pass the output to the driver 3) The driver will: a) initialize printer b) do line buffering based on pixel by pixel info from the printer.device c) translate Amiga printer controls to printer dependent controls d) send the output to the printer First of all, is this correct? Are there any important pieces missing? How do the preferences margin widths etc. figure into the equations? Second, I have a couple of friends who want to do things with the system in such a way as to affect ALL Amiga applications that use the printer. In other words, I don't want to use an outboard program (like ScreenDump) that gets the job done by bypassing the usual channels. (1-3 above). One, is we would like to play with alternate dithering algorithms. And two, is we would like to produce a Postscript 'driver' if you will, that makes use of PostScript ability to do dithering at higher resolution in the printer. In addition, to find a way to make use of PostScripts internal fonts in a useful manner. (Like produce a 'NotePad' that tells the printer.device that it's using 'ruby 12' for this font, and have that translate to an equiavlent PostScript font. It would seem the only way to do this kind of stuff is to produce a custom 'printer.device'. Remember, that I want to get the job done WITHOUT bypassing usual channels, because I want these features to work with off the shelf applications that I do not have control over. Is the printer.device written in 'C'? If so, is there any chance that Commodore might make the source available? Trying to completely re-write the printer.device by starting from the generic device handler code that has been floating around looks like a much bigger task. I'd really just hack what we've got rather than re-invent the wheel. Though I still think there are two problems with the existing application- to-printer chain. Graphics print speed (whether or not ScreenDump is used or something else, specifics of which will be forthcoming after we do a few more tests), and print quality, though I've seen that DPaint II seems to provide a more 1 to 1 print capability which allows much better output that I was able to get with DPaint I. This implies that it was primarily DPaint I's problem with printing textual material and not the device or driver. I'm thinking about posting a uuencoded version of my 'test pattern' file that I use to check this stuff out, so any of the rest of you who are interested in the kind of problems I'm referring to here can see what I'm talking about. It's a lo-res IFF DPaint file that has a worst-case pattern that I use for testing and adjusting preferences for best-I-can-get printer output. Though the printer I'm using has a 640 dot width, which ought to translate 2 for 1 from a lo-res picture file, unless I set my preferences margins to 1-84 or greater, DPaint will try to scrunch the file a few pixels horizontally. This seems pretty odd, I'd expect to be able to set margins to 1-80 (or even 1-81) to get the right translation, but it has to be somewhat larger than that. And then, I can set margins to something rediculous like 1-120 and I still get the same image as if they were set to 1-84. And of course, DPaint I will still scrunch the picture vertically anyway trying to force the aspect ratio to reflect the screen. Fortunately, DPaint II allows you to override the screen aspect ratio in the interest of quality output (especially with text). Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa