[Sugar-devel] Print Support (journal vs activity)

[Vamsi Krishna Davuluri]

[quoting tomeu]
Hi all,

my apologies for entering in this discussion so late, the soas and
distributions deadlines played very badly with the gsoc schedule.

If I understood correctly, the plan proposed in Vamsi's application
implies that the conversion from the format in which activities write
to a printable format like pdf would happen in the journal, I suppose
through the use of cups and a set of filters. Is this right?

I would like to know how we can expect that Sugar will be deployed
with all the filters that the user will need as she installs more
activities. Also would like to know if it has been considered to use
instead the same approach that regular linux apps use.

Thanks,
[/quote]

[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.

As an alternative he suggested I use gtkprint (for which again I have
written a script and shown to tomeu),

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
( the implementation can be found in pyabiword )

But this would mean we do printing to device, and printing to pdf within
activity only.

For the moodle part, when in the print page, for the upload slots we limit
it such that it can only upload pdfs

OR
what I had been thinking is, make py xmlrpc communicate with moodle's
datastore, have a 'print to moodle' within the activity itself, and upload a
maximum of three parallel live requests..
if 3 reached, disable the option
The status updates of print requests and such can again be found in the
moodle's print's user's page.
The rest will be same as my proposal.
[/quote]

So talking to my mentor and silbe, I think I have sketched it like this,

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.
after which simple cups code can be written to print that pdf or send to
moodle from journal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090421/5e17dc3c/attachment.htm