Comment 13 for bug 39847

The data for autop-generating PPDs is installed by the foomatic-db and foomatic-db-hpijs binary packages. This XML data is much smaller than the PPDs it generates. The and packages are PPDs supplied by printer manufacturers. Most of them are for PostScript printers and they are exactly the same PPD files as they are used for Windows and Mac. They contain a lot of options and PostScript code to get the maximum out of the printers, the printers work with them exactly as under Windows or Mac OS.

Ricoh makes even dedicated PPDs for Linux, so that more advanced features get accessible to the Linux users, and they always keep their set of PPDs complete and up-to-date.

At Red Hat they thought already about converting PPDs into Foomatic data, but this did not work out as the Foomatic XML data format does not have equivalents for all types of items you can find in PPDs.

CUPS unfortunately does only support individually compressing each PPD witth gzip, not very efficient. Therefore PPDs appear in distributions in this form currently.

One idea would be to make use of CUPS's PPD auto-generation feature to make PPD packages and disk occupation by PPDs smaller:

1. Uncompress all PPDs (*.ppd.gz -> *.ppd)

2. Create an index file of the PPDs with output similar to the output of /usr/lib/cups/driver/foomatic list

3. Pack them all into a bzip2-compressed tarball, index file first

tar -cvjf ppds.tar.bz2 index.txt /usr/share/ppd/

4. Put a simple script into /usr/lib/cups/driver/ which does

a. when called with "list": extracts the index from the tarball and drops it to STDOUT

b. when called with "cat <scriptname>:<ppdname>": extract the PPD <ppdname> and drop it on STDOUT

This way all PPDs get transparently available as on a physical file system, but occupy much less space on the live CD, the hard disk, or in a .deb package.

I could implement this as a build option in foomatic-db and then we could provide the PPDs in this mode.

This naturally only works out if

- tarball packaging makes the PPDs really substantially smaller

- Use of a compressed file system on live CDs does not make the changes in the compression useless.

WDYT? Should I file a spec or a wishlist bug on that?