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

Vamsi Krishna Davuluri vamsi.davuluri at gmail.com
Wed Apr 22 08:32:46 EDT 2009


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090422/71fd8fa0/attachment-0001.htm 


More information about the Sugar-devel mailing list