I can't speak for the classroom, but in the house I have two kids very active with their Mac computers and often wishing to print. I think printing is an area where lots of little things can go wrong which need grownups to sort out.
I have a single printer connected to a computer on the main floor. The kids started out (at ages 9 and 11, two years ago) by trying to print everything, printing 80-page documents they downloaded, making minor changes to get something to "fit" and printing each one, not knowing what to do with the pile of badly printed paper, getting frustrated when no-ink message and I wasn't around to pop in a new cartridge. When I disapproved of printing a very long document, they got wise and paused the printer queue, sent their print job to the queue, went downstairs to see if I was around or not, then unpaused the queue. So I taught them to *always* print to PDF, check how it "came out", try again until it looked fine, *then* print the PDF. And if the printer was offline, instead of a crisis where they were worried about their stuff, they immediately had options: wait until I get home, e-mail it to a friend with a working printer, mail it right to the teacher. They learned to keep their PDFs in a directory and liked being able to look at or reprint an older document without looking for the source document, which moreover they had sometimes updated and wrecked the page layout and in this case they were able to fall back to the printable PDF. In particular, they appreciate that printing should be thought about twice before being done. What I like about the scenario of classroom kids gaining permission to print, hooking up directly, and then printing with the teacher is that it underlines the expense (including environmental) involved and boosts the probability that the teacher will be able to fix the little problems (paper jam, ink) which kids have trouble solving without making it worse (e.g. pulling out jammed paper and stripping gears). I, too, think the priority should be classroom needs, not adult G1G1 users. thanks Sean P.S. way back in the days of Windows v3.1, the CLI copy command (also available from the GUI file manager where I usually used it) was able to print to parallel port lptx devices, e.g.: copy /b mydoc.prn lpt1 this was a function I used all the time, very useful as it worked even if the parallel port in question was captured or redirected (i.e. with Netware and redirected to a print queue). This disappeared from Windows 95 onwards and I have missed it ever since. On Fri, Mar 20, 2009 at 11:46 AM, Albert Cahalan <acaha...@gmail.com> wrote: > 2009/3/19 Benjamin M. Schwartz <bmsch...@fas.harvard.edu>: > >> Specifically, there are at least 3 different use cases you may choose to >> support: >> >> 1. USB printer connected directly to the Sugar machine. > > This is likely, even in a classroom environment. The printer > may sit next to the teacher, who gives approval to connect. > Students show their work to the teacher, get approval, plug > in the cable, and print. Plugging in the cable might prompt > the user for printing, either to select things or to confirm jobs > that are already queued. > >> 2. Networked printer, no server. Sugar prints directly over the network. > > This is somewhat likely. It's very simple. You can get a tiny > box that will convert any printer into a network printer. > Networked printers tend to be reliable and cheap when you > don't ignore server costs. > >> 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 > > This is getting complicated. Real IT support will be needed. > The server, including all the extra cabling, is a failure point. > Usability drops; now one must boot the server and muck with > the permissions. > >> 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. > > Lots of useful software prints roughly like so: > > fp=fopen("/tmp/4wiP9r.ps","w"); > fwrite(printout,1,nbytes,fp); > fclose(fp); > system("lpr /tmp/4wiP9r.ps"); > > Sometimes PDF is used instead of PS. Sometimes popen() is used > instead of a tmp file. Sometimes lp is run instead of lpr. > Sometimes bare system calls (open,write,close,pipe,execve) are > used instead of stdio. > > For example, Tux Paint normally sends PS into popen("lpr"). > > CUPS is among the many ways to support this. It's certainly > not the only game in town. > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel