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

[Benjamin M. Schwartz]

-----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.

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.

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.

> 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.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkntyggACgkQUJT6e6HFtqQfhgCdFOQctGzYpZo7/4bHxu66+NT7
W44AnAmcKXA8SD6pvhoumD3URBe2XisJ
=x9qR
-----END PGP SIGNATURE-----