Hello, Tomeu ( from his sugar maintainer perspective) has expressed a potential disaster in the part-1 of my proposal, that is by using CUPS-Pdf we would be actually required a great load of filters which would be a nightmare for the maintainers. And also the issue to register each mime type with every install of a new activity, for which we would have to wait till a new sugar update. As an alternative he suggested I use gtkprint (for which again I have written a script and shown to tomeu), So anyway gtkprint makes use of a structure which is rendered to cairo objects and thus prints the screen as a pdf or prints to a printer ( a wrapper around cups) but the advantage is we dont utilisie that many filters again ( the implementation can be found in pyabiword ) But this would mean we do printing to device, and printing to pdf within activity only. For the moodle part, when in the print page, for the upload slots we limit it such that it can only upload pdfs OR what I had been thinking is, make py xmlrpc communicate with moodle's datastore, have a 'print to moodle' within the activity itself, and upload a maximum of three parallel live requests.. if 3 reached, disable the option The status updates of print requests and such can again be found in the moodle's print's user's page. The rest will be same as my proposal. Martin, Jameson, suggestions and comments please.. Thank you