Oh well. Thats why I said it's almost certainly not a viable approach. I knew the app would draw on the screen and that screen data would wind up injected into, and thus screwing up, the print job. It may still be possible but you are on your own now, it's no longer a generic issue but one that needs in depth look at your application to see what -exactly- it does, and what, if anything, can be changed about it, and what can be lashed together around it. This may be a start, something printed, merely it needs to work better now, or it may be a total waste of time. I have no idea if there is any such kernel module or daemon as what I'm about to describe, but the one way I beleive this would work is the way Digi multiport intelligent serial card drivers work. Because they are a kernel driver for the very tty your terminal is using (in the case of a serial terminal hooked to a digiboard), it's possible for the driver to do a little magic and provide virtual printer device files. The driver provides device nodes like /dev/ttyNNNp where NNN is the normal tty name for some port on the digi and NNNp is the printer on that tty. Any program any where any time may send data to /dev/ttyNNNp just as if it was a plain dedicated serial printer. The _driver_ can do what no other process can do, which is block other things from writing to the tty while it sends ansi print data. Since it happens at the kernel driver level, it's transparent to all user processes without screwing them up at all. when a program tries to write to the tty while the driver is sending print data, the programs output is merely buffered and/or the program is told to wait. We used to use it a lot and it was perfectly solid. I see no reason why a generic kernel module or possibly even a userspace daemon process, possibly a /bin/login wrapper like the way ttysnoop works, could not be written to do that for any tty , with no relation to digiboards or any other serial ports. But since I don't need this, I'll leave you to investigate the possibility. good luck. -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! ----- Original Message ----- From: "Andrew Joakimsen" <joakimsen@gmail.com> To: "Brian K. White" <brian@aljex.com> Cc: <opensuse@opensuse.org> Sent: Saturday, September 06, 2008 8:46 PM Subject: Re: [opensuse] Native printing via SSH
I got it to print one page... but on the back it said Invoice # 40600 printed ok1;1H25;1HCreating file, reading record #1;1H25;4
And when the 2nd page printed it was not formatted (everything was stuck together with no spacing
And the application hangs with "Printing to LPT1:"
On Sat, Sep 6, 2008 at 7:05 PM, Brian K. White <brian@aljex.com> wrote:
----- Original Message ----- From: "Andrew Joakimsen" <joakimsen@gmail.com> To: "Brian K. White" <brian@aljex.com> Cc: <opensuse@opensuse.org> Sent: Saturday, September 06, 2008 3:49 PM Subject: Re: [opensuse] Native printing via SSH
That's precisely what I am trying to figure out. Do you know what the option would be called? The application writes PCL direct to the LPT port so if I can figure a way to block tty access (I don't think it will be an issue the application does nothing else while it prints and in the Windows environment if the printer is not setup correctly the app just hangs). I am trying to avoid forwarding ports or using a VPN... because if each user needs to have their own printer I think this way (with TTY printing) will be easier to mange on the server side.
Then you may be lucky. It appears to be possible to tell dosemu to run a command to print. In fact it appears to be the default way it prints. (last time I used dosemu was sometime in the late 90's and I seem to remember a completely different style of config and I seem to remember granting dosemu access to /dev/lp0 , not defining a spooler program. But, it looks simple enough.
Try this,
vi /usr/local/bin/ansiprint
#!/bin/bash # Print to ansi terminal printer stty raw </dev/tty echo -en "\033[5i" cat "$@" echo -en "\033[4i" stty cooked </dev/tty
then chmod 755 /usr/local/bin/ansiprint
Now put this in /etc/dosemu/dosemu.conf $_lpt1 = "ansiprint"
The script is used a lot on all my servers so it's heavily tested, but, you still may have some issue with the stty commands. You can comment them out and the only result will be that print jobs with lots of binary raster graphics data will fail. For several years I didn't have those lines either and almost a thousand end users did 100% of their buisinesses printing that way, so, even that way is ok.
The dosemu is untested. However, since the other examples are simply "lpr" then I know that dosemu must do one of two things, either it gives a temp file on the command line "lpr filename" or it pipes data into the command. The script works either of those ways so it should work, as long as you are right about the dos app's behaviour. I just did a "zypper in dosemu" and looked at the config file. I haven't actually run anything since I'm on the road at the moment using a centro as an evdo modem.
If it breaks, you get to keep the pieces :)
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org