Hello, On Feb 23 15:14 Till Kamppeter wrote (shortened): > I think, the best is if the backend can spit out this data. Then there can > never happen that the database and the actually installed backends differ from > each other.
Yes, this would be best. > In SANE one has at least only one driver architecture, the SANE backends. ... and funny required daemons like PTAL/HPLIP and what else may occur in the future (in particular for proprietary backends). > The syntax of this output should be > > - Easily machine-readable, but also human-readable (like PPD, xml, ...) > - Extendable format > - Not based on too complicated standard (PPD specs have > 160 pages) Don't get confused by the length of the PPD spec. The spec of the plain PPD syntax is small. Most in Adobe's PPD spec is description about very printer specific stuff (which keywords should be used and so on ...). I am only talking about using the plain PPD syntax. I think if a new syntax was created, the semantic would be the same as in the PPD syntax because I think we need all what is possible with the PPD syntax: - options (main keywords), choices (option keywords), defaults - option groups and sub-groups - user-interface options <-> admin-only options - constraints - translation strings and additionally - choices for arbitrary user input which matches a regexp I.e. we could start with the PPD syntax and enhance it. Because PPD syntax allows adding arbitrary keywords, I think this is a sufficient extendable format. But we must agree upon standard main keywords and option keywords (just like in Adobe's PPD spec). > - Contain all needed info for each supported model (list of models > must be queriable, too): [...] > (Please add what I have forgotten). o The backend name must also be in a scanner PPD. Or should this be just one choice of a "driver" option? For printing there are almost no PPDs which include different drivers because of too many constraints. (Only drivers with same driver optins like "ljet4, lj4dith" are in one PPD.) > By the way, in Mandrakelinux I let scannerdrake use a database generated from > the *.desc files and one additional file manually created by me. This > additional file contains for each backend which lines have to be in the config > file, And you must verify each entry in this additional file for each new SANE version whether it is still valid :-( Otherwise it may happen you enter obsolete stuff. Examples: In the old Yast scanner setup we set the SCSI device in <backend>.conf but I detected that at least the hp backend perfectly autodetects SCSI scanners. Having a SCSI device like /dev/sg0 in <backend>.conf may cause problems because the generic SCSI device nodes are assigned in arbitrary order to the SCSI devices (all USB storage devices are SCSI devices and get a generic SCSI device node). If a backend does not do autodetection when the SCSI device is set in <backend>.conf, the scanner may work or not depending how many USB storage devices have been connected during scanner setup and are now connected when using the scanner. In epkowa.conf there is (or was) by default the line usb /dev/usb/scanner0 which causes that it doesn't work out of the box with libusb. Since I changed it in the Suse iscan package to usb it works out of the box with libusb because epkowa autodetects its USB scanners. As a result I do no longer like to change the defaults in <backend>.conf because I assume when a backend detects a model it knows best which settings it must use for this model. As I do not have all scanner models to verify such settings (in fact I only have a few models) I think it is safer to rely on the automatisms in the backend than setting possible wrong values in <backend>.conf. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: [email protected] 90409 Nuernberg, Germany WWW: http://www.suse.de/
