Closed Bug 195065 Opened 22 years ago Closed 18 years ago

Can't print anything (mail messages, web pages) on solaris with mozilla 1.3beta "No printer could be found" SunOS/Solaris

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Platform:
Sun
SunOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: vargenau, Assigned: roland.mainz)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3b) Gecko/20030211
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3b) Gecko/20030211

when trying to print a web page or mail message, the print dialogue box
does not appear.
Instead you get an alert box "No printer could be found".

The problem does not appear in mozilla 1.3alpha with exactly the same
environment.

Reproducible: Always

Steps to Reproduce:
1. select print in file menu
2.
3.
Actual Results:  
you get an alert box "No printer could be found".

Expected Results:  
show the print dialogue box
Obviously, the Mozilla's Solaris 1.3b version was compiled with USE_XPRINT and
no longer with USE_POSTSCRIPT. Therefore the Xp extension must be provided.

1. Start Xprt with an unused DISPLAY, e.g. 1
# /usr/openwin/bin/Xprt :1.0 &

2. Set the XPSERVERLIST environment variable accordingly so Mozilla knows which
display to use for printing, e.g.
# export XPSERVERLIST=:1.0

3. Run Mozilla and enjoy printing

Sources involved:
mozilla/gfx/src/xlib/nsDeviceContextSpecXlib.cpp
mozilla/gfx/src/xprint/xprintutil.c

In an earlier comment I said "Run Mozilla and enjoy printing" - after several
hours configuring Xp and testing, my joy is somewhat reduced. Many documents
produce a very poor output on some printers although I tried my very best to
configure everything correctly.

Shouldn't we encourage Sun to re-enable Postscript printing support in the
binary they provide? I compiled a 1.3b Solaris version locally (it defines both
MOZ_ENABLE_POSTSCRIPT and MOZ_ENABLE_XPRINT by default), and the resulting
binary supports both printing interfaces simultanously without any problem. Use
Postscript printing for everyday's reliable printing - use XPrint when you have
time for a look into the future. As far as what I've seen the Mozilla code
already works very well, but the configuration of the various files in
/usr/openwin/server/etc/XpConfig/C/print is not obvious (at least not to me).

BTW: In order to see how the binary has been compiled, try
# strings libgfx_gtk.so | grep printer_list
Postscript printing is supported, if the string "printer_list" is contained
(nsDeviceContextSpecXlib.cpp, line 973).

Sun's Netscape has it:
# strings /opt/SUNWns6/components/libgfx_gtk.so | grep printer_list
print.printer_list

Sun's Mozilla 1.3b not:
#strings /opt/mozilla/components/libgfx_gtk.so | grep printer_list
Severity: blocker → major
Just switched to 1.3b and now I'm sitting here with something that cannot print!
Sic. What are the drawbacks to enable MOZ_ENABLE_POSTSCRIPT again?
I don't think that there is any drawback to enable MOZ_ENABLE_POSTSCRIPT again.
At least it works well on a locally compiled version. If we only knew who made
the Solaris 1.3b binary so we could ask why "--disable-postscript" made it into
the local .mozconfig file.
Carsten Emde:
Your problem only appears if you use the standard configuration from SunOS which
does not set any default model.
Installing rolands GISWxprintglue-sparc package from
http://puck.informatik.med.uni-giessen.de/download/GISWxprintglue-sparc-2003-02-26-trunk.tar.gz
solves this and other problems you may hit.
To cure your specific problem without installing rolands package you can edit
/usr/openwin/server/etc/XpConfig/C/print/attributes/printer and add
*xp-model-identifier: SPSPARC2
to make the SPSPARC2 printer model the default for all printer queues.
Personally I recommend GISWxprintglue-sparc because it has better fine tuning
and more printer models you can choose from.
Bjørn Kutter:
Thank you, yes, I will install GISWxprintglue, run Xprt and switch to X
printing, no problem. And, yes, the other Sun sysops on earth will do the same
when one of their users is upgrading to Mozilla 1.3. I certainly appreciate
Roland's work. There is no doubt that this is the future of printing from
X11-based applications. Only this will provide true WYSIWYG printing, since the
same software that generates the screen display is also rendering the printout.
But why now? Why Mozilla? After all, I still did not understand why a working
printing mechanism that provided us years of flawless and reliable printing is
now disabled. Did I overlook something? Can't we have both Xp *and* Postscript
printing (although I have it working on my locally generated binary)?
I'm facing the same difficulties. My sysadmin's will laugh at me if I request
this at work (>1,000 Netscape/Mozilla users/clients). If Solaris7 (and later) by
default is installed with USE_POSTSCRIPT, Mozilla should support that default
behaivour, imo.
I am seeing this in the nightly builds as well as in 1.3b.

