[sane-devel] Infrared channel

[Johannes Meixner]

Hello,

On Feb 23 10:34 Olaf Meeuwissen wrote (shortened):
> What you are suggesting here sounds quite a bit to the way foomatic
> handles printers.
> 
>   - an XML database
>   - a few utilities to crank out PPD files
>   - one utility to glue the PPDs, the spooler and the printer drivers
>     together

Note that the Foomatic XML is not 100% compliant to XML spec
see "entity reference problem in XML data" on LinuxPrinting.org:
http://www.linuxprinting.org/pipermail/foomatic-devel/2004q1/001838.html
and the "DTDs: first try" thread on LinuxPrinting.org, for example:
http://www.linuxprinting.org/pipermail/foomatic-devel/2004q1/001830.html

I.e. if you like to use XML be very careful to produce correct XML.
Note that XML can be valid (i.e. xmllint doesn't complain) but
nevertheless it is not what you expect (see above), see for example:
http://www.linuxprinting.org/pipermail/foomatic-devel/2004q1/001851.html
(there is a wrong mail reference, it should be .../2004q1/001838.html)
I think the best way to make sure the XML is correct is not to use
selfmade XML parsers but only established tools like xmllint
and xsltproc.

Some notes regarding possible problems:

Do not depend on XML or any other intermediate format.
Do not force the authors of scanner software to provide XML.
Only specify the syntax of the final scanner description data.
This way third party software (e.g. HP's HPLIP or Epson Kowa's Iscan)
can be made as the authors of this software like to do it.

For printers only the PPD format is mandatory.
It doesn't matter how the PPDs are created.
Examples:
- PPDs for PostScript printers are created by internal tools
  of the printer manufacturers
- PPDs for HP's HPIJS driver are created somehow by HP
  (I don't care how HP makes them - I only use the PPDs)
- PPDs for the GimpPrint/Gutenprint driver are created
  via Foomatic-stlye XML


> I guess, we could do without the PPD files for scanners

I would prefer this too.


> > Obviously it is best not to maintain any kind of text files
> > but to run the backend in a special mode and the backend spits out
> > what it knows in a well defined format.
> 
> It be nice if the backend could spit out a baseline because quite a
> few backends seem to at least partially support new models without any
> modification.  As a matter of fact, I have been playing with the
> thought to externalise a lot of data that is now hard-coded in the
> epkowa backend into data files.  This would make it possible to add
> support for at least some scanners without a recompile of the backend.
> # If the original data is in XML format, it would also ease keeping my
> # (internal) specs in sync with reality ;-)

Regardless whether we use *.desc files, PPD files, XML files,
or the backend spits out the data:
We must agree on one data format for scanner description.
This data format should be extensible.
I like the general idea of the PPD syntax.
I assume manufacturers may like the PPD syntax too because
manufacturers know how to create PPD files for printers
and if they can use their existing tools also for scanners,
I assume they would be happy.

I would prefer when the backend would spit out the data
in the scanner-description-format because this way each author
of a backend can use the interal data representation he likes most.

If a backend author likes to have the data in scanner-description-format
in an external file, then all the backend has to do is output the file.

If a backend author likes hardcoded internal data the backend would
have to convert it into scanner-description-format and output this.

If the internal backend data cannot be made public available
(e.g. a proprietary binary-only backend - Olaf can you imagine
which backend I have in mind ;-) the backend could nevertheless
output at least minimal scanner-description-format data like
model name, autodetection model string/ID, and support status.


Kind Regards,
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5      Mail: jsmeix@suse.de
90409 Nuernberg, Germany                    WWW: http://www.suse.de/