Mozilla should list the printer on system in printer dialog.

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 ***

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).

(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.)

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).

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.

> 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.

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.

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 ?