I have to agree with Tomas in comment 7 on this one: solaris is one platform
where it is often not possible for the user to change configurations at will. 
Please don't assume that all the solaris users have superuser privileges!  (Wish
that I did.... but I don't...)

I would very much like to see printing work out of the box the way it does in
all the other applications I use.

Neil
*** Bug 196048 has been marked as a duplicate of this bug. ***
Nominating for blocking 1.3.  The downloadable builds from mozilla.org
should work out-of-the-tarball, in my opinion, as that is where the
majority of folks who live on the bleeding edge with the latest mozilla
go to find them.

(Standard Disclaimer applies: I work for Sun, but am speaking for myself).
Flags: blocking1.3?
The solaris builds are contributed (AFAIK) and if this contributor builds
without postscript you must use xprint or you compile yourself.
(And you could start to contribute a build with postscript).

-> invalid
(Roland : Please reopen if I'm wrong)
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
Thanks Matti for the clarification. Didn't know this platform was contributed.
But does that mean the mozilla.org community doesn't take any responsibilities
whatsoever to the Solaris builds of Mozilla? Even though users are able to send
in bugzilla reports (which are turned into invalid)?

Does anyone know who is in charge of the Solaris builds?
Flags: blocking1.3? → blocking1.3-
I have been downloading solaris builds for a while now: it used to be that the
builds included a README file which had, amongst other information, the
contributor who compiled the build, a list of the flags used, and a list of the
special things the user needed to do to make it work (see for example, I think
it was 1.2.1 built by Noah Friedman, which had an extensive explanation of
various things one had to do to make it work).  I had assumed that since the
last few builds no longer had such a file that a) they were no longer
contributed builds [for which I shouted hurray!] and that they would work out of
the box on an essentially standard solaris system.  Also, I assumed that I would
no longer have to wait two weeks after a release for a build to become available
on my platform.

I am extremely disappointed to hear that this is not the case.  I know that as a
solaris user I am a small potato in the user base, but at the same time I am one
of the users who has the most invested in the success of mozilla: I have no
realistic alternative for browser, unlike windows, mac or linux users.  

Oh well.  I guess that I can always sell out all my principles and become a
windows user and switch to IE.

Seriously, please, if solaris builds are "only" contributed, could someone do
what they can to get Sun involved to change this picture?   And if someone from
Sun *is* involved in the current builds, can they be persuaded that having a
build work out of the box is a good thing?

One last comment: whether the build is contributed or not, there shouldn't be a
Solaris build labeled 1.3 which doesn't work for the average user.  If this bug
is not fixed, that needn't hold up the release on Win/Mac/Linux platforms: but
don't let someone contribute a build for solaris unless it is going to work!!!!

Neil
Flags: blocking1.3- → blocking1.3?
You can see the used build flags in RECENT builds (not 1.3b) with about:buildconfig
I don't know who contributed this builds but I think that this might be 
Roland Mainz.

You are always free to contribute your own builds (solaris-photoscript.tar.gz).
Contact staff@mozilla.org for that. 
BTW: There would be no build without contributor...
i confirmed that Roland.Mainz is the contributor. 
(See the long email address in the CC list of this bug)

Please ask the contributor if you have problems with a build.


