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

[Jameson Quinn]

My point of view is that, ideally, printing should be from the journal (or
even from a separate "print" activity), for both security and UI reasons.
The UI reason is that conceptually separating "edit document" and "preview /
print document" is a workflow that will likely save resources.

So the workflow I'd propose is the following. In grey are items that I'd
consider optional for this GSoC, in yellow are ones that I'd consider
clearly outside the scope of this GSoC.

"Print preview" option in journal
Uses cups filters to convert to PDF
Set of cups filters available is distribution dependent. An officially
"print enabled" distribution would have a certain limited set of filters
installed (the obvious ones). Filters outside this set would be mildly
discouraged to avoid inconsistent behaviour.
the PDF thus created would have special "print-me" metadata
in other words, sugar would use metadata to choose which of several
activities which handle a mime-type to use as default
"send to print queue" option for pdfs
default action from journal for "print-me" pdfs
provided by an activity which handles only pdf mime type
in GSoC time-frame, this could be an activity with NO UI, just send to queue
and terminate
later, this activity could first show a preview and allow send-to-queue as
an option
there could be an alternate version of this activity which actually printed
directly, over USB or wirelessly
Obviously, these pdfs could also be viewed using "open with"-"Read".
All queue management besides enqueue would be done through browse/moodle
Activities which wanted printing but did not naturally produce a format
within our basic filter list, could have a "print preview" menu item and use
gtkprint to export to "print-me" pdfs.
gtkprint would be a dependency of sugar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090421/c5bdfbb9/attachment.htm