[Sugar-devel] Print Support (journal vs activity)

[Tomeu Vizoso]

On Tue, Apr 21, 2009 at 15:28, Benjamin M. Schwartz
<bmschwar at fas.harvard.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vamsi Krishna Davuluri wrote:
>> [quoting tomeu]
>> I would like to know how we can expect that Sugar will be deployed
>> with all the filters that the user will need as she installs more
>> activities. Also would like to know if it has been considered to use
>> instead the same approach that regular linux apps use.
>> [/quote]
>
> Regular linux apps print through CUPS.  To print something through CUPS,
> you submit a file to CUPS's print queue, for example using the "lpr"
> command.  This file has to be in one of the formats CUPS supports.  That
> list of formats is different on different machines.  To see the list on
> your machine, look at "/etc/mime/mime.convs".  This shows the list of
> supported MIME types, and the command needed to process each one into
> postscript (which CUPS uses internally).
>
> As you can see from that list, all common image formats like jpeg, png,
> tiff, and bmp are supported.  Text formats, like TXT and HTML are
> supported.  Document formats like pdf and postscript are supported.
> Source code formats like c, sh, csh, and perl, are supported.  Mine even
> has support for microsoft .doc!
>
> I think we should solve our printing problem by extending this list to a
> few more common formats.  Add in python source and the Open Document
> Format, and we're pretty much done.  There are very few Activities that
> generate documents that could be printed, but are not in one of these
> formats.  Those Activities will have to gain the ability to export to one
> of the supported formats, just as they would on any standard linux desktop.

That's all fine, if the user sends a file to the printer spool, it
gets converted to a printable format, then sent to print. That's how
printing in unix works and there's no need to change it.

> The only remaining question is: "who calls lpr?".  In my view, the
> Activity should not have to call lpr, or otherwise initiate printing.
> Sugar's philosophy is to make things "built in", as much as possible, so
> that Activity authors don't have to worry about these sorts of things.
> There's also a potential security problem if Activities can initiate
> printing without user interaction.  Printing directly from the Journal
> seems like the logical way to handle this.

The security concern makes sense to me, though I would like to hear
from Eben what his thoughts are regarding user experience. What I
think is important is that activities are given a chance to produce
themselves the printable document, as they are the ones that can
better do that.

> If you are concerned about doing all this conversion on the local machine,
> then we can move all the filters onto the server, and have the print
> system transfer the raw file.  Vamsi has argued against this idea,
> however, because he wants users to be able to convert things to PDF
> locally, without server access.

Well, I think we want both and we already have the needed
infrastructure to do that. People deploying Sugar will chose which
printing infrastructure can be installed in each machine and the
server and Sugar will do whatever it can so stuff gets printed. I
don't see a real need to choose one approach and not the other.

>> So anyway gtkprint makes use of a structure which is rendered to cairo
>> objects and thus prints the screen as a pdf or prints to a printer ( a
>> wrapper around cups) but the advantage is we dont utilisie that many filters
>> again
>> ( the implementation can be found in pyabiword )
>
> This is not very accurate.  IIUC, gtkprint is just a shim connecting Cairo
> to CUPS.  In this case, it's equivalent to drawing stuff in Cairo, and
> then exporting to PDF.  In other words, it's a toolbox for writing PDF
> conversion filters.  That means that the system still contains "a great
> load of filters", only now the Activity authors have to maintain them.
> That doesn't seem like an improvement to me.

Well, that's not very accurate ;) Gtkprint makes it a bit easier to
reuse the cairo code you use to draw to screen to also print to paper.
And we can expect that motivated activity authors will produce a
better output that a generic filter converting some standard doc
format.

Again, what is very important to me is that activities are given a
chance to produce the printable format, because they are probably the
best that know how to print their stuff and because of code
distribution: we cannot anticipate all the activities that will be
installed on a system, we cannot anticipate which filters will be
installed by the deployer/distributor and we already have a code
distribution mechanism (bundles).

To summarize, this is my proposal:

- (py)gtk activities use gtkprint to produce a printable format, using
an API that makes easy to use the same cairo drawing for the screen
and paper. This doesn't mean that you print what you see on the
screen, just that you are given the chance to reuse part of the cairo
drawing you already have.

- (py)gtk activities use gtkprint. This means that they have an
abstraction for printing to cups, lpr and to a file (ps or pdf). Other
activities written in other toolkits can use whatever facilities they
have to interface with the underlying printing system, or cook their
own. If we decide that activities shouldn't be able to directly print
for security reasons, then put this functionality in the journal and
when an activity "prints", then show a non-modal alert that can take
the user to that entry in the journal, for actual printing.

- implement a moodle module where users can upload whatever file they
have in the journal. Depending on the printing filters installed on
the server, there are more or less chances it can be converted to a
printable format. Moodle could be smart enough to check that and
accept or reject the uploaded file based on that. This module could
also contain features to administrate the printing queue.

Please note that this scheme doesn't mean activities cannot make use
of local filters to avoid having printing code. If abiword wouldn't be
able to produce a pdf/ps (it is) and the local system had a filter for
converting .odt files, abiword itself could quite easily call that
filter to provide pdf output.

And of course, the server could be provided with tons of filters, or
at least many more that we can expect to have in every individual
system.

Regards,

Tomeu