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 <bmsch...@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@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@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel