“Why the funny name?”, you ask. It started off around spring 2000. CUPS was far less known than today. It shipped with a few generic “drivers” (good for a few hundred different printer models). These didn't support many device-specific options. CUPS also shipped with its own builtin rasterization filter (“pstoraster”, derived from Ghostscript). On the other hand, CUPS had this brilliant support for *controlling* all printer options thru standarized and well-defined “PPD files” (PostScript Printers Description files). Plus, CUPS was designed to be easily extensible.

Grant had in his database already a respectable compilation of facts about a lot more printers, and the Ghostscript “drivers” they run with. His idea, to generate PPDs from the database info and use them to make standard Ghostscript filters work within CUPS, proofed to work very well. It also “killed several birds with one stone”:

• it made all current and future Ghostscript filter developments available for CUPS;
• it made available a lot of additional printer models to CUPS users (because often the “traditional” Ghostscript way of printing was the only one available);
• it gave all the advanced CUPS options (web interface, GUI driver configurations) to users wanting to use Ghostscript filters.

It worked through a quickly-hacked up filter script named “cupsomatic”. cupsomatic is running the printfile through Ghostscript, constructing automatically the rather complicated command line needed. It just required to be copied into the CUPS system to make it work. To “configure” the way cupsomatic controls the Ghostscript run, it needs a CUPS-PPD. This PPD was generated directly from the contents of the database for CUPS and the respective printer/filter combo thru another Perlscript named “CUPS-O-Matic”.

After that was working, Grant implemented within a few days a similar thing for two other spoolers. Names choosen were pdqomatic and lpdomatic; the configuration here didn't use PPDs but other spooler-specific files. Towards the end of the year, Till started to put work into the database. He added a huge amount of new info and new printers. He also added support for other spoolers, like PPR (via ppromatic), GNUlpr and LPRng (both via an extended lpdomatic) and “spoolerless” printing (directomatic)….

Soooo, to answer your question: “Foomatic” is the generalization of all the “*omatic” thingies…. – Foomatic up to versions 2.0.x required Perl data structures in the openprinting.org PPDs. It had a different “*omatic” script for every spooler,

This all has changed in 3.0: there is now the Grand Unification of all *omatic scripts, the “foomatic-rip”, which all the different spoolers may use. Because foomatic-rip can read PPDs, both original PostScript printer PPDs and openprinting.org-generated ones, all of a sudden, all users of every single supported spooler will be able to access the power of PPDs, once they plug “foomatic-rip” into their system…. Also, the New Generation of openprinting.org PPDs doesn't contain Perl data structures any more, If you have used the previous version of Foomatic, and want to give the new one a spin – don't forget to generate a new-version PPD, via the new “foomatic-db-engine”!