[cups.bugs] [MOD] STR #3772: Do not abolish the /usr/lib/cups/driver/XXX driver program (PPD generator) concept in 1.5.x

[Till Kamppeter]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

In the patch attached to STR #3720 and also in a recent discussion in the
cups.development newsgroup

http://cups.org/newsgroups.php?s3995+gcups.development+v4017+T0

I have seen that you want to deprecate the concept of PPD files being
generated on-the-fly by programs placed in the /usr/lib/cups/driver/
directory due to performance reasons.

Getting back to having each PPD file explicitly present and at most
gzipped individually will cause a huge waste of disk space, especially for
the drivers like Gutenprint.

Recently, I have even introduced a new PPD generator which reduces the
space occupation of the ready-made PPD files for PostScript printers by a
factor of between 10 and 20 compared to individually gzipped PPDs. It
makes use of the fact that PPD files for similar printers are similar.
What exactly is done is that the PPDs are packed into an xz-compressed
tarball and preceeded by an index (the output of the "list" option). This
makes listing the PPDs happen in nearly no time and extracting the
selected PPD is done in around a second. The program is pyppd, a
GSoC-2010 project mentored by me. See http://pypi.python.org/pypi/pyppd.

The biggest performance problem came from Foomatic, but for this I have
already a solution: Instead of generating PPDs on-the-fly from XML files I
pre-build all PPDs and compress them with pyppd. This method I have
successfully applied in Ubuntu and will apply it in the upstream Makefile
soon.

To avoid a regression in disk space occupation by PPD files i suggest to
keep the driver program concept, but tell in the documentation that the
quick execution of the "list" call is very important, or replace the
concept by the principles of pyppd, implemented in C to avoid extra
dependencies. The tarballs do not even need an executable header like the
ones of pyppd, as the logic for reading the index and uncompressing the
PPD files could be implemented in the cups-driverd.

I know that there is also the possibility to convert PPDs into .drv files,
but will every arbitrary PPD convert into a .drv file and back into the
original PPD? Note that I am compressing also manufacturer-supplied PPD
files with pyppd to save space in distribution installations and the PPDs
are absolutely identical to the original after extracting.

Link: http://www.cups.org/str.php?L3772
Version:  -feature