Why are you yelling for something which is broken since the Mozilla project was
started ? The Postscript module never really worked, when it was generating a
job it created **** poor output or blew the printer queue up. The Postscript
module does not work on user installations - you need the SunOS 4 compatibility
packages to get it runing(!!). Newer versions rely on Ghostscript to get your
printer accept the output which has to be installed before you can print.
And the claim that the sysadmin will laught is invalid (go kick him, he is
getting paid to do his job) either because SOMEONE already installed GTK on your
box because it is a prerequirement to use Mozilla. Where is the problem to have
another prerequirement to print? The SunOS 4 compatibility packages are not part
of the Solaris enduser installation nor is Ghostscript part of Solaris but
XPrint is... hint hint...
Flags: blocking1.3?
*** Bug 197822 has been marked as a duplicate of this bug. ***
*** Bug 197814 has been marked as a duplicate of this bug. ***
*** Bug 198066 has been marked as a duplicate of this bug. ***
This is awkward. Mozilla should NOT in major features rely on any additional
package which the default system does not have (regardless how "bad" the
default is) ! We recently had this problem with the 1.3b build, which only
ran when you had the bleeding edge versions of libgtkxxx from Sun labs, but
at least 1.3 runs on the default Solaris installations again.

If we really can have both options, then we should provide them, or better,
we MUST provide them. If someone is not happy with the default, he has THE
OPTION to install additional packages, but REQUIRING to install something 
additional before you can use Mozilla just is the best way to KILL this 
project.
Roland, please provide a 1.3.1 Solaris build with BOTH options activated,
if you are the provider. The current situation is unacceptable.
I think this should not be resolved as invalid. Indeed, invalid is it to require
additional software from the contributor to be installed to get Mozilla 
running....

*** Bug 198212 has been marked as a duplicate of this bug. ***
>I think this should not be resolved as invalid.

It's marked invalid because the build contributor (who is cc'ed) means AFAIK
that this is o.k. because the PS modile is partially broken. I don't know why he
don't add a comment to this bug but i spoke with him over IRC.

Feel free to contact Roland Mainz and/or staff@mozilla.org

A "partially broken" Postscript module is more use than an alternative that
doesn't work at all for many users.  Printing used to work, and now it doesn't.
 Please put it back the way it was.
Richard Tobin:
| A "partially broken" Postscript module is more use than an alternative that
| doesn't work at all for many users.
Then contribute your own build if you think you know it better - I will assign
all the bugs like SEGV after printing, print preview not working, print preview
crashes, printing after viewing print preview fails with 'you can not print from
print preview', printing news articles fails and all the +150 issues in that
module to you. Do you agree to that deal?
The Postscript module is turned off for a very good reason: it does not work.

| Please put it back the way it was.
Are you willing to fix the bugs in that module ? Should I assign all the bugs in
the Postscript module to you ?
> Do you agree to that deal?

No, of course not.  I'm just a user who used to have a working browser (at least
in this respect), and now I don't.  I guess you just have to see whether you get
more complaints about the bugs in the Postscript module or about not being able
to print at all.

> The Postscript module is turned off for a very good reason: it does not work.

No doubt true for some interpretation of "it does not work", but the fact
remains that I could print last week and now I can't.
I have printed daily all the last month with Mozilla on Solaris. I really don't
know what you mean with SEGVs and other critical issue. I've NEVER seen them,
and prints where always absolutely OK.


I reopen this one and assign it to roland.
He can mark this invalid again...
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
-> Roland
Assignee: rods → Roland.Mainz
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 198121 has been marked as a duplicate of this bug. ***
*** Bug 198432 has been marked as a duplicate of this bug. ***
This seems pretty simple to me:

_IF_ you require a package people typically do not have, _THEN_ you must list it
in the release notes, the README file, and attempt to report its absence at
install or, worst-case, at first startup.

Right now we do NONE of these things.  Upgrading severity, since this makes
Mozilla pretty much unusable on Solaris (unless I want to install Xprt into
/tmp, configure it, and run it every single time I use Mozilla).
Severity: major → blocker
*** Bug 198609 has been marked as a duplicate of this bug. ***
Here's a workaround for Solaris (for Mozilla 1.3 with Solaris 8,at least):
Download the "Forte build" for Solaris 2.8
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.3/mozilla-sparc-sun-solaris2.8-1.3.tar.gz

