Ooops, I forgot. In my proposal, local printing would be done by a separate activity which handled only PDFs. Many deployments would never install this separate activity.<br><br><div class="gmail_quote">On Tue, Apr 21, 2009 at 11:58 AM, Jameson Quinn <span dir="ltr"><<a href="mailto:jameson.quinn@gmail.com">jameson.quinn@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<div class="im"><br><br>"Print preview" option in journal<br></div><div style="margin-left: 40px;"><div class="im">
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><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" target="_blank">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><div><div></div><div class="h5"><br>
<div style="margin-left: 40px;">gtkprint would be a dependency of sugar<br></div><br><br><br><br>
</div></div></blockquote></div><br>