240379 - Enable mozilla to detect printer list on system

Status: RESOLVED DUPLICATE of bug 135695

(Core :: Printing: Output, defect)

Description

[Louie Zhao]

Mozilla should list the printer on system in printer dialog.

Comment 1

[Louie Zhao]

Attachment: patch v1

Comment 2

[Roland Mainz]

Louie:
This idea is hopeless and will never work that way you're trying. There are at
least six different spoolers which are all incompatible to each other and all
require different enumeration way and ways to call the spooler.
And to make it worse each spooler can be installed additionally to the spooler
provided by the OS, either to replace it or to work in parallel.
Long ago I've talked with Rods and Dcone about that and we agreed to avoid that
feature since it is very very difficult to get it right (just look at Xprt on
Linux, even after two years the spooler autodetection feature does only cover
"most" cases, not "all". Sometimes manual configuration is stilll required). And
partial implementations will cause more problems than benefits.

*** This bug has been marked as a duplicate of 135695 ***

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That doesn't mean we shouldn't fix it for the 90% case if we can do it in a way
that doesn't make the other 10% worse off (which this shouldn't if the error
handling is right).

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(Also, please note that Roland Mainz doesn't have the power to prevent you from
getting the patch in if you disagree with him, although it is generally better
to try to reach consensus.)

Comment 5

[Roland Mainz]

David Baron wrote:
> That doesn't mean we shouldn't fix it for the 90% case if we can do it in a 
> way that doesn't make the other 10% worse off (which this shouldn't if the 
> error handling is right).

There is no "standard" for printing on Unix or Linux so there is no proper way
to detect the correct spooler - locations of binaries, configuration and command
parameters differ between Linux and Unix distributions and are not even stable
between different releases of the same vendor (not even for Solaris). And if the
user or admin chooses to install a different spooler the confusion is complete.

And Louie's way won't work for Solaris since "lpstat" can wait _minutes_
(waiting for queue status etc.) when network printers are involved (the Xprint
server can deal with the issue since it is running as system deamon and running
async; the list of printers are cached at startup).

Comment 6

[Roland Mainz]

David Baron wrote:
> (Also, please note that Roland Mainz doesn't have the power to prevent you 
> from getting the patch in if you disagree with him, although it is generally 
> better to try to reach consensus.)

What do you mean with that ? _Years_ ago dcone, rods and I came to the
conclusion that such a feature cannot be implemented in a proper way within
Mozilla.
What has changed in the meantime ? Nothing. The same problems exist and there is
no proper solution.
SuSE tried it outside Mozilla with a script which fills the
MOZILLA_POSTSCRIPT_PRINTER_LIST env var and failed horribly with that. And that
was only ONE SINGLE Linux vendor - getting a "consens" for "90%" of the Linux
distributions is like fighting against the windmills. And then think about
Solaris, HP-UX, AIX, IRIX...
And even Xprint has huge problems to get it right on Linux since the output of
the spooler status programs (lpstat, lpc, lsallq, lsq, lsqueues, lspq, etc.)
changes every year so I have to adjust that each time - and test that change
against the new and all older versions. Is it wise to keep such a maintaince
nightmare within the Mozilla CVS ? I doubt it.

Comment 7

[Louie Zhao]

> And Louie's way won't work for Solaris since "lpstat" can wait _minutes_
> (waiting for queue status etc.) when network printers are involved (the Xprint
> server can deal with the issue since it is running as system deamon and running
> async; the list of printers are cached at startup).

Yes, we have also detected this problem on Solaris. In some cases, finding a
network printers will take quite a long time. So I use "thread" to run the
"lpstat". Therefore, mozilla won't be blocked due to the delay of "lpstat".
Actually, using "thread" will prevent mozilla from block even "lpstat" fails.
The worst situation is that mozilla doesn't get any printer from this feature.

> That doesn't mean we shouldn't fix it for the 90% case if we can do it in a 
> way that doesn't make the other 10% worse off (which this shouldn't if the 
> error handling is right).

Currently, we have tested this fix on SuSE Linux and Solaris 8/9 (under
different locales). This patch may cover less than 90% cases, but we can work on
it to cover more. But at lease, we won't make the other 10% worse off.