Do ***NOT*** download the "2.7" or "CTL and SVG support" build:
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.3/mozilla-sparc-sun-solaris2.7-1.3.tar.gz
This will ***NOT*** print anything and will display this message:
"There was a problem printing. No printer could be found."
Dan Anderson:
| Here's a workaround for Solaris (for Mozilla 1.3 with Solaris 8,at least):
| Download the "Forte build" for Solaris 2.8
|
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.3/mozilla-sparc-sun-solaris2.8-1.3.tar.gz

sure, use that build if you do not mind that table layout is broken (nine
reports), imap crashes (three reports), printing using the Postscript/default
driver causes random crashes after printing (check bugzilla yourself) and random
browser hangs (two reports)
I downloaded and installed the "Forte 2.8" build for Solaris and have been
running it for a day now and the broken table support is surprising. 

Today, when I went to print a page to a PS file, mozilla bus-errored and
crashed. The disheartening thing was that I had not bookmarked the page I wanted
to print and it was painful to find that page again.

I have deleted Mozilla 1.3 on Solaris and have gone back to 1.2.1
The Sun Solaris 2.8 build is broken, as usual. It uses newer versions of Gtk
libraries than the default Solaris 8 installations have. Even installing
the netscape libraries (about 110 MB!) doesn't help.
The only excellent build is Roland's 2.7 build .... if he could simply decide 
to enable default printing additionally to xprint !
Please, all of you who are providing Solaris builds, adhere to what a 
typical default Solaris installation looks like, like all other builders
do ! 
This is in response to Comment #37

> The Sun Solaris 2.8 build is broken, as usual. It uses newer versions of Gtk
> libraries than the default Solaris 8 installations have. Even installing
> the netscape libraries (about 110 MB!) doesn't help.

Does it help to copy the following libs from the Netscape7 package into the
mozilla directory? 

libgdk-1.2.so.0
libglib-1.2.so.0
libgmodule-1.2.so.0
libgtk-1.2.so.0

I suggest you try this because it works for me.

I install each mozilla in /usr/local/mozilla-1.x.y and then put a wrapper in
/usr/local/bin/mozilla-1.x.y to run it. /usr/local/bin/mozilla is a symlink to
whichever mozilla I want my users to have.

I should note that my "usual" wapper (that sets MOZILLA_FIVE_HOME and
LD_LIBRARY_PATH) did not work for 1.3. I had to modify the wrapper by adding:
'cd /usr/local/mozilla-1.2; exec mozilla -splash $*'

I have been running the Sun build of Moz 1.3 for several days now. The README
file that accompanies the distribution suggests that you take the gtk/glib
libraries from the Netscape 7 package (also distributed by Sun). Without these
libraries, I found the build very unstable with frequent bus errors.

We do not have Netscape 7 installed on our system. So I instead copied the
libraries provided with Netscape 6 into a new dir, $MOZ_DIST_BIN/dist/lib and
made the following change to the run-mozilla.sh script:

358,360d357
< 
< LIBDISTDIR=$MOZ_DIST_BIN/dist/lib
< 
362,365d358
< 
< LD_LIBRARY_PATH=$LIBDISTDIR:$LD_LIBRARY_PATH
< 
< 

Since making these changes, I have had no problems with the Sun build of
Mozilla, and can once again print!
*** Bug 199965 has been marked as a duplicate of this bug. ***
I still havent been able to get Xprint to work with my printers though. At least
PostScript produced output I could use. See bug#199963.

If it crashes or hangs sometimes, that's better than no output that I can use.

And I still haven't figured out how to get N-up printing with Xprint. For
PostScript I just set the print command to use mpage instead of lp/lpr and it
worked. Xprint has a lot to offer, but it's not ready yet.

Having both available seams the best solution. Then if something doesn't work
with the PS module, try the Xprint module (like MathML).

Right now I cannot use a newer Mozilla on Solaris, 1.3a was the last release
that worked.

