IMHO this bug should be fixed at the highest priority.  There was quite a big
user backlash on Debian's mailinglists, for example, when xprint was made the
only output driver for mozilla.  Basically, people are now providing private
builds without Xprint at all, because they prefer a less featurefull printing
backend (the old mozilla postscript driver) than to configure Xprint.

That shows, IMHO, that currently Xprint is perceived by way too many people as
basically totally useless/broken/unconfigurable (it is not broken nor useless,
but since it won't work at all in many setups without proper configuration, AND
proper configuration is not currently within the capabilities of a regular user...)

There is little documentation on how to write Xprint-lingo printer definitions,
and not using PPDs to configure the printers is close to being non-configurable
for an end user, anyway (because they can get the PPDs easily in CUPS or from
the vendors, or from www.linuxprinting.org, which is actually not linux
specific), but "nobody" has Xprint configurations.  "Nobody" ships them.  And
not many people know, or care to, create them.

It would be even better if we could tell Xprint to actually use PPDs directly
without adding an extra cubbersome layer.  Activated when generating PS output,
of course.  IMHO this should be the goal in the long run.  PPDs _are_ the right
tool for the job of configuring PostScript printers.  Which is the case for most
printers that work perfectly on Unixes nowadays (maybe through ghostscript
output drivers, but still...).

Please consider this to be a request to get this to P1 priority, on behalf of
the Debian users.

I've provided suggsetions for implementation in the old Xprint bugzilla here:

http://mozdev.org/bugs/show_bug.cgi?id=5355 (RFE: locate and parse PPD files on
the fly in addition to model-configs)

http://mozdev.org/bugs/show_bug.cgi?id=5517 (Detect printer
models/capabilities/default settings automatically on CUPS)

The bugs mentioned earlier have evolved, so that you don't have to read through
all of them here's the summary so far: 


Since PPD (Postscript Printer Definition) files/documents contain roughly the same
information that model configs, and they are the standard used on UNIX-like
systems, Xprint should be able to locate and use them directly.

Sample PPD files can be obtained here: http://www.linuxprinting.org/download/PPD/

The PPD files usually reside on the CUPS server, in /etc/cups/ppd directory.
However, they are of course unavailable directly from the client machines
filesystems.

But the CUPS API gives the possibility to get a PPD file for a
printer _from the CUPS server_ regardless of its location, using the
cupsGetPPD() function:

http://www.cups.org/spm.html#3_3_2 :

"#include <cups/cups.h>
...
const char *filename;
filename = cupsGetPPD("name");

The name string is the name of the printer or class, including the remote server
name as appropriate (e.g. "printer@server".)

The return value is a pointer to a filename in static storage; this value is
overwritten with each call to cupsGetPPD(). If the printer or class does not
exist, a NULL pointer will be returned."

And to get the available queues (printers, classes and instances) one uses the
cupsGetDests() function: http://www.cups.org/doc-1.1/spm.html#3_2_5

Using the CUPS command-line tools one can also extract useful information about
printers (supported/default resolutions, paper sizes, printing modes, duplex
support, media sources etc.):

lpoptions -p printer_name -l

Roland: what do you think about the idea of having Xprint handle various sources
of model-config info in parallel? 

I've posted it here on the xprint mailing list  in 2004-10: 
http://xprint.mozdev.org/pipermail/xprint/2004-October/000350.html

In short:

Xprint would be refactored so that various sources of printer model information
are supported and coexist on one Xprint installation, with various priorities
when it comes to overriding other ones' settings.

E.g. a default installation of Xprint would use standard model configs, and if
CUPS is detected, Xprint would read the PPD from the CUPS system using CUPS API,
and any CUPS PPD settings would override settings provided by model-configs.

Another sources of model info should be possible to implement as plug-ins, e.g.
in future, one would possibly like to get model information from an LDAP directory.

Users of older (non-CUPS) spoolers like LPD could just use model-configs or a
plugin for Xprint that would get PPD files directly from the filesystem, from a
configured directory (or both at the same time).

I think any use of the CUPS API should bear the PAPI (OpenPrinting API) in mind,
which is designed to improve upon CUPS and IPP, accessing, for instance, lpd
printers. The use of PAPI in Xprint has been suggested in Xprint bug #411.
Although at the present time PAPI is under development, not yet finished.

Yes, PAPI could be used in the future as an additional model-config plugin, when
its implementation from http://sourceforge.net/projects/openprinting/ becomes
finally stable.

For now, CUPS seems the best option as it has been stable for a couple of years.

Anyway, various sources of printer model-config information will come ang go,
and if we want Xprint to survive, it needs a plugin architecture for them.

Currently I can think at least 4 such sources:
   * classic Xprint model-config files
   * PPDs from CUPS API
   * PPDs from local filesystem
   * LDAP directory (using the standard schema from RFC3712:
http://www.faqs.org/rfcs/rfc3712.html)

PAPI would be the 5th one...

I've been trying both the PAPI and the CUPS APIs. PAPI works giving me a list of
printers and their attributes, but not the default printer and not the resolutions.

CUPS also gives me a list of printers and identifies the default.  Like PAPI, it
does not return printer resolutions (in fact I suspect PAPI doesn't return them
because CUPS is not giving them to it). However, I can get printer resolutions
using the CUPS PPD API (rather than IPP attributes), i.e. via ppdFindOption
rather than ippFindAttribute.

This means any working implementation would not be one-to-one equivalent to
PAPI. By this I mean PAPI has an equivalent command to CUPS' ippFindAttribute,
but not to ppdFindOption.

So at the moment libcups can provide the dynamic information we want (for CUPS
systems at least).  Is there any reason why it would be wrong to find a place
for this inside the Xprint code rather than in some external utility? It would
mean incorporating new library dependencies (on libcups). Is the X Consortium
happy doing that kind of thing?

Drew, I have 2 questions about PAPI:
   * which distributions ship with it in default installation (almost all ship
with CUPS)?
   * how stable is PAPI (is it unlikely to change in the future, just as CUPS API)?

Your two questions are in the reverse order :)

