[Gnome-print] PPDs Re-visited



Hi All,

A couple of months ago I started a discussion on this list about the
possibility of integrating the functionality of libppd/GPr with
gnome-print to access the device dependent features of various printers.
The discussions revealed the fact that PPDs were a good way to list all
of the device capabilities of PostScript devices and could, most likely,
be modified to work with non-PostScript devices as well. However, one
point was made that certain information needed by gnome-print (unique
ID, printer class, etc.) was not available in the PPD file. Therefore,
using some combination of a previously conceived XML file format and a
PPD was considered.

Out of nowhere, I came to the realization that this may not be
necessary! One of the nice things about the PPD format is that it is
pretty extensible. You can add new "keywords" until your heart is
content. Therefore, it would probably be a small matter to add the
necessary information needed by gnome-print to the PPD file. For
instance the following information could be added:

*GnomePrintGUID: "947adab1-9fc1-4823-95a5-04a79146fa50"
*GnomePrintVendor: "Hewlett Packard"
*GnomePrintModel: "LaserJet 10e6"
*GnomePrintClass: "PostScript"

This information could easily be extracted by gnome-print through the
libppd library (with little or no modifications to libppd) and used as
needed.

Does this seem like a good possibility to anyone?

Before this discussion proceeds any further, I would like to know if
anyone has implemented or at least conceptualized a different method of
solving the same problem. I have been following the discussions on this
list closely and I haven't seen any activity in this particular area,
but that doesn't mean someone hasn't already addressed this.

For my part, I was supposed to hack together a version of gnome-print
that used GPr and libppd to try to prove to everyone how great it would
be. Needless to say, this is still on my to-do list. But, before I go
any further, I wanted to know if this problem had already been solved or
was near to being solved.

-- 

Thomas Hubbell
CompuMetric Labs, Inc.
thubbell@compumetric.com




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]