OK, we just had an animated conversation on IRC in which almost nothing was generally agreed-on.<br><br>Here's my refined proposal based on that conversation.<br><br>"Print preview" option in journal<br><div style="margin-left: 40px;">
Uses cups filters to convert to PDF<br>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.<br><div style="margin-left: 40px;">filters would NOT be part of sugar-platform, to leave maximum flexibility for deployments<br>if you had anything but the exact, limited set of "print-enabled" filters, printing behaviour would be officially undesigned and unsupported<br>
<div style="margin-left: 40px;">but nevertheless probably sane<br></div>enforcement would be social, not digital<br></div>
<span style="background-color: rgb(255, 255, 255);">the PDF thus created would have special "print-me" tag<br></span></div><span style="background-color: rgb(255, 255, 255);">To add to print queue, or any other queue management, you'd use Browse<br>
</span><div style="margin-left: 40px;"><span style="background-color: rgb(255, 255, 255);">there are several options for </span>streamlining the workflow. <br><div style="margin-left: 40px;"><span style="background-color: rgb(255, 255, 102);">the moodle form could have metadata in the tag for the upload control to tell sugar to please filter for "print-me" tag</span><br style="background-color: rgb(255, 255, 102);">
<div style="margin-left: 40px; background-color: rgb(255, 255, 102);">this means making sugar understand this kind of metadata - independently useful<br></div><span style="background-color: rgb(255, 255, 102);">you could make a "print" activity, a spin of browse, which handles PDFs</span><br style="background-color: rgb(255, 255, 102);">
<div style="margin-left: 40px; background-color: rgb(255, 255, 102);">it would open the PDF using a pdf-viewer plugin<br>it would have an "enqueue" menu item<br><div style="margin-left: 40px;">choosing this menu item would go to moodle and put the pdf in the upload tag (using some greasemonkey-like trick)<br>
</div>You could modify sugar to know when to use "Print" instead of "Read" by default, based on "print-me" tag<br><div style="margin-left: 40px;">using something in <a href="http://activity.info">activity.info</a><br>
this functionality would be independently useful<br></div></div></div></div><br><span style="background-color: rgb(255, 255, 102);">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 pdfs with a "print-me" tag</span><br>
<div style="margin-left: 40px;">gtkprint would be a dependency of sugar<br></div><br><br><br><br>