* how stable is PAPI (is it unlikely to change in the future, just as CUPS API)?

It's probably fair to say it's quite unstable at the moment. The API is at
v0.92, and the implementation is quite buggy.  Norm Jacobs from Sun is currently
working on it but I wouldn't expect it to be stable before the end of the year.

 * which distributions ship with it in default installation (almost all ship
with CUPS)?

Because of its current unstableness, I would imagine (without actually checking)
none ship it yet. Certainly Debian does not have it yet (maybe I should add it).
But the more people's attention we bring to it, the sooner it will start being
recognised and used.

So using PAPI in Xprint isn't a good idea at least for a year or two from now.

On the other hand, CUPS is stable, well tested, popular, omnipresent, well
known, and it can be used to address the issue with model configs - and this
issue is currently the most significant one with Xprint, that prevents its wide
adoption _now_, at the time I write this.

So IMHO Xprint's integration with CUPS PPD's is the best option presently; and
it's very urgent, too. People and Linux distributors just don't use Xprint -
mostlly because of lack of this feature.

They try to print from Mozilla to their 300DPI printer - the printout gets
messed up (too big to fit on paper); 

About 95% of them just gives up and forgets about Mozilla printing - they switch
to MS Windows of print from Konqueror, which simply doesn't use Xprint.

About 5% of them manages to find out about the Xprint model configs. About half
of them gives up, the remaining 2,5% messes with Xprint configuration (default
resolution and such). then they try to print with a 600DPI/1200DPI printer and
the printout comes out to small. Most of them just runs away from Xprint,
screaming loudly in horror. The remaining few, like me, try to cautiously write
a model config for each printer they use, then configure Xprint by the book. But
that's the (roughly) 10 people in the world like you and me :/

In short: if Xprint doesn't get the printer model information _automatically_,
_dynamically_ from CUPS using PPDs, almost noone will really use it.

People will just giv up on printing from Mozilla, or distributors will make
their custom builds of Mozilla that circumvent Xprint and do printing without it.

Fedora Core is an example of this:

http://www.redhat.com/archives/fedora-devel-list/2004-September/msg01132.html :

"From: Owen Taylor <otaylor redhat com>

<...>

To summarize briefly:

 - xprint doesn't use the font system that we use everywhere else
   (fontconfig)
 - xprint can't use the layout system we use everywhere else (Pango)
 - xprint doesn't integrate well with the printing system that we
   use everywhere else (CUPS)
 - xprint can't use the desktop-wide printing dialog (libgnomeprintui)

The first and last are important ones for why enabling Xprint support
in the build is a bad idea; we can't provide as good a font or
printer selection user interface if the printing backend might be 
incompatible with our standard technologies rather than closely
integrated with our standard technologies."

Fedora is the only distribution that I use and that ships with a custom version
of Mozilla that replaces Xprint with something else. And it is the only
distribution where I print from Mozilla - I've tried setting up Xprint correctly
on others, I've even succeded, but after some upgrades and changes in
model-config stuff (location of files, structure? I don't even remember), I've
given up. I've thout to myself - hey this information is in the CUPS, why do I
have to feed it manually to Xprint?

So after almost a year of struggling with Xprint I've given up and wait for this
CUPS integration. I think the majority of users did the same, only that they
don't speak about that here in the Freedesktop Bugzilla.

BTW, here's the information about patch for Mozilla (used by Fedora) that gets
rid of Xprint and uses their own Postscript printing:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133787

For me, it solved all Mozilla printing problems. It's only sad that the solution
was accomplished by throwing Xprint away :(

I've noticed that latest versions of Mandrake Linux (actually Mandriva Linux
after their merger with Conectiva) also ship with modified Mozilla builds, like
Fedora. 

Those builds don't use Xprint for printing and get printers dynamically from CUPS.

I suspect that there _must_ be a downside to this (lack of support for
additional printer options? no optimized font outlines upload? no support for
PCL, only for PostScript?), but for me that change eliminated most problems with
printing from Mozilla. I can print pages with Latin, Cyrillic and other scripts
without problems, and no printout comes out too small/too large.

I don't have to manually configure any of 14 printers available from central
CUPS server in our office.

I wish this level of ease of use was accomplished by Xprint sometime...

FYI: PAPI support for PPD data is tracked at
http://sourceforge.net/tracker/index.php?func=detail&aid=1185348&group_id=59551&atid=506109

Looks like the bug has stagnated...

> Looks like the bug has stagnated...
As far as PAPI goes, it's still under development. Some work was done on it not
too long ago, but the new PAPI didn't work on my system, so I'm waiting for that.

Closing WONTFIX because nobody cares about Xprint. Reopen if you plan to address this bug.