Comment 8

[Louie Zhao]

We use "pref" to store the printer-list. When "lpstat" costs long time (e.g.
_minutes_), maybe we won't get it the first time we open "print dialog" (in the
patch, mozilla reads printer-list when opening "print dialog"). But since the
thread is running async, we hopefully get printer-list when opening "print
dialog" the next time. 

BTW, this requirement is brought forward by many end-users and strongly needed
by them. From this point of view, mozilla should have this feature just like
other Unix Apps, e.g. OpenOffice. Although there is no perfect fix technically,
we can try our best to provide a solution to cover more cases.

Comment 9

[Roland Mainz]

Louie Zhao wrote:
> > And Louie's way won't work for Solaris since "lpstat" can wait _minutes_
> > (waiting for queue status etc.) when network printers are involved (the 
> > Xprint
> > server can deal with the issue since it is running as system deamon and 
> > running
> > async; the list of printers are cached at startup).
>
> Yes, we have also detected this problem on Solaris. In some cases, finding a
> network printers will take quite a long time. So I use "thread" to run the
> "lpstat". Therefore, mozilla won't be blocked due to the delay of "lpstat".
> Actually, using "thread" will prevent mozilla from block even "lpstat" fails.
> The worst situation is that mozilla doesn't get any printer from this feature.

Right now your current patch will not work in the real world:
1. You are assuming that "lpstat" is always used to enumerating printers. This
is true for CUPS and Solaris but not for *BSD, AIX, HP-UX and LPRng (which is
popular on Linux, too)
2. You are assuming that the printers you have obtained work with the default
spooler command - which is currently "lpr" in Mozilla.
But "lpr" is horribly wrong for Solaris and ONLY works when the SunOS
compatibilty packages have been installed on Solaris (which isn't the case for
the enduser install cluster). 
I asked Greg.Onufer@sun to file a bug for that - that's bug 179538 ("[ps] lpr is
not guaranteed to exist on SunOS 5.x systems, lp is guaranteed to exist and
should be used instead" - note that the bug wasn't touched since more than 18
months!!).
The same problems applies to CUPS (where the CUPS *BSD compatibility tools must
be installed before there is a working "lpr") and nearly all other spooler
systems on Unix.
3. You're assuming that the output of "lpstat" has a fixed, stable format. See
my previous comment about that. Older CUPS releases do not work with that patch
and future versions may break it, too. The same applies to LPRng. And don't
even  think of the platform-specific spooler solutions on AIX and HP-UX...
4. The spooler command parameters differ between spooler implementations and
versions, too.

So far the thing can only be solved like this:
Detect the spooler type being used via trial-and-error method (e.g. test each
spooler type/version combination and pick that one which returns valid spooler
names which are associated to _active_ and _enabled_ queues (!!)) and remember
the spooler type/version being used  for that specific printer name and select
the matching spooler command for spooling on a per-printername basis (this is
basically the way how Xprt deals with this nightmare on Linux).

Even with that method you'll cover less than... say... 75% of the cases - for
now. In a year your code is rotten and needs to be updated. And when the spooler
status command changes it's output you have to update the code - again.
If you are still willing to do this please move the printer name enumeration
(e.g. "dist/bin/moz_ps_enum_printers.sh") and spooler invokation (e.g.
"dist/bin/moz_ps_spooljob.sh") into _shell_ scripts that users can edit them on
demand... sticking the hardcoded values into binaries is a bad idea.

And the patch misses a way to avoid that manual user settings are overwritten -
and a switch is needed to turn it off on demand.

> > That doesn't mean we shouldn't fix it for the 90% case if we can do it in a 
> > way that doesn't make the other 10% worse off (which this shouldn't if the 
> > error handling is right).
>
> Currently, we have tested this fix on SuSE Linux

Which version ?
SuSE 8.2 gives me:
-- snip --
% LANG=C lpstat -v | sed 's/:/ /g' | awk '{ print $3 }' | sed 's/_default//g' | 
paste -s -d' ' -
parallel parallel parallel parallel parallel
-- snip --
... that doesn't sound good...  ;-(

> and Solaris 8/9 (under different locales).

Blastwave has CUPS packages - what will happen if someone has installed that ?