[FreeNX-kNX] printing using pdf (was printing under freenx/knx)

[Cardon Denis]

Hi,

> Cardon Denis skrev:
> > I was also wondering how developers are planning to implement printing
> > in the next release. Will it use cups (somehow like above)? Or will it
> > use pdf (print pdf on the server, transfer file, print file on client
> > side)? To my mind pdf is probably the most stable and universal
> > solution. I experienced it on a citrix server, and it resolves many
> > printing issues.
> 
> Reading about your pdf suggestion I started thinking.
> We already have filesharing working, one could use that. When sharing
> files on the nxclient they will appear in ~/MyShares/<ShareName>. What
> about auto-creating a share ~/MyShares/PrintQue, and then the nxclient
> automatically probes that directory and opens a print dialog for any pdf
> or ps files it detects in it client-side. KDE already have print-to-pdf,
> and you can always print-to-ps. This would be somewhat unnatural
> behavior, as it would be two steps to perform a print (create the pdf,
> using server-side print dialogs, and print it, using client-side print
> dialogs).
> If autocreating a share would be a problem, one could do it the other
> way around, creating a ~/MyShares/PrintQue folder on the nxserver, and
> use scp in ssh to fetch any pdf/ps files in it.
> Still only supports native X11 connections and VNC connections to
> localhost (eg the nxserver itself) though...
> 
> Both these solutions would require changes in the client, and would thus
> not be feasible until !M version 1.5. It somehow feels wrong to
> introduce this kind of hack on that large timescale. Before 1.5 we
> should have plenty of time to implement a "real" printing solution...

Printing under citrix is one of the most problematic part of that kind
of setup. Citrix is quite featureful and may recreate printers on the
server side like the real printer on the client side (you may even have
driver upload to get all the bells and whistle of your local printer).
This may seem a great solution and indeed it works great as long as you
have standard printers (all of them with server-native printer drivers,
so no alien driver installed), and you are on a local or fast network.
When working with low bandwidth connexion (like 2-3 persons per 64kbps
ISDN connexion), then it becomes a nigthmare.

So there are plenty of addons have sprouted to solve this issue, many of
them using pdf as a mean of getting the file from the server to the
client (like uniprint and al.)

The two steps approach is not necessary if one can hack a server side
pdf printer driver that could recognized who is printing (cups does that
so it shouldn't be too hard to get this info), and then to transfer that
pdf print job to a local temp directory on the client side base on the
login of the user (may have issues with multiple login from different
location with the same login name though). Then on the client side,
there could be either be pooling of the temp directory for new jobs, or
there could be a messaging mechanism to inform of the new print jobs.
Once the new print job is seen on the client side, the pooling/messaging
mechanism would fire up acrobat reader / gpdf / kghostview etc. in order
to allow the user to see the print job and chose the printer he wants to
print to.

I'm not a great C/C++/bash coder (a few years of java have washed my
brain), so I cannot tell exactly the complexity of such a setup, but it
does not seem to be so hard to implement (please correct me if I'm
wrong). As far as Windows client are concerned, this method could also
be applied without much difficulties I guess.

Concerning rdesktop connexion, we would require to find a way to know
which user is sending the print jobs in order to redirect it correctly.
Since the pdf print driver would be embedded in cups and then samba
printing subsystem, it should be possible to get the user name (I saw a
post from kurt on the samba mailing list dealing with user name
authentication, so I think he may shed some light on that one). It may
require mapping to unix user name though if naming convention are
different.

Cheers,

Denis
-- 
Denis Cardon
Tranquil IT Systems
10 rue du Docteur Bouchard
49400 Saumur
tel : +33 (0) 2.41.67.56.99
fax : +33 (0) 2 41 51 71 97
mob : +33 (0) 6 81 66 27 62
http://www.tranquil-it-systems.fr