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

[Sean DALY]

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 <acahalan at gmail.com> wrote:
> 2009/3/19 Benjamin M. Schwartz <bmschwar at 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 at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>