tjc@mtfmi.att.com (T.CZARNECKI) (03/11/89)
I recently purchased a UNIX-PC 3B1 and I am trying to configure the dot matrix printer that I had left over from my DOS machine to the 3B1. Here is the problem: The printer is a OKIDATA Microline 182, the printer setup on the UNIX-PC only has an option for a OKIDATA92. If I select that option, I can't do screen prints... I've tried other selections like EPSON, but that yields complete garbage. The printer is attached to the parallel port. Anyone solved this problem or have any suggestions other than replace the printer.. Thanks in advance for your help. Tom Czarnecki att!mtfmi!tjc
kevin@kosman.UUCP (Kevin O'Gorman) (03/12/89)
In article <932@mtfmi.att.com> tjc@mtfmi.att.com (T.CZARNECKI) writes: > > The printer is a OKIDATA Microline 182, the printer setup >on the UNIX-PC only has an option for a OKIDATA92. If I select >that option, I can't do screen prints... I've tried other selections Yep, AT&T did it to you again. They did it to me, too. Screen printing works only with AT&T printers, maybe on full compatibles. This is not too surprising because it is built into the kernel and they didn't want to clutter that with lots of odd options for different bit-addressing styles that different printers have. I solved this long ago, though I'm not sure I still have the code around. You must become familiar with the controls on the line-printer spooler, and fake it into thinking that the first(!!!) printer you defined on the system is an AT&T printer such as the ATT471. Then it will do screen prints to that device. In no other case will it do so. The problem is that these prints will look like garbage on your Okidata. So you have to change the interface for that printer. Fortunately, this is a shell script somewhere in /usr/spool/lp, not a driver. You can find it by doing "find /usr/spool/lp -newer ..." after you have defined the printer. What I did was to take raw output for that printer, filter it with a program, and send it to my "real" printer, which I had defined after the ATT471. The filter had to accomodate the fact that the ATT471 prints 8 dots on each line in graphics mode, and the Oki only prints 7. So although the formats were pretty easy to figure out, I had to emulate the 471 and send the equivalent output to the Oki. It worked fine, but I have a real 471 these days, and the Oki is old and not too solid, so I do real screen prints when I need them.
jcm@mtunb.ATT.COM (was-John McMillan) (03/14/89)
In article <719@kosman.UUCP> kevin@kosman.UUCP (Root) writes: >... >Yep, AT&T did it to you again. They did it to me, too. Screen printing ^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^ AT&T targets precisely ;-) >works only with AT&T printers, maybe on full compatibles. This is not too >surprising because it is built into the kernel and they didn't want to >clutter that with lots of odd options for different bit-addressing styles >that different printers have. (It's always fun reading paranoid broadcasts!-) AT&T -- according to the report I heard from within AT&T -- TRIED to include the OKIDATA-92 printer, but supporting this printer's "features" collided with deadlines. The KERNEL only sends the bits out (ref: 'wd' ioctl): there is a screendump program that is responible for translating it to the printer -- and therein's your problem -- at least the software one! You can generate image FILES -- since I do NOT do this, I'll defer to others to explain how -- and drive the printer from your own bitmap-to-printer converter. jcm
jeff@cjsa.WA.COM (Jeffery Small) (03/14/89)
In article <719@kosman.UUCP>, kevin@kosman.UUCP (Kevin O'Gorman) writes: > In article <932@mtfmi.att.com> tjc@mtfmi.att.com (T.CZARNECKI) writes: [ .. lots of printer problems being discussed ...] OK. I have spent many-many hours trying to solve the print spooler mysteries of the UNIX-PC. Here is a summary of what I have learned. There will be a lot of "obvious" things discussed here for many of you - but I have made an effort to be reasonable complete. First of all, if you want to get control over the spooler, you simply have to do the work from UNIX. The User Agent lets you do simple tasks but really limits you when you try to perform the unconventional. Get those manuals out and look this stuff up. The commands you will need to use are: enable(1), lpstat(1), accept(1M), lpsched(1M), lpadmin(1M) Lesson number 1 is that when you try to do any lp setup work with these commands (especially lpadmin), if the command fails: *** YOU DON'T GET ANY ERROR MESSAGES, WARNINGS OR FEEDBACK ***** The lp system is generally silent and just returns - whether or not it has performed your requested task. This makes it extremely difficult to know what is going on and is probably the single biggest reason that people find that they cannot get printers properly configured. You have to become user id "lp" in order to (successfully) issue many of the lp commands. Not even "root" can do these tasks! So (as root) set an appropriate password for lp and then "su lp". Now you've got a fighting chance! Also note that many of the administrative commands reside in /usr/lib - so add this to your PATH to make life a lot easier. As any login id, you can find out how your system is currently configured by typing: "lpstat -t". Here is sample output from my system with my added running commentary noted by all lines starting with a "##": scheduler is running ## As user "lp" you can start the scheduler with "lpsched" and shut it down ## with "lpshut". To do most routine administrative tasks you HAVE to ## "lpshut" the scheduler. If you don't, your subsequent commands are going ## to silently fail - whether you are user "lp" or not! I don't want to ## think about how many time this has bitten me. I don't want you to think ## about it either :-) system default destination: Epson ## You set the default system printer with the command: lpadmin -dPRINTER_NAME ## Now, just because getopt is a good idea, don't think that anyone at AT&T is ## using it. That's right - no space allowed between "-d" & the printer name! ## This applies to the other options as well. members of class Serial: Daisy Diablo630 members of class Parallel: Quantex Epson ## Here we see that I have four printers hooked up to my system - 2 Serial ## and 2 Parallel. Now you want to know where to order that Parallel port ## expansion board don't you! The fact is, there are only two printers on ## this system - 1 Serial and 1 Parallel. I have just given each printer ## two names. Realizing that you can do this, is a big step in getting ## the system to work the way you want it to. I have a Quantex #7065 dot ## matrix printer which has a bunch of snazzy capabilities when it operates ## in native (ie. Quantex) mode. So I have created a "Quantex" printer with ## a customized interface (discussed below) which gives me access to all of ## these features. Unfortunately, the UNIX-PC can't be made (at least by me) ## to understand the Quantex's graphic print mode. Fortunately, the printer ## will accept an escape code sequence which will put it into Epson mode. I ## have created an "Epson" printer with its own interface which simply puts ## the Quantex into Epson mode and then passes whatever onto the printer. This ## is how you get screen prints to work! I'll bet there are a lot of printers ## out there that will do Epson-graphics if you could just get your UNIX-PC to ## talk to them properly! ## ## BTW: I believe that on pre-3.5 versions of the OS, the graphics printer had ## to be the first - ie. the Default printer on the system. On 3.5/3.51, I ## think you will find that for screen prints, the Default printer is first ## checked to see if it supports (as far as 3.51 OS is concerned) graphics. ## If it does, the screen dump will go there. If that printer is not recognized ## as a graphics printer, then other printers you have specified will be ## examined until a "graphics" printer is found. If one is located, then the ## screen dump will be queue there. Thus, If I specify that the "Diablo630" ## is the Default printer on my system, a screen print request will still find ## its way to the "Epson" 'cause that's the only "graphic" printer that has ## been configured. ## ## Also BTW: If you are running the Smart software, then you will HAVE to set ## the Default printer to the appropriate one which you have configured within ## Smart because Smart only supports ONE printer and it HAS to be the Default. device for Quantex: /dev/rawlp device for Daisy: /dev/tty003 device for Epson: /dev/rawlp device for Diablo630: /dev/tty003 ## Here you can see that the pairs of names point to the same device location. ## There has been a lot of discussion about how /dev/lp massages you output ## and, in the process, messes up things like page-break and the margin ## settings. They did (finally) add the setprint(1) command to the system, but ## long ago I decided that it is easier and more sensible to attach the printer ## to the raw parallel device and manage the format of the output either from ## the interface program (discussed below) or directly at the printer by the ## various option (switch) settings that most modern printers offer. For ## example, my printers handle page breaks far more intelligently than any ## driver or interface script could - so I let them do that job. This works ## especially well when you have long lines. Regardless of whether I set my ## printers for "truncate" or "wrap-around", they will keep track of the actual ## physical number of lines printed (rather than the # of logical lines) and ## will handle page breaks properly. The dumb interface programs were always ## getting this wrong and I use to get those horrid pages with just one line ## of text at the top. Quantex accepting requests since Sep 2 18:25 Parallel accepting requests since Sep 2 18:25 Epson accepting requests since Sep 24 15:27 Daisy accepting requests since Feb 10 14:30 Serial accepting requests since Feb 10 14:30 Diablo630 accepting requests since Feb 10 14:30 ## Once you add or change a printer with lpadmin, you have to tell the system ## that it is ready to accept requests. You do this with the "accept(1M)" ## command. You use "reject" to deactivate this. See the man page. printer Quantex is idle. enabled since Sep 6 15:48 printer Epson is idle. enabled since Sep 15 08:08 printer Daisy is idle. enabled since Feb 10 14:30 printer Diablo630 is idle. enabled since Feb 10 14:30 ## You also have to "enable(1)" each printer before you can print on it. ## Any time there is a serious problem with the printer (cable is disconnected, ## paper-out signal, etc) the system "disable"s printing. Once the problem ## is fixed, the printer needs to be manually re-"enable"d. ## Don't forget to "lpsched" the system when you are done. Now for a set of sample commands to create the above configuration: % su lp Password: lp% lpshut lp% lpadmin -pQuantex -cParallel -h -mdumb -v/dev/rawlp lp% lpadmin -pEpson -cParallel -h -mdumb -v/dev/rawlp lp% lpadmin -pDaisy -cSerial -h -mdumb_S -v/dev/tty003 lp% lpadmin -pDiablo630 -cSerial -h -mdumb_S -v/dev/tty003 lp% accept Quantex Epson Daisy Diablo630 Serial Parallel [you should get status messages here] lp% enable Quantex Epson Daisy Diablo630 [you should get status messages here] lp% lpsched [you should get status message here] lp% exit % And finally, you now need to customize the dumb interface scripts which were put into the /usr/spool/lp/interface directory (-m option to lpadmin) and named after your printers. The beauty of the System-V spooler system is that you have full control over the system because you can make these interface programs be anything you want them to be. Go ahead, process special options, issue control codes, change the tty settings, anything you want! Here is the one I use for "Epson" to put my Quantex printer into Epson graphics mode. If you compare this to what you get with the default "dumb" script, you will see that I ripped out all of the header junk which prints that unwanted banner page with every job. ----------------------------------------------------------------------------- # lp interface modified for use as interface to Epson MX-80 mode of Quantex # copies=$4 options=$5 raw=$6 shift; shift; shift; shift; shift if [ "$1" = "-raw" ] then shift fi files="$*" i=1 echo "\033[1!d\c" # put Quantex into Epson mode sleep 3 # give it some time to "take" echo "\033@\c" # issue a reset to initialize Epson mode sleep 3 # also some time for it to "take" while [ $i -le $copies ] do for file in $files do cat "$file" 2>&1 # dump the stuff to the printer echo "\014\c" # I DO want a page-break between each graphic # print job - so this stays (this time) done i=`expr $i + 1` done echo "\033q\c" # issue reset to put us back into Quantex mode sleep 5 # wait for this to "take" exit 0 ----------------------------------------------------------------------------- Well, those are the basics. I hope you had fun and found some of this useful. If there is any interest, I can also provide some info on: * sharing printers between UNIX-PCs connected by serial cables (the dumb-remote scripts don't do the job if you try to pass printer options) * I can post a sample "C" interface program I wrote which allows me to set all the neat options of my Quantex and Daisy printers (speeds, margins, page lengths, fonts, graphic modes, proportional spacing, etc) and a shell script which I use to print all of my jobs that acts as a nice front end to the interface program. These won't be of any direct use to anyone, but they could serve as a model which could be modified to meet your particular printing needs. Let me know! -- Jeffery Small (206) 485-5596 uw-beaver!uw-nsr!uw-warp C. Jeffery Small and Associates !cjsa!jeff 19112 152nd Ave NE - Woodinville, WA 98072 uunet!nwnexus
hartman@abacab.UUCP (Mark A. Hartman) (03/15/89)
In article <719@kosman.UUCP>, kevin@kosman.UUCP (Kevin O'Gorman) writes: > In article <932@mtfmi.att.com> tjc@mtfmi.att.com (T.CZARNECKI) writes: > > > > The printer is a OKIDATA Microline 182, the printer setup > >on the UNIX-PC only has an option for a OKIDATA92. If I select > >that option, I can't do screen prints... I've tried other selections > > Yep, AT&T did it to you again. They did it to me, too. Screen printing > works only with AT&T printers, maybe on full compatibles. This is not too ^^^^^^^^^^^^^^^^^^^^^^^ Sorry, but this is blatently untrue. The screen print option works with a number of non-AT&T printers, notably several Epson and HP printers. I'm not sure whether the manual states explicitly which ones work, though. #include <standard disclaimer> -- Mark Hartman {att,obdient}!abacab!hartman
kevin@kosman.UUCP (Kevin O'Gorman) (03/17/89)
In article <1435@mtunb.ATT.COM> jcm@mtunb.UUCP (was-John McMillan) writes: >In article <719@kosman.UUCP> kevin@kosman.UUCP (Root) writes: >>... >>Yep, AT&T did it to you again. They did it to me, too. Screen printing > ^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^ AT&T targets precisely ;-) >>works only with AT&T printers, maybe on full compatibles. This is not too >>surprising because it is built into the kernel and they didn't want to >>clutter that with lots of odd options for different bit-addressing styles >>that different printers have. > >(It's always fun reading paranoid broadcasts!-) AT&T -- according to >the report I heard from within AT&T -- TRIED to include the OKIDATA-92 >printer, but supporting this printer's "features" collided with deadlines. Then, in another followup: In article <202@abacab.UUCP> hartman@abacab.UUCP (Mark A. Hartman) writes: >In article <719@kosman.UUCP>, kevin@kosman.UUCP (Kevin O'Gorman) writes: >> >> Yep, AT&T did it to you again. They did it to me, too. Screen printing >> works only with AT&T printers, maybe on full compatibles. This is not too > ^^^^^^^^^^^^^^^^^^^^^^^ > >Sorry, but this is blatently untrue. The screen print option works with >a number of non-AT&T printers, notably several Epson and HP printers. >I'm not sure whether the manual states explicitly which ones work, >though. It looks as if I posted before checking things out. Apologies to AT&T. For the first few years that I had the 7300, I only had the Okidata, and had no contact with other UNIX PC's except one with a ATT471. I got a firm impression of how things were from that experience and the fact that as near as I could tell, AT&T never said screen dumps depended on your printer type. That looked like a gotcha! to me. Still, I usually refrain from stating my impressions as fact, no matter how firm. Anyway, the solution I described in my followup was working for me for some time. I thought I understood the printer stuff until this thread started. Now I have some questions. Now, the followups are confusing me a bit. If lots of printers are supported, I expect the format conversions to be in a program somewhere, but I cannot find it. Continuing <1435@mtunb.ATT.COM> jcm@mtunb.UUCP (was-John McMillan) writes: > >The KERNEL only sends the bits out (ref: 'wd' ioctl): there is a >screendump program that is responible for translating it to the printer >-- and therein's your problem -- at least the software one! Are you sure? There's no program by that name (or any other unknown progams with names ending in 'dump') on my system. Also, I can't figure out how to look up a 'wd' ioctl. I do see ioctl(wd,WIOCREAD,&pixmap) but that doesn't tell me much. > >You can generate image FILES -- since I do NOT do this, I'll defer to >others to explain how -- and drive the printer from your own >bitmap-to-printer converter. I can see how to do this if I'm writing the package, but the data flow for the Shift-Print screen dump still looks like a kernel thing to me. Does anyone have better information?
pschmidt@bbn.com (Peter H. Schmidt) (03/19/89)
Re: the program that does the screen dump - I've been struggling to get screen dumping working on my machine (I have a 3B1 w/ 2M/40M running 3.51), and I have seen that pressing <Shift><Print> fires up the program /usr/bin/sprint. Screen dumping on my machine works fine if I have the default printer set to Epson, but it produces no output if the default is Panasonic1091 - does anyone have an (informed) idea of why this is the case? Regards, Peter ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Peter H. Schmidt | Strive for excellence in all that you do. BBN Advanced Computers Inc.| Sweeping reforms cause more problems. You can 10 Fawcett St. | make a difference - not a large one, but an Cambridge, MA 02238 | important one. The golden rule is a recipe for (617) 873-4311 | oppression of its followers by the renegade few. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
thad@cup.portal.com (Thad P Floryan) (03/20/89)
Another printer that is well-supported on the UNIXPC is the C.Itoh ProWriter Model 8510 (which I use). This printer has the same "guts" as the DEC LA50 and the Apple ImageWriter (or whatever their dot-matrix printer is called). Screem dumps (esp. of ``mahjongg'' or THE STORE!'s "AMAZE") are incredible! ^^^^^^--- should be "Screen" CAUTION: the ROM code for the DEC LA50 and the Apple printer are *NOT* the same as the ProWriter. Thad Floryan [thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad]
jcm@mtunb.ATT.COM (was-John McMillan) (03/20/89)
In article <721@kosman.UUCP> kevin@kosman.UUCP (Root) writes: ... >Now, the followups are confusing me a bit. If lots of printers are supported, >I expect the format conversions to be in a program somewhere, but I cannot >find it. > >Continuing <1435@mtunb.ATT.COM> jcm@mtunb.UUCP (was-John McMillan) writes: >> >>The KERNEL only sends the bits out (ref: 'wd' ioctl): there is a >>screendump program that is responible for translating it to the printer >>-- and therein's your problem -- at least the software one! Quoth the User's Manual: ioctl( wd, WIOCREAD, &pixmap) This "ioctl" causes the pixel image of the entire display to be "dumped" into the memory at "pixmap". "Pixmap" should be 15660 unsigned shorts arranged as 348 rows each containing 45 unsigned shorts. The least significant bit of the first short in the array contains the upper-left-hand display pixel. In other words, bits across the scan-line are taken sequentially from shorts in the respective row (of the 348 rows), with sequential bits- in-a-short taken from the least significant end. >Are you sure? There's no program by that name (or any other unknown progams >with names ending in 'dump') on my system. Also, I can't figure out how >to look up a 'wd' ioctl. I do see ioctl(wd,WIOCREAD,&pixmap) but that >doesn't tell me much. Since it seems to tell ME everything about how to GET the data, I'm failing to understand YOUR delemma, and leave it to others to help. >>You can generate image FILES -- since I do NOT do this, I'll defer to >>others to explain how -- and drive the printer from your own >>bitmap-to-printer converter. > >I can see how to do this if I'm writing the package, but the data flow >for the Shift-Print screen dump still looks like a kernel thing to me. ? "Data flow"? You request the data with the IOCTL. Or you use the existent routines to build a FILE of that data. "A kernel thing"? >Does anyone have better information? Translator, please !-) jc mcmillan --att!mtunb!jcm
bamford@ihlpf.ATT.COM (Harold E. Bamford) (03/21/89)
In article <721@kosman.UUCP> kevin@kosman.UUCP (Root) talks about his confusion re: the screen dump program: >Continuing <1435@mtunb.ATT.COM> jcm@mtunb.UUCP (was-John McMillan) writes: >> >>The KERNEL only sends the bits out (ref: 'wd' ioctl): there is a >>screendump program that is responible for translating it to the printer >>-- and therein's your problem -- at least the software one! > >Are you sure? There's no program by that name (or any other unknown progams >with names ending in 'dump') on my system. Also, I can't figure out how >to look up a 'wd' ioctl. I do see ioctl(wd,WIOCREAD,&pixmap) but that >doesn't tell me much. >I can see how to do this if I'm writing the package, but the data flow >for the Shift-Print screen dump still looks like a kernel thing to me. > >Does anyone have better information? I have better information. When you request a screen dump, the program "sprint" is invoked which grabs a bit-image of the screen and formats it for the printer. I have written a version of sprint that formats for an HP ThinkJet (native mode) so I know whereof I speak. Which is not to say that it couldn't have been done better... If there is sufficient interest, I will post the sprint.c program which is easily adapted to other printers. In fact, the major complication in this one is that it rotates the picture 90 degrees for readability. -- Harold Bamford
kevin@kosman.UUCP (Kevin O'Gorman) (03/21/89)
It seems I'm not making myself understood, and this prompts me to make one more try. Otherwise I would probably let this thread just drop. In article <1441@mtunb.ATT.COM> jcm@mtunb.ATT.COM (was-John McMillan) writes: >In article <721@kosman.UUCP> kevin@kosman.UUCP (Root) writes: >> >>Continuing <1435@mtunb.ATT.COM> jcm@mtunb.UUCP (was-John McMillan) writes: >>> >>>The KERNEL only sends the bits out (ref: 'wd' ioctl): there is a >>>screendump program that is responible for translating it to the printer >>>-- and therein's your problem -- at least the software one! > >Quoth the User's Manual: > [deleted] > > [mentions screendump program] > >>Are you sure? There's no program by that name (or any other unknown progams >>with names ending in 'dump') on my system. Also, I can't figure out how >>to look up a 'wd' ioctl. I do see ioctl(wd,WIOCREAD,&pixmap) but that >>doesn't tell me much. > >Since it seems to tell ME everything about how to GET the data, I'm >failing to understand YOUR delemma, and leave it to others to help. > >>>You can generate image FILES -- since I do NOT do this, I'll defer to >>>others to explain how -- and drive the printer from your own >>>bitmap-to-printer converter. >> >>I can see how to do this if I'm writing the package, but the data flow >>for the Shift-Print screen dump still looks like a kernel thing to me. > >? "Data flow"? You request the data with the IOCTL. Or you use the >existent routines to build a FILE of that data. "A kernel thing"? > >>Does anyone have better information? > > Translator, please !-) I'll do my best. This thread started because someone else with an Okidata printer discovered he could not get screen dumps by pressing Shift-Print. I had solved this problem for my own Okidata printer some time ago. I would have sent the code, but I don't use it any more and am not sure where to find it. So I described what I remembered about how I did it. I then asked for more detail about how the data is handled when you do Shift-Print. In this thread, I have only been interested in Shift-Print printing and how it works. I am not interested in writing programs that do the whole thing, partly because I'm not too sure how to start them without having something show up on the screen to destroy the very image I'm trying to capture. Therefore, I'm interested in all the steps (ALL of them, not just one ioctl) that take the system from Shift-Print to a printed image. I have since discovered (by sleeping a 'ps -ef' and hitting Shift-Print) that the screendump program John referred to does exist and it is called sprint. It does seem to know quite a few printers, but Okidata is not in the list. This was the source of my initial aggravation: AT&T advertised support of Okidata printers, but it was only partial and did not include screen dumps, but you only found that out after you shelled out $$$ for the printer. So the questions I still have some interest in: 1) Who (what program) is listening to Shift-Print, and if it's not the kernel, how does it get connected to Shift-Print. 2) What program actually executes the ioctl, and if not the same as the answer to 1), how does it get started. 3) What starts the progam sprint, and what are its calling parameters. What are the expected inputs and outputs of sprint. 4) Does sprint invoke /bin/lp directly, or does it have its own way into the print queues. The snapshots I took did not show /bin/lp running when sprint was running, so I wonder about this. Answers to these questions would help others who might be interested in writing filters or replacements for use with sprint, to add the support for other printers to the Shift-Print screen dump mechanism. This is a reasonably nice feature of the UNIX PC, and it would be nice to stick with it rather than taking a completely different approach. If this still needs translation, I give up!