143
edits
Changes
Jump to navigation
Jump to search
Line 8:
Line 8: + + + + + + + + + + + + + + + + + + +
Talk:Summer of Code/2009/Print Support (view source)
Revision as of 22:51, 23 March 2009
, 22:51, 23 March 2009no edit summary
[[User:Homunq|Homunq]] 03:01, 24 March 2009 (UTC)
[[User:Homunq|Homunq]] 03:01, 24 March 2009 (UTC)
* Thing is we don't technically do a pdf conversion, CUPS comes with an emulator of the print engine, and prints to the PDF. And we do this because we would like for the teacher to review it.
The pdf is stored in a web folder on the server, and through moodle the teacher goes through them (we provide a webpage), and approves the ones he thinks appropriate for printing.
I explained it my explanation
The outcome of my second draft (beta) was that students should be provided as minimal functionality as possible. They shouldn't be given too much flexibility or options. And... you get
WYSIWYG only as we send the files directly from the journal.
* Yep, student can cancel his request, I forgot adding it. The function cupsCancelJob() the student can cancel the job before his request goes to server (or before it can be printed to pdf).
But after actually entering the web folder, It would become a bit complex. I would have to do this:
1) we would send in a query with the name of the file and a .pdf extension
2) if that file exists on web folder delete, otherwise do nothing
3) send suitable message
* No, no. There is ABSOLUTELY no need to interact with sugar activities, cups has a folder with its supported mimes in it. We would also append the server supported CUPS Mimes to the clients CUPS.
IF the mime type exists in cups mime.type , we are all good to do printing from journal. (that is why we require step 1)
There is no reason to read the file, the server handles the necessary post script conversions!