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. <div class="gmail_quote">2009/3/19 Benjamin M. Schwartz <<a href="mailto:bmschwar@fas.harvard.edu">bmschwar@fas.harvard.edu</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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 <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </blockquote></div> -- "It is difficult to get a man to understand something, when his salary depends upon his not understanding it." -- Upton Sinclair