Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!mailrus!rutgers!tut.cis.ohio-state.edu!osu-cis!att!ihlpl!ihtnt!ihtlt!kosman!kevin From: kevin@kosman.UUCP (Kevin O'Gorman) Newsgroups: unix-pc.general Subject: Re: UNIX-PX Printer Setup Keywords: 3B1 windows Message-ID: <724@kosman.UUCP> Date: 21 Mar 89 15:39:38 GMT References: <1441@mtunb.ATT.COM> Reply-To: kevin@kosman.UUCP (Root) Organization: K.O.'s Manor - Vital Computer Systems, Oxnard, CA 93035 Lines: 87 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!