No Subject

1) Import all of the features from the PPD into the new XML profile and
use only this file. For non-PS printers, these profiles will have to be
made entirely from scratch.

2) Limit the scope of the XML profile to 1. For PS printers, 2 & 3 will
be handled by PPDs. For non-PS printers, PPD-like files will need to be
created.

Each of these solutions is workable. I would tend to go with 2 for a
couple of reasons. On the one hand, the libppd library is already
available for interacting with PPD files. With only slight
modifications, this library could also be used to handle the PPD-like
files created for the non-PS printers (assuming that the basic PPD
structure is adhered to).

The other major reason I think 2 would be preferrable is marketability
to vendors. A PS printing solution that requires little more than a PPD
file is quite flexible. In fact, this is how all PS printing is done
from the Mac environment - no one develops a complete PS driver, they
just add a PPD to the existing Mac PS driver. Since vendors must develop
PPD files for their printers anyway, it would probably break down any
perceived barrier to "official" linux/gnome printing support. If, on the
other hand, vendors must worry about a different file format, they may
be more reluctant to devote resources to it. Since PPD is a known
standard that is viable for many different platforms, I think PPD
support in gnome-print would signal to printer vendors that the
gnome-print environment is every bit as capable (if not more so) and
mature as the printing solutions available on other proprietary desktop
OSes.

-- 

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