<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'DejaVu Sans'; font-size:9pt; font-weight:400; font-style:normal;">On Tuesday 21 April 2009 14:16:36 Tomeu Vizoso wrote: > On Tue, Apr 21, 2009 at 19:02, Carol Farlow Lerche <cafl@msbit.com> 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 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. > > On Tue, Apr 21, 2009 at 9:36 AM, Tomeu Vizoso <tomeu@sugarlabs.org> wrote: > >> On Tue, Apr 21, 2009 at 18:29, Benjamin M. Schwartz > >> > >> <bmschwar@fas.harvard.edu> 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 > >> Sugar-devel@lists.sugarlabs.org > >> http://lists.sugarlabs.org/listinfo/sugar-devel > > > > -- > > "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 > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel -- Andrés</body></html>