[hfdb] Foomatic printer db

[Zenaan Harkness]

Well, I read the first quarter or so of your paper Till, and browsed the
rest. Gotta get back to work today, but some thoughts do come
immediately to mind:

 - that's one big database you've got there! (makes sense - so man
printers). It's great to see, and seems to be in much better shape than
I had imagined (as a printer-naive debian user).

 - it seems it's currently all in XML, which is great for
automatability, either in transforms (to further normalize the current
design, and/ or to import and export into an SQL db

 - some ppd files are free, some are not, some are generated
 - perhaps all Free ppd files are now auto generated by foomatic ??

 - there is clearly some normalization work to done that could be
useful; independant of storage format (as I raised with James)

 - I think that further normalization ought to be the first step here,
before things like a web interface and additional db features go in,
which would simply make the design job harder. For example, this quote
from the paper seems to perfectly apply here:
---
Printer/Driver classes

One problem of the Foomatic database is, that one has often to repeat
the same comments in many printer entries or that one has to add
constraints for many individual printers into the option entries or into
the printer lists of driver entries. This makes maintaining the database
a lot of work.

To solve this problem we came to the idea of introducing printer
classes. A class should contain printers with a common capability, as
for example PCL-5e printers, wide format printers, printers compatible
to the HP DeskJet 990C, ... So one can simply put the PCL-5e printer
class as the only printer entry into the printer list of the "ljet4"
driver and simply add any new PCL-5e printer to the PCL-5e class. Then
the printer gets automatically associated with the "ljet4" driver. In a
"PageSize" option one could make all paper sizes bigger than Legal only
available to the wide format class. There could also be a class of all
multi-function devices needing HPOJ to be able to scan, this class would
add an appropriate text paragraph to the printer's web page on
linuxprinting.org. And when this text piece needs to be updated, one
updates it in the class entry and it automatically changes on hundreds
of printer pages.


This makes it also easier for users to add a printer via a web
interface, They simply need to pick classes to which the printer belongs
and so most information and driver/option associations are done, the
user only needs to add little info by filling in the web form, the
maintainers of linuxprinting.org need only to do some fine tuning.

Similarly one could also make classes for drivers.
---

>From my reading of it, Printer Classes as a concept is essentially a
normalization step. I think that we should look to clearly undestanding
the current schema/ design, that there is further very useful such
normalization/ transformations we can apply to the foomatic database.
This will make our work easier going forward.

Similar here:
---
Option conflicts

An important structural element of PPD files which is not supported yet
by Foomatic are option conflicts. Option conflicts are definitions in
the PPD files which prevent the user from making choices which make
printing impossible or simply do not make sense, as for example duplex
on transparencies or A3 paper in the envelope feeder. This avoids that
users send print jobs with bad settings and then complain about
something wrong or nothing coming out of the printer. This is especially
important because most spoolers cannot report back error messages of the
driver to the user who has sent the job. So users do not know why
nothing comes out of the printer. Or they waste expensive material when
nice double-sided transparencies come out.
---

Have to smile at those double-sided transparencies :)

This type of data/ declaratory information is well suited to the
relational model. And the relational model can be readily represented in
XML files (and of course SQL RDBMS).

cheers
zen