[Sugar-devel] Print Support proposal (need input) Beta
Carol Farlow Lerche
cafl at msbit.com
Thu Mar 19 13:59:00 EDT 2009
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
> 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.
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
"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...
More information about the Sugar-devel