Re: [hfdb] Sorry - fixed now Re: [Fwd: Summary of the LSM Free Software Printing Summit]

[David Zeuthen]

Hi, 

> On Fri, 2004-07-16 at 06:19, Roger Leigh wrote: 
> ...
> > Proposed PPD extensions
> > - -----------------------
> > 
> > Patrick Powell then started an unplanned (but very interesting)
> > discussion about the shortcomings of current PPD files and user
> > interfaces.  Currently, PPDs may only contain a single language, which
> > makes internationalisation difficult (translated PPDs are not
> > typically distributed with Debian due to the sheer size).
> 
> If this is implemented, this will make printer PPD "driver"
> integration pretty straightforward - we simply automate the
> extraction of the relevant information from the PPD file, eg:
>  - which 'low level' drivers supported (and which kernels)
>  - which translations are included
>  - printer features
> 
> I imagine the truly canonical location for all this information
> to stay as inside the PDD file. And, for a nice searchable DB
> (hfdb) to be a really useful thing for people looking to purchase
> a printer and/ or looking for driver/ os options. The hfdb will be
> able to cross reference the PPD printer info with low-level driver
> info, to provide something quite useful.
> 
> HAL wll be able to make use of "maximal feature support" metric
> to auto-choose 'best' low level driver for the printer the user
> just plugged in, as well as take advantage of auto-generated hal
> xml printer descriptor files (these can come straight from PPD,
> or if it is useful to include cross reference info with other
> drivers, hardware interfaces (eg. usb, firewire), then from
> hfdb (which is what I'll personally be focusing on)).
> 
> So the way I'm imagining the data transformation flow at this point
> is:
> 
>   PPD -> hfdb -> xml -> hal
> 
> Now printer data submissions may well come from multiple points:
>  - obviously at the moment, still from linuxprinting.org
>  - hfdb, once we start accepting submissions
>  - hal - perhaps some automated "new data submission" thing (?)
>  - wherever
> 
> Our intention is to at a minimum have hfdb become a single distro-,
> device- and kernel- email submission point, and ideally unify the
> disparate hardware info databases community-wide.
> 
> Given that PPD files are text, we can simply diff any changes between
> versions, in order to add updates to hfdb. Or remunge them into hfdb or
> whatever works. It's possible there might be reasons to maintain the
> canonical data in hfdb's DB (SQL db at the moment, perhaps XML later),
> and generate the PPD files from that - but I don't think this is a
> necessity.
> 

I'm not sure how much hal needs to be involved here - remember, one of
the primary goals of hal is merge (arbitrary) data with bus/class
specific data, not replace existing software.

However, we do represent (USB) printers in hal and we probe the printer
for both USB vendorId and USB productID as well as the IEEE 1284 ID
string (well, as several properties, for now assume it's one string) as
well as what character device node user space needs to access to use the
device.

So, perhaps one use is that the HFDB generates hal device information
files like this

        <deviceinfo version="0.2">
          <device>
            <match key="info.bus" string="usb">
              <match key="usb.vendor_id" int="0x03f0">
                <match key="usb.product_id" int="0x0104">
                  <match key="printer.ieee1284" string="something">
                    <merge key="printer.ppd" 
type="string">name_of_ppd_file</merge>
                </match>
              </match>
            </match>
          </device>
        </deviceinfo>
        
for each printer, and when this particular printer is plugged in we
merge the information.

So the thinking is that desktop apps just ask hal for printers on the
system and then they get both the information we've probed for (usb,
ieee1284 and device node) as well as the stuff we've merged (the name of
the ppd file).

Now, I don't know a lot about printing, Joe Shaw might be better to
comment on this, but am I on the right track? Or is this already solved
in existing or planned software?

Thanks,
David