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

← Older edit

@@ 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.
-   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
-   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.
-*  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).
+*
+   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:
 ) we would send in a query with the name of the file and a .pdf extension
@@ Line 25: / Line 33: @@
 ) send suitable message back
-*  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.
+*
+   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!
+[[User:IwikiwI|IwikiwI]]
+== Why the distinction? ==
+To me, "mark for printing" and "save as PDF" should be one single option, as both should result in a PDF in the journal. "unmark for printing" would be something you did on that pdf, not on the original file. [[User:Homunq|Homunq]] 00:25, 31 March 2009 (UTC)
+'''Answer'''
+I edited my proposal a lot so its more understandable now.
+But my idea is use the same code, and when mark as printing is done, the pdf generated will not be shown to the user. It will be hidden and after sending it to the moodle queue, it will be deleted.And till that happenes only he can unmark for printing, Which will destroy the job before it reaches moodle's datastore.
+After this he's free to again mark for printing. :D
+And since only Write (abiword) can generate pdfs atm, we wont be able to generate pdfs for .py, or image types from other applications.
+A global pdf generation button would be awesome. And Unique!
+And the reason I do conversion for case one is, a scenario where sugar recognized format might not be recognized by the teacher's machine.
 [[User:IwikiwI|IwikiwI]]