Closed Bug 218096 Opened 21 years ago Closed 15 years ago

Cannot print to anything but PostScript/default

Categories

(Core Graveyard :: Printing: Xprint, defect)

x86
Linux
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: davidpjames, Assigned: masaki.katakai)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

Printing to any of the @:64 printers does not work, including
spooldir_tmp_Xprintjobs@:64.

Reproducible: Always

Steps to Reproduce:
1. Ctrl+P from any page when running Mozilla (or MozFB) in Linux
2. Select any of the printers ending in @:64
3. Click Properties and change to na letter if necessary
4. Attempt to print

Actual Results:  
Nothing. At all.

Expected Results:  
Should have printed, given me an error message - something, anything but nothing.

I've also checked this with Firebird (20030901). I'm curious as to what this
@:64 suffix is all about - is the :64 supposed to be a port? If so shouldn't it
be :631, since that's where CUPS is? I'm sure that this @:64 didn't used to be
there. Moreover, I cannot edit the command it uses for these @:64 printers.
Fortunately PostScript/default still works and I can tell Moz to go print via
kprinter, where I can select the printer of my choice. Too bad I can't bump it
to the top of the list however.

Though I should perhaps file a separate RFE on this, there should be a way to
configure the print manager to call up an external print manager such as
kprinter, qtcups, xpp, whatever it is RedHat ships with, etc. so that we never
have to see the Mozilla print manager again (and so that we don't have *2* print
manager dialogues to deal with). A Moz print manager doesn't appear in Windows -
just the normal Windows print manager. It can't be too difficult to pipe output
directly to a user-selected print manager if they so choose.
A little more info:

After pressing "Print", a small progress-type dialogue is thrown up telling me
that Mozilla/FB is preparing to print. Following that, there is nothing.

The system is Debian Sid and I have verified that XPrint is installed and
running since it is listed as a recommends when installing Mozilla through
apt-get. '/etc/init.d/xprint Start' reports the service as running. I have never
used XPrint though so I can't say for sure that it is functionning as it ought
to be. For reference, the most recent Debian release of XPrint is found at:
http://packages.debian.org/unstable/x11/xprt-xprintorg.html

The version of Mozilla makes no difference - I get the same problem with a
locally compiled copy of Firebird, the downloaded release and the Debianized
releases of both FB and Moz Nav.
> Printing to any of the @:64 printers does not work, including
> spooldir_tmp_Xprintjobs@:64.

At least spooldir_tmp_Xprintjobs@:64 should drop its postscript jobs in the
/tmp/Xprintjobs/ dir. If that is broken something is really screwed up.
Do you have the Debian package net/cupsys-bsd installed?
-->XPrint
Assignee: printing → katakai
Component: Printing → Printing: Xprint
QA Contact: sujay → Roland.Mainz
Deb package net/cupsys-bsd is installed.
Product: Core → Core Graveyard
XPrint support is gone.  See bug 326716.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Seriously, how does INVALID make any sense as a resolution?

Was the bug an actual bug at the time it was filed? Yes, and no one in the past 6 years has ever said otherwise.

ergo, a resolution of INVALID cannot be a legitimate resolution, even once the underlying source of the bug is removed. INVALID is a resolution to be used against reports that aren't bugs, not against legitimately filed bug reports on actual bugs that happen to be no more due to other changes in the codebase.

I see two possible correct resolutions to this:

1) WONTFIX
This would stand as a sort of proxy for "Can't fix", as in "we won't fix it because we can't fix it"
2) FIXED and make it dependent on the bug that saw the underlying source of the bug removed

Since the problem doesn't occur any more, WONTFIX doesn't quite fit as a resolution, even though it sums up the position taken by Mozilla. Therefore, I'll opt for the latter - the problem was "fixed" by fixing some other bug.
Depends on: 326716
Resolution: INVALID → FIXED
You need to log in before you can comment on or make changes to this bug.