[Sugar-devel] Fwd: Print Support (journal vs activity)
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. On Wed, Apr 22, 2009 at 12:05 AM, Andrés Ambrois andresambr...@gmail.comwrote: On Tuesday 21 April 2009 14:16:36 Tomeu Vizoso wrote: On Tue, Apr 21, 2009 at 19:02, Carol Farlow Lerche c...@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 to...@sugarlabs.org wrote: On Tue, Apr 21, 2009 at 18:29, Benjamin M. Schwartz bmsch...@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
Re: [Sugar-devel] Fwd: Print Support (journal vs activity)
I vote for the second option. Having Read do this makes sense to me: if you want to read (including preview) something you either read it off the screen or print it and read it off a paper. 2009/4/22 Vamsi Krishna Davuluri vamsi.davul...@gmail.com: 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. On Wed, Apr 22, 2009 at 12:05 AM, Andrés Ambrois andresambr...@gmail.com wrote: On Tuesday 21 April 2009 14:16:36 Tomeu Vizoso wrote: On Tue, Apr 21, 2009 at 19:02, Carol Farlow Lerche c...@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 to...@sugarlabs.org wrote: On Tue, Apr 21, 2009 at 18:29, Benjamin M. Schwartz bmsch...@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
Re: [Sugar-devel] Fwd: Print Support (journal vs activity)
[21:52] bemasc iwikiwi: Read only handles pdf, and nothing else. You still need all the conversion filters. [21:54] bemasc (Read actually can handle a few things other than pdf, but not jpg, png, odt, txt, html...) [21:55] bemasc iwikiwi: now, if you want, you could write a Print activity that can handle all these types. Presumably, that means including conversion filters inside the Print activity [21:55] iwikiwi bemasc, yep, just checked the documentation, and I want that particular case implemented, that is transfer a file from pendrive, then get it printed, so either I make all file export capable activities print or I just make a cups-pdf printing activity. [21:55] iwikiwi bemasc: exactly my thoughts :D [21:56] CIA-56 Sugar: sayamindu sucrose-0.84 * r091d2ead5ef3 /po/es.po: Commit from Sugar Labs: Translation System by user sayamindu. 18 of 18 messages translated (0 fuzzy). [21:56] bemasc iwikiwi: This Print activity could actually be built into Read, or it could be its own new Activity. [21:57] bemasc That's something you will have to decide. [21:57] iwikiwi bemasc: building it into read seems reasonable, but I wonder if I can add odf viewing to read... if i can everything is solved [21:58] bemasc iwikiwi: of course you can. Just convert to pdf and open with evince. [21:59] -- kristianpaul has left this server (Read error: 110 (Connection timed out)). [21:59] iwikiwi bemasc: okay, so thats internal again, done. this way journal wont have to be disected much. [22:00] bemasc I like this idea. The cool thing about Read is the interface, which is designed to be usable (on the XO) in tablet mode. [22:00] bemasc If you do it this way, then as an additional benefit, Read will gain the ability to view all these different formats. [22:01] iwikiwi bemasc: okay, so when ever we open files in read, we do this, cups-pdf internally makes a temp object which read displays, and when we exit read, the object is destroyed, mean while within read it can be made a journal item, or sent to moodle or direct printing [22:02] iwikiwi very nice! [22:02] bemasc That sounds good to me. [22:02] bemasc I'm not sure if you even need cups-pdf, but it might be the easiest way. [22:03] iwikiwi hmm, what is the harder way you have in mind? [22:03] bemasc I mean, you want Read to be able to open a .odt file. [22:03] bemasc To do that, the .odt has to be converted to pdf, using libabiword. [22:04] CIA-56 Sugar: sayamindu sucrose-0.84 * rfcd966df0030 /po/es.po: Commit from Sugar Labs: Translation System by user sayamindu. 18 of 18 messages translated (0 fuzzy). [22:04] Nubae tomeu: my ip seems to be blacklisted and I cant commit to git, alsroot suggested I ssh proxy via your server [22:04] iwikiwi bemasc: actually this is easier, as i wont be needing to write a new filter [22:04] bemasc So you have two options: you can add a odt filter to cups, and then use cups-pdf. [22:04] tomeu heh [22:04] bemasc Or you can write your own code to say it's an odt, so I'll use libabiword to convert it. [22:04] tomeu Nubae: don't have an account in shell.sl.o? [22:05] Nubae nope [22:05] bemasc iwikiwi: I don't know which way is easier. [22:05] tomeu Nubae: you should! [22:05] tomeu bernie: happen to be around? [22:05] alsroot tomeu: last time i blacklisted shell.sl.o :) -- but it could be resolved now [22:05] CIA-56 Sugar: sayamindu sucrose-0.84 * r5cf22accff75 /po/es.po: Commit from Sugar Labs: Translation System by user sayamindu. 18 of 18 messages translated (0 fuzzy). [22:05] tomeu alsroot: the blacklist is not per host and per key? [22:06] tomeu hmm [22:06] Nubae heh, yeah, it hasnt been needed till now [22:06] tomeu no, may be per host [22:06] Nubae I've deleted my key several times and recreated [22:06] alsroot tomeu: it it per IP-key then its ok [22:06] Nubae without luck [22:06] tomeu Nubae: can you comment in the ticket already open about it? [22:06] tomeu this is really a pita [22:06] Nubae yep [22:06] iwikiwi bemasc: I take 2nd, but I think I will leave this one bit till 6th, so i can actually play with the abiword framework code :p [22:07] iwikiwi i have endsem exams running atm pretty much sums it up, its either use pyabiword or cups-pdf for internal conversion :D ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
