Difference between revisions of "Talk:Summer of Code/2009/Print Support"

From Sugar Labs
Jump to navigation Jump to search
Line 11: Line 11:
  
  
* Thing is we don't technically do a pdf conversion, CUPS comes with an emulator of the print engine, and prints to the PDF (cups-pdf modules to be specific to create a virtual printer). And we do this  
+
* Thing is we don't technically do a pdf conversion, CUPS comes with an emulator of the print engine, and prints to the PDF (cups-pdf  
 +
  modules to be specific to create a virtual printer). And we do this  
 
   because we would like for the teacher to review it.  
 
   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.
+
   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
 
   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   
+
   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.
 
   WYSIWYG only as we  send the files directly from the journal.
  
  
*  Yep, student can cancel his request, I forgot adding it. With The function cupsCancelJob() the student can cancel the job before his request goes to server (or before it can be printed to pdf).
+
*  Yep, student can cancel his request, I forgot adding it. With 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:
 
   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
 
   1) we would send in a query with the name of the file and a .pdf extension
Line 25: Line 29:
 
   3) send suitable message back
 
   3) send suitable message back
  
*  No, no. There is ABSOLUTELY no need to interact with sugar activities, in the cups folder we have a file with the list of mime types accepted. We would also append the server supported CUPS Mimes to  
+
*  No, no. There is ABSOLUTELY no need to interact with sugar activities, in the cups folder we have a file with the list of mime types  
 +
  accepted. We would also append the server supported CUPS Mimes to  
 
   the clients CUPS.
 
   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)
 
   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!
 
   There is no reason to read the file, the server handles the necessary post script conversions!
 
[[User:IwikiwI|IwikiwI]]
 
[[User:IwikiwI|IwikiwI]]

Revision as of 00:26, 24 March 2009

Looks pretty good. A couple of quick questions, while it is still unfinished:

  • Why do you do the PDF conversion on the server? Shouldn't the student be able to see a WYSIWYG version, margins and all?
  • Is there a way for a student to cancel a request?
  • At the moment, Sugar opens files by mime type, and each activity handles its own mime type(s). If you save a pdf to journal to be opened by the "send to server" activity, it would actually be opened by Read. Would you plan to modify sugar to have an "open with" metadata to cue it to open with your print activity? Or would you find some other workaround?

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 (cups-pdf
 modules to be specific to create a virtual printer). 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. With 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 back
  • No, no. There is ABSOLUTELY no need to interact with sugar activities, in the cups folder we have a file with the list of mime types
  accepted. 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!

IwikiwI