Ron Goldman wrote:
>
> Currently if someone wishes to print from an application running in a VNC
> session, the printer must be visible to the computer running the VNC server
> (and the server also probably needs to have a driver for that type of
> printer). If the user is behind a firewall or does not want to make their
> local printer visible to the entire net, then they are forced to print to a
> file on the server, transfer that file to their local machine, and then
> print it.
>
> There is no simple way to set things up so that applications on the server
> can print to a printer on the client computer. The folks at WorkSpot want
> to change this, so I'm exploring extending the current VNC protocol to
> support local, client-side printing: a printing request on the server-side
> would be redirected to the Xvnc server, sent over to the client (vncviewer)
> and printed on a printer connected to the client computer. Initially only
> plain text & PostScript would be supported.
>
> I welcome any comments about the issues involved in doing this or
> suggestions on how to best proceed.
How would the apps running on the remote machine see the printer? (this
isn't intended to sound like a flame). In unix the printers are
installed/maintained by root using printcap (or equivilant), so your vnc
server can't install/unistall printers willy nilly. The applications are
running in plain unix space, and just so happen to be talking to a GUI
controller, which happens to also be a desktop controller. So to
applications print to vnc, you would have to enable each app (recompile
with a vnc print lib).
For what it's worth I have a possible solution. Just like with a fax
print driver, you can send meta info with the print job to the driver
(in that case the fax #), you send some sort of session key. The vnc
print daemon picks this up, redirects it to your own vnc server process,
which then tunnels it to your client, which then prints it.
Bear in mind that we can have lots of users & vnc servers running on the
same machine, so inter-process security could be an issue. However every
process belongs to another, so by looking back up the tree you could
tell which vnc process printed the job. But even that can break, bum.
The rest is left as an exercise for the reader :-).
Having identified which vnc server asked for the print is not the end of
it. With non-shared vnc servers, the vnc session can be snatched away
from you at any moment. I think that you need a modification so that the
print session belongs to the vnc client instanciation, not to the vnc
server per se.
Also what about protocol versions? Some clients will support the
vnc-print, some wouln't, similarly with serrvers. This can be resolved
with "masonic handshakes". But what sort of printer control protocol
should we use? I have vnc on mac+win+linux, all of which control their
printers in different ways. I would suggest that the vnc-server sees
your printer in the way its OS would normally expect to see a spooler.
Then the vnc-print protocol sorts the "shares".
So far as print protocol is concered, I don't see too much a problem (ha
ha). our vnc-print provides a spooler, so long as both ends know what is
connected, then we should all be happy. So if you had say, a GDI
printer, on your vnc-client m/c, you would want the vnc-server end to
know this. The application on the vnc-server m/c would need to: a) know
this is a GDI printer, and b) be able to print GDI. And the same for
HPCL etc. So iff I can get my KOffice app to print GDI, then it's none
of the spooler's business, just so long as the instructions come out OK
at the actual printer. Clealy there should be some chat, based on the
vnc-server's OS way of talking to printers+spoolers, to determine which
kind of printer hangs of the back end.
There is an existing model that you might like to play with: a Psion's
remote printing. The Psion sits in its cradle with a spooler running on
your desktop m/c. You select the PsionPrint printer in the Psion, and
print your document to it. The PsionPrint forwards this down the link
cable to your PC, where it gets spooled. This spooler is itself a native
desktop app, that can send the printjobs onto any visible printer. So
the vnc-print server module could be quite stupid, and just forward data
to the vnc-client. It's up to the vnc-client to spool manage and worry
about PS or HPCL errors or out-of-paper etc.
Any good?
--
Simon Dales, Publication Software Engineer
"The impossible is easy"
Nuffield Press Ltd., 21 Nuffield Way, Abingdon, Oxford, OX14 1RL,UK
+44-1235-558637
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
