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"
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
wrote: ----- Original Message ----- From: "Andrew Joakimsen"
To: "Brian K. White" Cc: 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
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