<div class="gmail_quote"> Yep, agreed, though for some reason if the user has a file other than that specified format, and wants to print it badly (say a file which he just transferred from his pendrive), in-activity printing would never work, and even having a missing odf filter would be inviting a loophole. So my idea is I will create a filter for every default format and include it (which is only odf) (we wont have even one additional filter, and as we wont be requiring PPD files for either wifi printing or pdf conversion through cups-pdf we would be reducing the installation size greatly) that taken care of, here's a brief outlline of journal printing, we create a new button, for previewing purposes open it with read, for print purposes link to a printing activity (building a print activity is final step) end gsoc. apart from moodle this is the skeleton I think is best. instead of trying to write print code for each new activity why not just see to it that we follow a norm of filters? OR TWO! , we avoid all this complicated stuff, we make read our printing dock, any file sent to journal will be opened by read when we want to print it or preview it and for all the objects this will do pdf drawing for moodle and create a journal item as pdf too, and for direct printing use gtkprint. Please, try to agree to one of these, both are technically journal printing, both send pdf to moodle.<div><div></div><div class="h5"> <div class="gmail_quote">On Wed, Apr 22, 2009 at 12:05 AM, Andrés Ambrois <<a href="mailto:andresambrois@gmail.com" target="_blank">andresambrois@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="font-family: 'DejaVu Sans'; font-size: 9pt; font-weight: 400; font-style: normal;"> <div>On Tuesday 21 April 2009 14:16:36 Tomeu Vizoso wrote: > On Tue, Apr 21, 2009 at 19:02, Carol Farlow Lerche <<a href="mailto:cafl@msbit.com" target="_blank">cafl@msbit.com</a>> wrote: > > It's entirely unclear what this project has morphed to. Tomeu, what use > > is uploading arbitrary journal entries to Moodle? > > Because the chances that the needed filter to convert that file to a > printable format is in the server are bigger than being in every > machine, for some deployments. > > > I thought creating pdf > > output in sugar and enabling uploading of the pdf to Moodle was the point > > of this project. That is useful in two ways. First, it is a path to > > assignment turn-in or printing either through Moodle or by other > > transports to a system configured to print pdfs. It also allows a > > student to review the printer-ready output to decide if it is worth > > getting hard copy. > > Sure, I though I had made clear than printing to PDF in Sugar has > important use cases. > > Regards, > > Tomeu </div>My idea for dealing with the headache of filters is assuming only pdf/ps is printable, and having the Journal display a "Print" button if and only if the mimetype is pdf or ps. This way we can then make the decision of sending it to moodle via xml-rpc, a local cups queue, or a remote cups server using lpr. Activities that can't output to pdf/ps will be provided with gtkprint facilities and a pdf journal entry will be generated after they draw their output. Vamsi has already hacked pdf output into Write, so that's one big activity we will have covered. For the security issues, activities will only generate a journal pdf entry, which would be displayed using show_object_in_journal or somesuch (just like Chat currently handles opnening URLs). The user will then have the ability to immediately review the printable output and/or send it to the preferred queue. This architecture follows some basic principles: 1) Paper/Ink is expensive, we need a way to easily and reliably review what's going to be printed. Requiring people to load up Browse, navigate inside Moodle, and download a PDF file for review, is not exactly user-friendly. 2) We don't need to specify a set of "required" filters...yet, we can easily expand this to "well, HTML, JPG and PNG are probably going to be supported by every CUPS out there, so admit those as well", but I think 1) is priority here. 3) Following up on 2), the journal mechanism is orthogonal to what we end up sending to Moodle. Ben and Tomeu have sort of agreed on sending the raw journal entries to Moodle, so we can use all the CUPS filters on the server, this conflicts with 1) in my view, but it has its advantages. <div><div></div><div> > > On Tue, Apr 21, 2009 at 9:36 AM, Tomeu Vizoso <<a href="mailto:tomeu@sugarlabs.org" target="_blank">tomeu@sugarlabs.org</a>> wrote: > >> On Tue, Apr 21, 2009 at 18:29, Benjamin M. Schwartz > >> > >> <<a href="mailto:bmschwar@fas.harvard.edu" target="_blank">bmschwar@fas.harvard.edu</a>> wrote: > >> > -----BEGIN PGP SIGNED MESSAGE----- > >> > Hash: SHA1 > >> > > >> > Tomeu Vizoso wrote: > >> >> Printing is not limited to uploading files to moodle, we provide both > >> >> local and server printing and users will use whatever works in their > >> >> environment. > >> > > >> > I think this is too much for one Summer of Code project. That's why I > >> > have been recommending that we forget about local printing for now. > >> > >> I would actually be happy if we just implemented sending journal > >> entries to the print queue and the moodle module. Print to pdf has > >> several important use cases and I would like to see it implemented for > >> 0.86 for at least Write and Browse, but I don't think it needs to be > >> part of this GSoC. > >> > >> > Anyway, on a purely technical level I think we have reached agreement. > >> > (I > >> > do wonder whether the Moodle print queue should also support acting as > >> > a standard print server, so that standard desktops can print into the > >> > Moodle > >> > approval queue, but that's a detail.) > >> > >> Yeah, I would prefer if we use simple file upload at first because it > >> works already. > >> > >> There's lots of fun stuff to do in this area, but what gives most > >> value to the user is quite straightforward. We should aim to leave the > >> complicated stuff for the end, as extras, and focus on delivering what > >> matters most first > >> > >> Regards, > >> > >> Tomeu > >> > >> > - --Ben > >> > -----BEGIN PGP SIGNATURE----- > >> > Version: GnuPG v2.0.10 (GNU/Linux) > >> > > >> > iEYEARECAAYFAknt9FQACgkQUJT6e6HFtqTjmwCfdM831aiEMbpRiJNQLX8Bf2FY > >> > OH8AniCGOPuqgY/GlR+V2io6+/NyiTnl > >> > =KI8s > >> > -----END PGP SIGNATURE----- > >> > >> _______________________________________________ > >> Sugar-devel mailing list > >> <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a> > >> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> > > > > -- > > "It is difficult to get a man to understand something, when his salary > > depends upon his not understanding it." -- Upton Sinclair > > _______________________________________________ > Sugar-devel mailing list > <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a> > <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> -- </div></div> Andrés</div></blockquote></div> </div></div></div>