Ron Goldman wrote:
>
> Thanks to Simon & James for the comments.
>
> Fortunately I don't need to come up with an all inclusive printing
> solution. Basically my problem is to enable users running a modified vnc
> viewer on their local computer (Linux/Mac/PC), who are connected over the
> internet to their own Xvnc server running on a special Linux server
> machine, to have their Linux apps (which are child processes of the user's
> Xvnc server process) print to the user's local printer. So security issues
> or identifying the correct Xvnc server should not be a problem.
Like I said before; the unix version is the problem. Once you have
solved it for Linux/unix, the win/mac server would be a "trivial"
simplification/subset.
> >Simon wrote:
> > How would the apps running on the remote machine see the printer?
>
> I'm thinking that they would see a generic PostScript printer that would
> have an entry in the server's /etc/printcap file. They would have no idea
> about what type of printer the user actually has. So, as James suggested,
> the printing on the server side is to a (PostScript) file. This would go in
> a spooler subdirectory associated with both the user & the specific VNC
> session. The Xvnc server would act as the print spooler, taking files out
> of the spooler directory and sending them across the VNC connection to the
> vnc viewer application, which would either just send them to a
> PostScript-capable printer or run them through Ghostscript to print them.
Yes a vnc-print daemon is definitly the route. The daemon and your
vnc-server talk to each other privatly. Vnc-server passes the print job
back to your vnc-client via an extension to vnc protocol. Your
vnc-client then spools locally, and then sends it onto which ever
printer you have set.
The vnc-client print spooling can work quite well, like with PsionPrint.
Since this app is native to your desktop, it will understand about your
local printers. So printer related errors will be reported to your
vnc-client mc, where you can best deal with them.
However in the PS world of printing, what about PPDs? The remote app
might want the know about the capabilities of the printer. Say what
paper sizes, resolution, etc. So we would like a mechanism where the PPD
could be virtualised. Then the remote app could have some chance of
asking the vnc-print daemon for printer metrics. Otherwise I could print
a doc to one paper size and find that the client can't print it.
This discussion seems to be heading down the route of having to have
printermetrics reported to the vnc-print daemon. Then the daemon can
know what is on the other end. Also the print errors can be reported to
the appropriate link in the chain.
But a general unix app does not know about vnc, so how does the
vnc-print daemon know which vnc-client requested the print? It is no
good looking to see if the requesting app is a descendant of the
vnc-server, i.e. called from the Also with shared vnc sessions, which
vnc-client of a specific vnc-server process requested the printing? We
need a unix hacker to help us out on this.
There is a possible hack to this: have a vnc aware app sitting on your
vnc-server desktop. It will talk to the vnc-print daemon, and forward it
to your vnc-client. Also you could bypass the vnc-server, and possibly
client, altogther. The vnc-print-desktop-print-controller talks direct
to your client end's native spooler app. If it used an unused port, then
vnc would never know. If the ip-port # was in the range permitted for
vnc, then your firewall wouldn't know it wanted to interfere. All this
would fall down if your were short of port numbers. But since it is
mechanically idependant of vnc, it could be used for any other remote
printing, totally outside vnc. However watch for security holes.
Since we have three tame apps, they can start passing useful info
between each other. So in your local office you could have a desktop
m/c, and a vnc-print aware spooler. And on the vnc-server m/c we have a
print controller and a daemon. Then the server end desktop will known
that you had a PS error, out of paper etc. Also it can pass
printermetrics.
> If the app produces files in some other format (e.g. troff, DVI, etc.) then
> either the normal Linux lpr filtering will translate them to PostScript, or
> the user will need to manually run a program to convert them to PostScript
> & then print that.
See above, resolving this feature is trivial when the print daemon to
vnc-client has been solved.
But much more cool: what if your vnc-client m/c had a good dvi renderer,
and the vnc-server had never heard of dvi? Send your dvi to print, it
tunnels through to your vnc-client-spooler, that redirects it
appropriatly. So now you can print dvi on an palm, or whatever.
--
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
---------------------------------------------------------------------