Tried #38 and #39 on Solaris 8 release 10 Patchcluster 1 installed, 
still no Mozilla and thus no printing. --debug run always fails with:
[New LWP 1]
[New LWP 2]
[New LWP 3]
(no debugging symbols found)...warning: Lowest section in /usr/lib/libw.so.1 is
.hash at 00000074
(no debugging symbols found)...(no debugging symbols found)...ld.so.1: 
/usr/local/mozilla-1.3/./mozilla-bin: fatal: relocation error: file
/usr/local/mozilla-1.3/./mozilla-bin: symbol PL_strncpy: referenced symbol not found
Program terminated with signal SIGKILL, Killed.
Tried Xprint (Solaris 8 provided): Results are absolutely AWKWARD ! 
It even does not recognize blanks in text, printing anything in one long 
word ! Have given the font pathes, as described in the release notes.
I don't think that Xprint is anything which is recommendable for use now,
this is Alpha quality at best. Enable default printing !
> It even does not recognize blanks in text, printing anything in one long 
> word ! Have given the font pathes, as described in the release notes.

Read http://mozdev.org/bugs/show_bug.cgi?id=3353
That it a new bug in Solaris, not Mr. Mainz fault. Eclipse people have the same
problem with Solaris Xprt currently.
*** Bug 200833 has been marked as a duplicate of this bug. ***
To #44:
Regardless whom's fault that bug is, the effect is the same:
Xprint is unusable on Solaris. This definitely is a blocker.
Enable default printing. Those who use Xprint will not loose
anything, but those who can't will win everything. There's
ABSOLUTELY NO REASON to block default printing.
I'm not sure if this is relevant to the rest of the discussion, but it might
help other people like me.

I use Solaris 8. I downloaded yesterday's nightly Solaris 2.7 build and could
not print with the "No printer could be found" dialogue box. Downloading the
Solaris 2.6 nightly build solved my problem.



Bug 181213 also appears to be a duplicate of this bug.

We really need this fixed by enabling postscript printing.

*** Bug 202596 has been marked as a duplicate of this bug. ***
QA: Please take measures to convince the build contributor to enable this.
    It's not a good idea to get the reputation of Mozilla be damaged
    by the wrong opinions of a single person. The Steering Committee should
    think about taking Solaris builds back into Mozilla.org hands again,
    maybe Sun can donate a machine for the builds.
