[Sugar-devel] Fwd: Print Support (journal vs activity)

[Lucian Branescu]

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.davuluri at 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 <andresambrois at 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 <cafl at 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 at sugarlabs.org>
>> > > wrote:
>> > >> On Tue, Apr 21, 2009 at 18:29, Benjamin M. Schwartz
>> > >>
>> > >> <bmschwar at 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 at 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 at lists.sugarlabs.org
>> > http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>> --
>> Andrés
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>