stever@videovax.UUCP (01/22/87)
We have an Epson JX-80 (color) printer, which produces quite acceptable
output. (As an example of the things we do with it, last night my older
son made a very fancy birthday card for a friend, using DPrint. My wife
also prints her homework, in black-and-white.)
There is one fly in the ointment, though. When we have selected "JX-80"
in Preferences, the output is agonizingly slow!!! On each line, the
printer driver insists on printing the full width of the paper for each
color, even if nothing is to be printed on that line! Of course, the
printer has to cycle the (multistripe) ribbon up and down with each
color, so it takes five to ten seconds per line.
When the output is only a line feed, the printer driver still cycles the
ribbon through all four colors before moving to the next line. We can
get around the problem by selecting "FX-80" in Preferences, which
produces fast black-and-white output, but this renders color printing
unavailable.
There is a solution -- the JX-80 printer driver needs to optimize
printing for best throughput. Some suggestions (in the comments
below, "line" means the vertical expanse that can be printed in a
single pass of the printhead):
1. Neither printhead motion nor ribbon motion should occur unless
there are one or more dots to be printed on a given line. If a
line consists entirely of empty pixels, (even hundreds of them),
all that is required is a line feed.
2. The ribbon should not be cycled to a color that is not used on
the line being printed, nor should any printhead motion occur
for that color. Ribbon motion is one of the slowest functions
on the printer, so elimination of unnecessary ribbon color changes
should have a very high priority.
3. The printhead should go only as far as is required to print the
last active dot for each color on the line. Why waste time
sweeping across 8-1/2 inches of paper and returning across the
same 8-1/2 inches when the only dots to be printed are within
one inch of the left edge of the paper?
4. The rest state of the ribbon should be on the black stripe,
so it will not be necessary to move the ribbon at all for
black-and-white printing.
5. If there is only black-and-white information to be printed, do
not send any ribbon motion commands (not even "go to black ribbon").
Combined with (2) and (4), above, this will permit black-and-white
printing as fast as if "FX-80" had been selected in Preferences.
All-in-all, these improvements would probably double the printing
speed for sparsely-colored images, and increase the speed for
black-and-white printing by ten times.
How about it, Commodore-Amiga? Can we hope for an improved JX-80
printer driver in V1.2? Or can I get the source for the JX-80 printer
driver so I can hack these changes in myself?
Steve Rice
----------------------------------------------------------------------------
{decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!steverdaveb@cbmvax.UUCP (01/25/87)
In article <4175@videovax.Tek.COM> stever@videovax.Tek.COM (Steven E. Rice, P.E.) writes: > several good suggestions for speeding up the JX-80 driver. Steve: These are very good logical suggestions which were on my 'to-do' list when I wrote the original driver. Unfortunately, with all the other drivers to write, I never got a chance to do a second pass on all the drivers. Since I no longer woke for CBM-Amiga, I can't say if they will update this driver. CBM-Amiga has published (in the RKM) the source for the Epson driver, perhaps they can be persuaded to publish the source for the Epson_JX-80 driver. Good luck in your endevours.
keithd@cadovax.UUCP (01/28/87)
In article <4175@videovax.Tek.COM> stever@videovax.Tek.COM (Steven E. Rice, P.E.) writes: >There is one fly in the ointment, though. When we have selected "JX-80" >in Preferences, the output is agonizingly slow!!! On each line, the >printer driver insists on printing the full width of the paper for each >color, even if nothing is to be printed on that line! Of course, the >printer has to cycle the (multistripe) ribbon up and down with each >color, so it takes five to ten seconds per line. AHA! Other people HAVE been having problems. A friend and I have been exploring some of the printer problems, and are thoroughly confused. We have learned a few things, but am not sure where many of the problems lie. They can either be in: 1) The printer driver for the particular printer 2) The printer.device 3) The application doing the printing We have been testing on two types of printers basically, a Canon1080a color ink-jet, and an Epson LQ-800 24 pin high quality dot matrix printer. Neither printers were in the original Amiga preferences, all drivers were obtained from Compu$erve. We have the source to the LQ-800 driver, but not to the Canon driver. We've tested printers with 5 packages that are of note: 1) Dpaint I 2) Dpaint II 3) DeluxePrint 4) NotePad 5) PageSetter Here are some of the things we've found: 1) The slowest APPLICATION is DeluxePrint. Here is where we get the 30+ minuite print times when using the LQ-800 which has in the NLQ mode, which provides 1440 dots horizontally. It takes a good 30 seconds a line. The LQ-800 prints a page in around 10-12 minuites worst case with most of the other programs (except PageSetter which also tends to the 30+ print minutes per page). 2) The applications are apparently doing their own re-sampling (I use this term to mean 're-sizing' the image by 'doubling-up' pixel lines horizontally and/or vertically or 'dropping-out' such lines in order to make the image fit the paper 'correctly'. Each application seems to be re-sampling DIFFERENTLY. Of all the packages mentioned, only DPaint II can be configured so that the re-sampling dosen't affect text output objectionably. All the rest you see a tendency for some letters to be 'thicker' than the same letter elsewhere on the page. This is because some vertical lines are 'doubled- up' and others are not, to make the image wider on the page. 3) NotePad sizes, 'Small, Medium, and Large' and Auto-Size seem to do different things with respect to size depending on the printer driver and current setting of preference margins. I can't get Auto-Size to work AT ALL with the Canon1080a driver I'm using, it just comes back as if it was done, with no errors and no printout. With the LQ-800 used with the standard Amiga-supplied Epson driver, 'Small, Medium, and Large' are all pretty gigantic. 4) The 'preferences' left and right margins do affect the different packages 're-sampling', but differently with every package. If I find a good setting for one package, other packages work differently, and may have different optimal settings. I've setup a test graphic, a DPaint I lo-res screen that has a bunch of single pixel vertical black lines seperated by single pixel white lines at the top edge of the graphic, and the same pattern horizontally at the left edge of the graphic. Using the Canon driver, I have to set the right margin to any number above about 85 in order to eliminate the re-sampling effect and thereby get clean lines with no 'extra' lines or lines missing. Any number above 85, up to 250 or so (which I've tested) acts all the same. No variations whatsoever. Unfortunately, with the Canon, DPaint I will try to adjust the vertical aspect to fit the screen h/v aspect ratio, and won't allow me to get an image that dosen't replicate or remove horizontal lines, thereby producing thick horizontal lines at periodic intervals. With PageSetter or the NotePad, I can't get the horizontal size to work at all without ugly 'thick' vertical lines at various intervals. With NotePad, I'll pick a font, do a bunch of H's , and find that some of the verticals are thicker than others throughout a line. I've tried setting the right margin all over the place, and though it does change where the thick and thin lines are, I can't seem to find a setting that outputs all H's uniformly. I can't get PageSetter to do this very well either. I've only done a cursory test of the screen dumper program with my test graphic. It looks like this might work better, but I really don't know yet. At any rate, it won't help me to print PageSetter documents correctly anyway. Personally, I sure wish these packages would allow me to disable any resampling at all, and take the hit in the aspect ratio and size. Shit, I can size it with a Xerox if I need to, I just can't stand the idiotic looking text when random horizontal and vertical lines are being replicated. And, it sure is a pain to try to 'cancel' a print job, most of these programs (except Dpaint II) don't provide a print cancel option. It would seem reasonable to provide this within the printer.device or the OS somewhere since obviously the Application writers aren't doing it. (Kill -9 anyone?) So what the hell is going on here? What can a printer driver do to help fix any of these problems? What can a printer driver be doing that can cause Auto-Size on the Notepad to do nothing? I've tried patching the DPI on my driver, and do get some changes, but I don't know how to figure out what I really need to set it to to get what I want (and that's text that dosen't look like SHIT). The RKM implies that these numbers need to be set to whatever the real DPI of the printer is, but that dosen't correspond to what the application is going to do with it, and usually screws up the output. The Canon has 640 dots horizontally. Sound familiar? No matter WHICH application I use, if it's dumping something that was created on the screen, it OUGHT to be able to do it without 'doubling' up vertical lines at random intervals trying to make it 'fit' the page. And though the Canon vertical DPI is not the same as the horizontal DPI, if I patch the driver to MAKE them the same, I ought to get no horizontal double-lines if I'm getting no vertical ones, but that is not the case. I'd rather stretch the image slightly vertically and not suffer re-sampling distortion than get a 100% correct aspect ratio MOST OF THE TIME. So ok, Commodore, you laid off your printer driver expert. So what are you going to do NOW? What are the rest of us going to do NOW? Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa
gwe@cbosgd.UUCP (02/03/87)
The story of the film so far: First the sun was formed, and the earth cooled down, then the dinosaurs died, then people gripe about slow printing... In article <1366@cadovax.UUCP> keithd@cadovax.UUCP (PUT YOUR NAME HERE) writes: > >AHA! Other people HAVE been having problems. A friend and I have been >exploring some of the printer problems, and are thoroughly confused. We >have learned a few things, but am not sure where many of the problems lie. >They can either be in: > > 1) The printer driver for the particular printer > 2) The printer.device > 3) The application doing the printing > >Here are some of the things we've found: > > 1) The slowest APPLICATION is DeluxePrint. Here is where we get the > 30+ minuite print times when using the LQ-800 which has in the NLQ > mode, which provides 1440 dots horizontally. It takes a good 30 > seconds a line. The LQ-800 prints a page in around 10-12 minuites > worst case with most of the other programs (except PageSetter which > also tends to the 30+ print minutes per page). (Keith then includes the results of more research than I've seen in many Master's Theses... pat yourself on the back, Keith, 'cause you deserve it !) Having owned an Apple ][e system before my Amiga, I guess I was spoiled... I could dump any Hi-res screen with one command, and print it out with a 1 dot/pixel or 4 dots (2x2) per pixel. A double-size print would neatly fill half of a page. And the dump would take only about one minute (more on some programs, to allow the print head to cool between lines). I realize that Apple Hi-res has far fewer pixels to "translate", and has an entire card dedicated to nothing but driving the printer. But on the other hand, it didn't have a 68000 chip, or seperate graphics chip, or 512 K ram, or ... Net effect: when I want to create graphics for printing, I slide over and fire up the ol' ][e. Despite the wonderful resolution, 4096 colors, and ease of use of the Amiga. >Personally, I sure wish these packages would allow me to disable any >resampling at all, and take the hit in the aspect ratio and size. Shit, >I can size it with a Xerox if I need to, I just can't stand the idiotic >looking text when random horizontal and vertical lines are being replicated. Absolutely. >And, it sure is a pain to try to 'cancel' a print job, most of these programs >(except Dpaint II) don't provide a print cancel option. It would seem >reasonable to provide this within the printer.device or the OS somewhere >since obviously the Application writers aren't doing it. (Kill -9 anyone?) The escape key usually did this on the Apple. When you've made a mistake, it's MADDENING to have to wait 20 minutes for the stupid thing to stop. Brings up another point. Why don't these commercial packages grab some of that wonderful, copious RAM and use it as a printer buffer, so I can work on a second graphic while printing the first ? Maybe it isn't possible ? > >So ok, Commodore, you laid off your printer driver expert. So what are >you going to do NOW? What are the rest of us going to do NOW? > > >Keith Doyle Once again, thanks for a well-written and researched article. ------------------------------clip and save---------------------------------- Bill Thacker cbatt!cbosgd!cbdkc1!serial!wbt DISCLAIMER: Farg 'em if they can't take a joke ! If you love something, set it free. If it doesn't come back to you, track it down and kill it. -----------------------------valuable coupon---------------------------------
andy@cbmvax.UUCP (02/03/87)
<minor flames ahead, be warned> In article <1366@cadovax.UUCP> keithd@cadovax.UUCP (PUT YOUR NAME HERE) writes: >In article <4175@videovax.Tek.COM> stever@videovax.Tek.COM (Steven E. Rice, P.E.) writes: >>There is one fly in the ointment, though. When we have selected "JX-80" >AHA! Other people HAVE been having problems. Different problems, however. Steve's problems can be handled by enhancing the printer driver for the epson_jx. His are specific problems/suggestions of things that the driver isn't doing now that, if it did, would result in increased performance. (And he's going to try) >A friend and I have been >exploring some of the printer problems, and are thoroughly confused. We >have learned a few things, but am not sure where many of the problems lie. >They can either be in: > > 1) The printer driver for the particular printer > 2) The printer.device > 3) The application doing the printing > So far so good... >We have been testing on two types of printers basically, a Canon1080a color >ink-jet, and an Epson LQ-800 24 pin high quality dot matrix printer. Neither >printers were in the original Amiga preferences, all drivers were obtained >from Compu$erve. We have the source to the LQ-800 driver, but not to the >Canon driver. > >We've tested printers with 5 packages that are of note: > > 1) Dpaint I > 2) Dpaint II > 3) DeluxePrint > 4) NotePad > 5) PageSetter > >Here are some of the things we've found: > > 1) The slowest APPLICATION is DeluxePrint. Here is where we get the > 30+ minuite print times when using the LQ-800 which has in the NLQ > mode, which provides 1440 dots horizontally. It takes a good 30 > seconds a line. Since I don't have this printer, I'll ask...is this out of line with what it does on other computers ? What is its rated speed ? (1440 dots horizontally on a 24 printer is about 34560 pixels per printer pass or 'line', right ?) As I've said before, if someone wants to send me the driver, I'll take a look at if to see if its doing anything really funny. (BTW, is there a buffer size option on this Epson ? Is it on ?) > > 2) The applications are apparently doing their own re-sampling (I use > this term to mean 're-sizing' the image by 'doubling-up' pixel lines > horizontally and/or vertically or 'dropping-out' such lines in order > to make the image fit the paper 'correctly'. The printer.device has many options, settable by the application program as to what aspecting calculations are made during a graphics dump. What you are saying is that you disagree with the decisions made by the application program authors. Fine. Write the companies. Tell them. Please don't complain about the flexibility of the printer.device, though (which is what you are doing). Flexibility gives the ability to make mistakes, as well as the ability to do it your way. You do know about the dithering that goes on, right ? Selected by preferences, you can choose Grey Scale (dithering) or Black and White (with a threshold selection to decide what is black and what is white) (BTW, re-sampling is a poor choice of term for what you are describing. In your previous posting it sounded like you thought the printer.device was reading the bitmap many times for each pixel) > > Each application seems to be re-sampling DIFFERENTLY. As I said, aspecting is controlled by the way the application calls the printer.device. There are several variables and flag values to control it. > 3) NotePad sizes, 'Small, Medium, and Large' and Auto-Size seem to do > different things with respect to size depending on the printer driver > and current setting of preference margins. Right. If your margins are set full width, small means 1/4 page, medium means 1/2 page, and large means full page, assuming the values in printertag.asm of the driver are set correctly. The margin settings are obeyed, so making the margins smaller will cut down on the width. I can't get Auto-Size to > work AT ALL with the Canon1080a driver I'm using, it just comes back > as if it was done, with no errors and no printout. With the LQ-800 > used with the standard Amiga-supplied Epson driver, 'Small, Medium, > and Large' are all pretty gigantic. I'd check those printertag.asm values if I were you. >Personally, I sure wish these packages would allow me to disable any >resampling at all, and take the hit in the aspect ratio and size. No, you don't. (well, maybe you do) Text is all stretched out when you pick 1 to 1 aspecting. (but if it doesn't look too horrible, maybe I'll put it into Notepad sometime). You could see what it looks like by modifying one of the screen dump programs out there. >And, it sure is a pain to try to 'cancel' a print job, most of these programs >(except Dpaint II) don't provide a print cancel option. It would seem >reasonable to provide this within the printer.device or the OS somewhere >since obviously the Application writers aren't doing it. (Kill -9 anyone?) > One of the big things that the Amiga OS does not provide is resource tracking. (At the time it seemed that the performance hit would be too much). So, while it would be simple to provide a means of killing any arbitrary process (since Exec knows where each one is) the process wouldn't have the resources it took (memory, I/O ports, etc) returned to the system. Only the application knows what resources it owns are finished with when. >So what the hell is going on here? What can a printer driver do to help >fix any of these problems? What can a printer driver be doing that can >cause Auto-Size on the Notepad to do nothing? Notepad autosize says to the printer.driver that it wants the driver to attempt to print a note the same size as the one on the screen. If the values in printertag.asm are incorrect, this might easily lead to being unable to print. I'd have to see the drivers to be sure, as other factors might also be involved. Printertag sounds like the problem though, judging from the rest of your complaints. (it could also be the Render Pixel case in your driver, but this is less likely) > >I've tried patching the DPI on my driver, and do get some changes, but >I don't know how to figure out what I really need to set it to to get >what I want Set the variables in printertag.asm correctly. Putting in funny numbers in attempts to defeat the graphic dump call flag choices of the application won't work very well, and will waste a lot of time. >The Canon has 640 dots horizontally. That seems to imply about 80 dpi. Sound familiar? No matter WHICH >application I use, if it's dumping something that was created on the >screen, it OUGHT to be able to do it without 'doubling' up vertical lines >at random intervals trying to make it 'fit' the page. It can do it if it wants, via the appropriate printer.device call >And though the >Canon vertical DPI is not the same as the horizontal DPI, if I patch the >driver to MAKE them the same, I ought to get no horizontal double-lines >if I'm getting no vertical ones, but that is not the case. I'd rather >stretch the image slightly vertically and not suffer re-sampling distortion >than get a 100% correct aspect ratio MOST OF THE TIME. um, the aspecting isn't random, it follows a (probably fairly standard) algorithm. Why not use one of the screen dump programs available and see if the no-aspecting is what you really want ? > >So ok, Commodore, you laid off your printer driver expert. So what are >you going to do NOW? What are the rest of us going to do NOW? > We didn't lay off the person who wrote most of the graphic drivers. He left on his own to persure fame and fortune as an independent software developer. So, ok, Keith, when are you going to send the source to the drivers you're having trouble with ? And when are you going to to get a screen dump program and start playing with the flags on thecall to dump the screen so you can get a real idea of what's going on ? >Keith Doyle ># {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd ># cadovax!keithd@ucla-locus.arpa 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."
gregor@tikal.UUCP (02/03/87)
In article <3326@cbosgd.ATT.COM> gwe@cbosgd.UUCP (Bill Thacker) writes: >In article <1366@cadovax.UUCP> keithd@cadovax.UUCP (PUT YOUR NAME HERE) writes: >>And, it sure is a pain to try to 'cancel' a print job, most of these programs >>(except Dpaint II) don't provide a print cancel option. It would seem >>reasonable to provide this within the printer.device or the OS somewhere >>since obviously the Application writers aren't doing it. (Kill -9 anyone?) I found something that may help you. Turn your printer off-line. In a few minutes, a requester alerting you to printer trouble will appear. (this may require the printer cable to be wired correctly) Select cancel, and usually the print job will end. Gregor Harrison -- EMAIL: {uw-beaver, fluke}!tikal!gregor QUOTE: "Sticks and stones may break my bones, but so what?" DISCLAIMER: "All opinions found above are my personal property, and not that of Teltone, Inc."
wagner@utcs.UUCP (02/04/87)
Keith was looking for a way of cancelling a print that's part way done. I also feel the need. A quick (but not very satisfying) fix is to make the printer not ready. A minute later, a requester comes up saying that your printer is broken. You then select cancel. Works every time. Michael
papa@bacall.UUCP (02/07/87)
> > >And, it sure is a pain to try to 'cancel' a print job, most of these programs > >(except Dpaint II) don't provide a print cancel option. It would seem > >reasonable to provide this within the printer.device or the OS somewhere > >since obviously the Application writers aren't doing it. (Kill -9 anyone?) > > The escape key usually did this on the Apple. When you've made a mistake, it's > MADDENING to have to wait 20 minutes for the stupid thing to stop. > An easy trick to stop the printer if you have made a mistake is to turn the printer OFF! Wait for about 30 seconds, a system requester will come up. Click on Cancel, and the call to the printer device will return to the program, and you can go on with your work without having to wait minutes for the dump to be finished (and discarded 8-). -- Marco Papa Felsina Software
kaz@cadovax.UUCP (02/09/87)
In article <1987Feb4.154157.11126@utcs.uucp> wagner@utcs.UUCP (Michael Wagner) writes: >Keith was looking for a way of cancelling a print that's part way done. >I also feel the need. A quick (but not very satisfying) fix is to make >the printer not ready. A minute later, a requester comes up saying that >your printer is broken. You then select cancel. Works every time. > >Michael Unfortunately, the requester can and does come up again and again. This occurs whenever the printing program calls DumpRPort for only a portion of the entire printout, and does not check for errors between each call. For example, DeluxePrint prints a greeting card in three parts; The backside of the card, the middle of the card and the frontside of the card. This means three cancels are required, and at least 30 seconds go by between each printer-problem requester. NotePad is an interesting example. A small note may only require 1 cancel, but a full screen note requires several cancels. I hope a new version of notepad is released that handles cancel print in a clean manner -- like deluxe paint II. Its all very well for Commodore to say it's the application writer's responsibility to make use of the printer.device features, but it is obvious their own applications don't set very good examples in these areas. Of course they only had the RKM manual example to work from, like us :-) I noticed an interesting "feature" with notepad recently. Print a note using "small" which is the size of the original note window. Next print it again but first enlarge or shrink the window. You will see the size of the text get very small or super large as the auto-scaling of the dump rast port takes effect. I was suprised by this because I thought changing the window size would only adjust how much text I could enter, not change the size of the text itself. Personally, I don't like having the text size change, and is another reason I would like the printer.device to be less "flexible". Kerry Zimmerman # {ucbvax,ihnp4,decvax}!trwrb!cadovax!kaz # cadovax!kaz@ucla-locus.arpa