Mozilla 1.4b for Solaris 2.7 still has the same printing problem. To be able to
print (in alpha quality, see #43) Xprt has to be running. Please reenable
postscript printing again! Otherwise I'll have to print from the Windows version
and the Solaris builds are not really usuable :(. 
BTW: Solaris 2.8 builds cannot start (relocation error) and as I don't have
administrator privileges, I won't install any new libs!
Flags: blocking1.4? → blocking1.4+
I had the same problem as well (with 1.3). I looked at the Mozilla xprint module
help page (http://www.mozilla.org/projects/xprint/usage/), and here are the
steps I was supposed to do to enable printing (btw, I'm running Solaris 8 with
all the latest patches, or so my sysadmin tells me):

[1] Start Xpriint server (Xprt) if there is none running yet.
Well, ps -ef |grep Xprt didn't produce anything, so I tried the command that was
listed
    /etc/init.d/xprint
I get the error
    /etc/init.d/xprint: Command not found
Great. The first step does not work! So I putz around in /usr/openwin/bin and I
find the Xprt binary. Now how do I run this thing? Well, back on the xprint web
page, there is a sample "ps -ef |grep Xprt" that shows the command line options
for Xprt, but are they the complete set of options? Probably not.

So I read the man page for Xprt, and it tells me that the env variable
XPCONFIGDIR is important, so I do an 
   echo $XPCONFIGDIR
and I get
   XPCONFIGDIR: Undefined variable

The man page says that the default value of XPCONFIGDIR (if not set explicitly)
was /usr/openwin/server/etc/XpConfig, so I cd to that directory. Well, after
traversing a couple subdirectories (C/print), I see a file Xprinters, which is
supposed to store the information about accessible printers, but everything in
that file is commented out (the printers I use are not there). So I'm back to
square one. Maybe I'm missing something? Maybe there is a "global" Xprt server
that has all the right settings, that I can simply point to? Well, I call my
sysadmin and he's never heard of Xprt. Could it be that the solaris systems we
use (we have very few) don't use Xprt at all?

Moral of the story: there are some Solaris installations out there for which
getting using Xprint-only enabled Mozilla to print is not easy (or possible). As
others have pointed out in this thread, even though the postscript support is
broken (I've had problems with output being clipped etc), it is still usable.
Please enable postscript output as well (and the release notes could have a big
bold red-colored blinking markquee that says that if people use the postscript
print option, they must not file printing-related bugs). I think that might be a
win-win situation...

Roland, I hope you've noticed that this is a 1.4+ blocker now...
*** Bug 207352 has been marked as a duplicate of this bug. ***
This isn't a blocker to try to change Roland's build options (although that
would be nice). He's free to build however he likes. 

Starting with 1.4, Contributed release builds will be be segregated in a
releases/mozilla1.x/contrib directory with readme documentation identifying the
contributer, build options, etc. 

mozilla.org doesn't produce "official" solaris builds so if you use Roland's
contributed builds and you find problems that have to do with his configuration,
you'll need to take that up with him. If you'd like to contribute Solaris builds
with postscript or other options enabled, feel free to contact me.
Flags: blocking1.4+
So I'll be looking forward to the contributed builds then! As we are using
Solaris at work and I am not an admin, I don't have appropriate privileges to
install any packages (those suggested to enaple proper non-postscript printing
nor gnu-utilities to build Mozilla myself). 

At this moment in time, administrators are still skeptical against Mozilla and
it is way too much to have them additional software installed just to be able to
do a simple printing job (which looks acceptable). As IE is our official
browsing tool, I can be happy they let me keep a local copy of Mozilla somewhere...

Therefore I am absolutely dependend on some nice people...
feedback from Sun Sverige, response to the attempt to open a customer escalation
about Mozillas inability to print on any level 2 printers:
I was told that I should try the xprint stuff instead and the direct postscript
support is depreciated and will be no longer be available in future versions of
Mozilla.
guys, are you unable to read the docs?
there is a binary tarball available which allows to install+run the XPrint
server WITHOUT any root privileges or vodoo magic.
http://puck.informatik.med.uni-giessen.de/download/xprint-2003-05-08-release_008-sparc-sun-solaris2.7.tar.gz
has a README with instructions. is it really THAT hard?
Direct postscript support is NOT deprecated as far as Mozilla is concerned. 
Contributed builds without it will, as comment 55 says, have to be labeled
specially.
Re: comment #57, Daniel Lilienberg: who told you that direct PostScript support
is deprecated?

/be
Apart from the problem noted in comment #43, another 'nice feature' of 
XPrint is that it breaks up pages which physically do not fit on the 
assigned paper into several pages instead of scaling them down to fit,
like the default and 'broken' postscript module does. Absolutely unusable.

I managed today to get Pete's build (the Solaris 8 Sun contributed) 1.4rc1
build to work! Installing Netscape's 7 dist/lib is absolutely necessary
because the Sun /opt/sfw/lib libraries are incompatible despite they have
been Forte cc compiled (some weird compiler flag set, causes the LWP1 etc
hang symptom.). So set library path to the dist/lib, install patches 
108434,108435,109147 at least, and you can just forget Rolands release 
(sorry, Roland :-< ).

The native Postscript support in Mozilla may be build by default but it is
unuseable for any printers unless you filter its invalid Postscript via
ghostscript to make it valid Postscript code.
I filed a bug long ago about that problem but it was duplicated to another
unrelated bug and never solved - so far to the theory of that the module is
"supported".

We live now with XPrint and are VERY happy with it - it works and is maintained
by a qualified person, all items which the native Postscript support in mozilla
lacks.

re comment 59 David Baron
You say native Postscript support is not deprecated. What is your definition of
"deprecated" when the module is broken and noone fixes it?

re comment 61 beanladen@arcor.de
Your beloved Sun builds have broken table layout, broken IMAP and broken HTML
editor while Mr. Mainz builds are working.
To #62:
I'm printing a couple of times every day since more than a year with the
postscript default (for those builds which had it enabled) directly to 
the printer, did not notice any severe problem.
I'm not using IMAP nor the editor, so I probably do not run into problems
there. But we have a lot of our internal program documentations in tables
with complex CSS styling, and I cannot confirm at all that they are 
rendered wrong.
beanladen@arcor.de
Thank you for proving that you are lying. The problem with the Sun builds is a
known problem since more than a year, a bug has been filed and the build
contributor at Sun has confirmed the problem.


                                  ___________________
                          /|  /|  |                  |
                          ||__||  |      Please do   |
                         /   O O\__         NOT      |
                        /          \     feed the    |
                       /      \     \     troll      |
                      /   _    \     \ ______________|
                     /    |\____\     \     ||
                    /     | | | |\____/     ||
                   /       \|_|_|/   \    __||
                  /  /  \            |____| ||
                 /   |   | /|        |      --|
                 |   |   |//         |____  --|
          * _    |  |_|_|_|          |     \-/
       *-- _--\ _ \     //           |
         /  _     \\ _ //   |        /
       *  /   \_ /- | -     |       |
         *      ___ c_c_c_C/ \C_c_c_c____________
David Schweiger:
| The native Postscript support in Mozilla may be build by default but it is
| unuseable for any printers unless you filter its invalid Postscript via
| ghostscript to make it valid Postscript code.

you do not need ghostscript, the minimum requirement for mozillas postscript
module was recently bumped to postscript level 3 printer with min. 64MB
printing >20 pages requires min. 128MB
if the printer still hangs after receiving the print job you need a firmware
upgrade from your vendor or a newer postscript printer
postscript level 2 printers do NOT work

solution to this mess is to use XPrint which works with plain postscript level 2
with <8MB or filter using ghostscript
Give food, please !! I mean, bug numbers. Nice picture, I love ASCII art.
If you like, I can send you a couple of prints (real paper). None of those
sheets is fake, all original Mozilla default postscript printout.

Anyway, it looks like this discussion gets totally useless. Since Roland feels 
only to be a contributor, we can't get anything if he does not want to feed us.
Mozilla drivers are not responsible for contributed builds.
Since all default postscript module lovers can now use the Sun contributed 
build (provided the Netscape provided gtk/gdk libs are installed), there's a 
working solution for everyone, whatever he likes. So this bug can be closed.
dvschweiger@web.de: Please don't remove someone from the CC list without his
permissions. You have the right to remove yourself.

This bug should be "wontfix" but only the build contributor can do that (Roland)
and you have no right to protest against a "wontfix" because this are his builds.
I've been using nightly builds on Solaris 8, updated about every 6 weeks for new
features for a couple years now.

I use postscript printing, browsing and IMAP email. I use nightly builds because
they work better on my platform than the release builds from ANY contributors
ever have.
*** Bug 214746 has been marked as a duplicate of this bug. ***
*** Bug 211418 has been marked as a duplicate of this bug. ***
not blocking development
severity -> major
Severity: blocker → major
*** Bug 228864 has been marked as a duplicate of this bug. ***
To comment #69, Scott:
Seems that our little dictator has got his hands into the trunk builds you
praised. Now there's postscript disabled also ! 
It should be discussed if this is allowed on the TRUNK builds. I think he 
should do whatever he likes with contributed releases, but I don't think anyone
except the drivers should decide that the postscript module should not be
tested and developed anymore on the TRUNK and force even developers to use
external, private software!
QA, what is the policy for trunk builds for Solaris ?

There are AFAIK no official Mozilla SUN builds except contributed builds.
It's the decision if the contributor ...

CC Asa for an official comment from Mozilla.org about this
Ignore beanladen 'stalker' arcor.de. He is stalking after Mr. Mainz since a year
now. His latest adventure is filing invalid bug reports with invalid claims just
to 'prove' is opinion. In http://bugzilla.mozilla.org/show_bug.cgi?id=195065#c64
he has been identified being a liar and now he starts attacking platform
supporters personally to press his opinion. I think it is time to remove
bugzilla access for Mr. beanladen.
Bug 231944 has been filed to get rid of the troll.
I have to agree with comment 74. The Sun contributed builds, at least 1.6b,
don't include the PS module.

Now, I'm trying to get mozilla accepted. If the entire lp printer setup has tro
be duplicated witrh xprint, mozilla won't go far around here. mozilla would be
the only software that uses xprint, and it doesn't need it. Netscape, IE, and
konqueror all manage to print fine with out it.

Xprint is nice. I'm using it though it crashes mozilla on one machine and the
Xprt server on another often (Xprt is on x86 linux. Mozilla on Solaris 8 for
SPARC, and mozilla on x86 linux)

But trying to get people here to use xprint, and mozilla isn't likely to happen.
I would rather the contrib builds include both. Then when one doesn't work, the
other can be tried. I've had more truoble with xprint crashes than the PS
module. X print looks great when it works though.
Thomas ( #78 ),
seems you mixed it up. PS (AND Xprint) ARE included in the
Forte builds from Sun (Pete Zha) (I don't know about 1.6b, but 1.4,1.5,and 1.6
have it), but postscript is disabled in all of R.Mainz builds.
The reason for the harsh discussion here is that someone wants to force people
to use XPrint. Nobody ever made a claim to remove XPrint support (even I would
not), and it has been proven that both can be enabled without harming anyone.
R.Mainz is not the owner of the PS module, so he won't be responsible for bugs
there. There's no reason to prevent people from using "broken" software if they
like to do so every day. I'm always the first to fight for freedom even of the
dull and dumb, therefore I take the burden to be **** on here voluntarily.
By the way, I'm impressed by the stability and features of Rolands builds 
(esp.that he even got SVG working on Solaris => applause, applause), and by no
means would say that he does not a very good job. With only one notable and 
notorious exception (you guess what I mean)...

Matti:
Bad to hear that the TRUNK is also a contributed-only. So we even can't do
anything regarding this issue. Since Sun is taking Mozilla more seriously 
now and provides new release builds very fast, maybe it's possible to convice
them to take care of the TRUNK for Solaris also. There seems to be no 
technical reason not to provide both (or even more builds) if someone takes 
the workload.

#76,77:
Please make yourself familiar with the VERY details of how setting up Forte
builds and Solaris and any other thing you are talking about, esp. work 
yourself through any single bug you are thinking about and prove that this
makes using the Forte builds "impossible". If you have technical questions,
I can help you out.

I know the 1.6b build for Sun didn't have the PS driver. If the 1.6 final did
OK. The other requirements of those builds are another problem. 

I've never asked that xprint be taken out. Once it works, and get's adoption in
other project, great. But for now mozilla is the only big, well know app that I
know of which uses it.

The PS driver has worked for many since the original m* builds, and doesn't
require another infrastructure to be used.

So the PS driver should be included, for backward compatibility with systems
that cannot use Xprint. I'm lucky here and can use it personally, but others
couldn't use xprint without the sysadmin setting it up, and he won't.

It's really anoying when I print a page and mozilla and Xprint both die.
Since xprint is on a seperate machine, I have to switch to it, restart, the come
back and start mozilla again. If I could figure out what causes the crash, I
would avoid it, but thus far have not found a cause.
I have several Solaris 8 7/03 systems (Blade 150s, Ultra 10s) using Roland's
Xprint-only Mozilla 1.6 build. I installed GISWxprintglue, and did all the
required setup. The printer queue is local, and the printer is attached using
Jetdirect.

I can successfully print www.google.com, but mozilla will bus error on anything
more substantial. For example: www.mozilla.org, maps.yahoo.com . The Sun
contributed Mozilla 1.6 build is broken. The Sun contributed Firefox 0.8 build
is printing reliably for me, and it uses the standard Postscript support. It may
not look good, but at least it's functional. My gcc build of Mozilla 1.3 (with
Xprint disabled) is also printing reliably. But of course, the Java plugin won't
work in the gcc build.

I would try to build Mozilla with postscript support myself, but I don't have
Forte and I really would like Java support. I would appreciate it if you
re-enabled postscript support.
better summary

(note: attempts to contact roland failed so I'm not sure if the bug assignment is helpful, but I'm not changing it even though he's also on the cc: list)
Summary: it is impossible to print anything (mail messages, web pages) on solaris with mozilla 1.3beta → Can't print anything (mail messages, web pages) on solaris with mozilla 1.3beta "No printer could be found" SunOS/Solaris
I'm going to resolve this as invalid because it's pretty much a dead issue. Roland doesn't seem to be active in the project any more. The mozilla revisions discussed are old and no longer supported. Current releases have builds contributed by a Sun employee, and they apparently include the PS module.
Status: NEW → RESOLVED
Closed: 21 years ago → 18 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.