Changes

:'''1)''' (this is no way related to abiword's print to pdf ability)

:'''1)''' (this is no way related to abiword's print to pdf ability)

:The right click menu of an item in the journal will have a new option, i.e. send for network printing. When clicked, the item will be sent to a local virtual CUPS-PDF printer for PDF conversion, and the pdf will have metadata attached stating its details (this PDF plus metadata wont be visible to the user).The object is then said to be marked for printing and can be unmarked for printing too.(That is by again right clicking on the parent journal item and clicking cancel for network printing).

:The right click menu of an item in the journal will have a new option, i.e. send for network printing. When clicked, the item will be sent to a local virtual CUPS-PDF printer for PDF conversion, and the pdf will have metadata attached stating its details (this PDF plus metadata wont be visible to the user).The object is then said to be marked for printing and can be unmarked for printing too.(That is by again right clicking on the parent journal item and clicking cancel for network printing).

:Also a similar button will be provided for saving to PDF. Which will have a PDF file of the same in journal;the pdf will be tangible. (plus text will be mapped as text only)

:Also a similar button will be provided for saving to PDF. Which will result in a PDF file of the same parent in journal;the pdf will be tangible. (plus text will be mapped as text only)

:The usecase would be, distinction of saving a pdf and sending it to printing. And the conversion is mandatory so as to prevent a scenario where the sugar file type might not be recognized by the teacher's machine.

:The usecase would be, distinction of saving a pdf and sending it to printing. And the conversion is mandatory so as to prevent a scenario where the sugar file type might not be recognized by the teacher's machine.

:(The 2nd would be implementing queuing and teacher review, reject approve facilities         

:(The 2nd would be implementing queuing and teacher review, reject approve facilities         

:'''2)''' Through moodle the teacher will have a page displaying the contents of the moodle print datastore along with user names attached, and he/she will be able to download them to his remote system, and  check them and approve them for printing if he/she wishes. After his/her approval or disapproval (that is a delete along with an option why) the information is held in the datastore, and the user can view it in the form of history transactions pertaining to his id, and teacher can view a finite list of previous transactions pertaining to all.  :

:'''2)''' Through moodle the teacher will have a page displaying the contents of the moodle print datastore along with user names attached, and he/she will be able to download them to his remote system, and  check them and approve them for printing if he/she wishes. After his/her approval or disapproval (that is a delete along with an option why) the information is held in the datastore, and the user can view it in the form of history transactions pertaining to his id, and teacher can view a finite list of previous transactions pertaining to all.   

:( The 3rd usb printing on demand!)

:( The 3rd usb printing on demand!)

:For the sake of our python convenience we will be using a python wrapper to cups, pycups. The print objects will have metadata attached to them through the sugar datastore API.  

:For the sake of our python convenience we will be using a python wrapper to cups, pycups. The print objects will have metadata attached to them through the sugar datastore API.  

:For the second part of it when ever the print page url is accessed, we make browse communicate with the moodle print queue through xmlrpclib to get the queue details, and upload that many slots (as the number of slots will also be dependent on the print queue through a php trick). This would essentially mean a rainbow hack so that browse can communicate with journal without a dialog (Or a simpler way will be to bypass the dialog automatically). The execution part of this will take place dynamically as soon as the user requests the print page. And also, once the pdf is read, it is destroyed.

:For the second part of it when ever the print page url is accessed, we make browse communicate with the moodle print queue through xmlrpclib to get the queue details, and upload that many slots (as the number of slots will also be dependent on the print queue through a php trick). This would mean a rainbow hack so that browse can communicate with journal without a dialog (Or a simpler way will be to bypass the dialog automatically). The execution part of this will take place dynamically as soon as the user requests the print page. And also, once the pdf is read, it is destroyed.

:for step-2, We will be using the interface already created, but for the teacher we will issue global access privileges enabling him/her to access all the sent requests for his group.The approve button will initiate shell commands to send the particular file to a network printer through CUPS installed on the server.This can again be achieved through hacking into moodle and understanding how notifications are sent to the students from teacher. The notifications would be relating to whether the teacher has approved or disapproved the print.  

:for step-2, We will be using the interface already created, but for the teacher we will issue global access privileges enabling him/her to access all the sent requests for his group.The approve button will initiate shell commands to send the particular file to a network printer through CUPS installed on the server.This can again be achieved through hacking into moodle and understanding how notifications are sent to the students from teacher. The notifications would be relating to whether the teacher has approved or disapproved the print.  

:The moodle part can be achieved through hacking the already existing plugin [http://docs.moodle.org/en/Upload_a_single_file_assignment] and looking into the moodle API and plugin documentation. From my research so far, moodle has most of all the low level details already existing within the moodle libraries. Even $_GET $_POST methods are abstracted into simpler functions.

:The moodle part can be achieved through hacking the already existing plugin [http://docs.moodle.org/en/Upload_a_single_file_assignment] and looking into the moodle API and plugin documentation. From my research so far, moodle has most of all the low level details already existing within the moodle libraries. Even $_GET $_POST methods are abstracted into simpler functions.

:for step-3, no new code is required; a few more dependencies are required, Which wont exceed 17mb. We will be including print directly (usb), as an option under the item's right click menu too. This will essentially have the same code as print to pdf, but with code to select a new default printer added.

:for step-3, no new code is required; a few more dependencies are required, Which wont exceed 17mb. We will be including print directly (usb), as an option under the item's right click menu too. This will have the same code as print to pdf for the most part,and will have added code to select a new default printer.

:''Is there a disadvantage in relying upon moodle for network printing?''

:''Is there a disadvantage in relying upon moodle for network printing?''