[quoting tomeu]<br>Hi all,<br>
<br>
my apologies for entering in this discussion so late, the soas and<br>
distributions deadlines played very badly with the gsoc schedule.<br>
<br>
If I understood correctly, the plan proposed in Vamsi&#39;s application<br>
implies that the conversion from the format in which activities write<br>
to a printable format like pdf would happen in the journal, I suppose<br>
through the use of cups and a set of filters. Is this right?<br>
<br>
I would like to know how we can expect that Sugar will be deployed<br>
with all the filters that the user will need as she installs more<br>
activities. Also would like to know if it has been considered to use<br>
instead the same approach that regular linux apps use.<br>
<br>
Thanks,<br>[/quote]<br><br>[quote=me]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.<br>
<br>As an alternative he suggested I use gtkprint (for which again I have written a script and shown to tomeu), <br><br>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 <br>
( the implementation can be found in pyabiword )<br><br>But this would mean we do printing to device, and printing to pdf within activity only.<br><br>For the moodle part, when in the print page, for the upload slots we limit it such that it can only upload pdfs<br>

<br>OR <br>what I had been thinking is, make py xmlrpc communicate with
moodle&#39;s datastore, have a &#39;print to moodle&#39; within the activity
itself, and upload a maximum of three parallel live requests..<br>if 3 reached, disable the option<br>
The status updates of print requests and such can again be found in the moodle&#39;s print&#39;s user&#39;s page.<br>The rest will be same as my proposal.<br>[/quote]<br><br>So talking to my mentor and silbe, I think I have sketched it like this,<br>
<br>essentially each activity will be checked if it can print to pdf/ps or not, if not code in activity.py draws a cairo object (pdf) and makes an entry of it in journal.<br>after which simple cups code can be written to print that pdf or send to moodle from journal. <br>
<br><br>