[Sugar-devel] Print Support proposal (need input) Beta

[Carol Farlow Lerche]

I disagree that print-to-pdf should be omitted.  I think print to pdf is
important for submitting  work in a portable, "frozen in amber" way.  The
printer interface may be on a platform that does not have support for all
the file formats of the native XO activities.  Someone may want to print an
artifact at a later time when activity file incompatibilities intrude.

2009/3/19 Benjamin M. Schwartz <bmschwar at fas.harvard.edu>

> Vamsi Krishna Davuluri wrote:
> > So in a classroom environment, can I assume the classroom server will be
> > acting as the server?
>
> You cannot assume; you have to decide what to require.
>
> Specifically, there are at least 3 different use cases you may choose to
> support:
>
> 1. USB printer connected directly to the Sugar machine.
>
> 2. Networked printer, no server. Sugar prints directly over the network.
>
> 3. All printing passes through a server.
>   a. networked printer with restricted access
>   b. USB printer connected directly the server
>      and also
>   1. the server may print every submission immediately
>   2. apply automatic quotas, or
>   3. require manual approval
>
> None of these use cases is currently supported.  You will have to figure
> out which ones you want to support.
>
> I agree with Carol that #3 is the one most likely to be useful in large
> school deployments.  Conversely, #1 is the one for which OLPC has had the
> most requests, from adults who bought XOs during the Give 1 Get 1 program.
>
> I think you should focus on #3 and ignore #1 and #2.  I say this because
> #3 does not require CUPS, or _any_ printing stuff, in Sugar.  You don't
> even need to include the "print to PDF" functionality in Sugar.  All you
> need to do is send the file you want to print to the server, over the
> network.  The server (running CUPS) can take the file (png for Paint, jpg
> for Record, odt for Write) and convert it to postscript for printing.
>
> I see two main virtues to this approach: it is easy to implement (so it is
> likely to work), and it minimizes the amount of software running in Sugar.
>  Sugar is tightly constrained in memory and disk space, so it is always
> best to achieve your goals with as little code as possible.
>
> What I am suggesting is a very minimal approach to printing.  For example,
> there is no way for users to choose to print a single page from a
> document, portrait vs. landscape, DPI, grayscale vs. color, double-sided,
> Tray 3 or Tray 4... but that's OK.  Sugar is designed to be simple to use,
> even for users who cannot yet read.  Once we have basic printing of whole
> documents, then we can begin to add these kinds of advanced options.
>
> --Ben
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090319/0da3de29/attachment.htm