Because of incomplete deployment, SANE would have to be a trial-use module for LSB Post-4.0. There are reasons its priority should be higher than that, though. Printer vendors want to ship unified drivers for all-in-one devices, which would include SANE backends. If we don't allow them to otherwise, calls to the SANE ABI would disqualify the driver from LSB certification.
Thus, part of the LSB Post-4.0 work for SANE will include a method for allowing SANE backends to ship in printer driver kits. Resolving this should be high priority, even if the SANE interfaces themselves aren't.
The latest package versions available from the SANE project are:
sane-backends 1.0.20 sane-frontends 1.0.14
The LSB reference platforms ship the following versions of the sane-backends package.
SANE frontends link dynamically with libsane. In principle, any SANE backend can be used as libsane but in practice distributions use the dll backend. This way, applications can get access to all installed SANE backends.
More information on the various ways in which SANE frontends can use SANE backends can be found here.
There are 14 public API interfaces.
sane_cancel sane_close sane_control_option sane_exit sane_get_devices * sane_get_option_descriptor sane_get_parameters sane_get_select_fd ** sane_init sane_open sane_read sane_set_io_mode ** sane_start sane_strstatus **
Feedback on lsb-discuss indicates that not all interfaces are required. Interfaces marked with * are recommended for inclusion and those with ** optional. Note, however, that omitting any of the interfaces from the standard would break the normal deployment scenario where the dll backend provides libsane.
The same feedback also mentioned that types used in function signatures as well as enumerations referenced should be included in the standard. Enumeration values should be limited to those defined in version 1.04 of the SANE standard specification.
To accommodate the dll backend's implementation SANE backends normally also provide a second set of API interfaces. This set parallels the documented interfaces and is constructed mechanically.
For a backend by the name of BE this second set of API interfaces is as follows.
sane_BE_cancel sane_BE_close sane_BE_control_option sane_BE_exit sane_BE_get_devices sane_BE_get_option_descriptor sane_BE_get_parameters sane_BE_get_select_fd sane_BE_init sane_BE_open sane_BE_read sane_BE_set_io_mode sane_BE_start sane_BE_strstatus
Backend names need to chosen so that the above API interfaces are valid C identifiers.
To avoid reinventing the wheel, some internal interfaces are provided as well but backend implementations are free to ignore those. Backends that do use them should link them statically and refrain from exporting these interfaces.
The internal interfaces all start with a sanei_ prefix.