I have come up with two approaches: I will be concise this time. And try to talk less on sugarizing it. Thanks to tomeu and silbe, and a little fiddling around, it is now clear that rendering to pdf is in no way dependent on CUPS, it can be done with the cairo libs, and gtk print. And even documents are drawn as text and not images, so they are subject to copy/paste. So now come the approaches: 1) Implement print-to-pdf, transfer the file to the server in a normal tcp/ip protocol, and never interact with CUPS client side, the transferred file with open in a default viewer or a one after the other in a queue (FIFO) format. which can then be saved/printed/ deleted accordingly. The logic for printing to pdf with with cairo is fairly simple ( I have the code ready) . Now what is left is sugarizing them, The journal will be the printing hub, i will write a small activity that takes care of printing to pdf/ or sending a locally temporary pdf to server. 2) Install minimal cups-client packages on the laptops side. now we can directly interact with the cups print server through gtk print in the program, in the process avoiding writing code for file transfer. The rest will be very much the same. This will send a print request to the IPP queue of the server. There will be no use for print-to-pdf this way, but it can made available too. (please be ready to dish out a maximum of 20-25 mb disk space this way for the minimum cups installation) Please dont worry that there hasnt been enough eloboration on sugarizing it, I will include it in the proposal on the wiki page after this has been taken care of. :) Thank you