Started Mozilla but can't find any Xprt printers in the print dialog. Further investigation shows that the whole xprint module is missing on components/
this is by design. if you look at the SRPM, you'll notice that xprint is specifically disabled. over to Blizzard
xprint isn't supported in the rpms.
There is no reason to keep it turned off. Reopen...
Christopher Blizzard wrote: > xprint isn't supported in the rpms. Is this "not supported" due technical reasons (if yes - which one ?) or only because RedHat does not want to support Xprint ?
I don't want to support X print.
Blizzard, I understand Xprint module is really good shape now and there is no bad thing for RedHat when you put this module into RPM. New printing dialog has been enhanced to support both Xprint and PostScript printing together. There should not be any regression with Xprint. There are many benefits for us when we support Xprint. We have still some problems around PostScript printing for Asian language and non iso-8859-1 languages. Xprint can be the one solution for those, e.g. bug 119265, bug 121879, bug 126602.
Masaki Katakai wrote: > There are many benefits for us when we support Xprint. We have still some > problems around PostScript printing for Asian language and > non iso-8859-1 languages. Xprint can be the > one solution for those, e.g. bug 119265, > bug 121879, bug 126602. Not to forget that Xprint can print hebrew (bug 24824), polish (bug 63737), arabic, thai, korean, MathML(!!), chinese (verification for the new gb18030 standard pending but I doubt that there are problems), japanese and even sets the job title correctly (bug 6810). And the admins only have to configure the whole thing _once_ on the server side (incl. the fonts which should be downloaded to the printer) and do not need to configure each client seperately for each new mozilla release.
Well, it looks we have two choices here: a) RedHat supports this option to enable asian customers to print with Mozilla and Mozilla-based products on Linux. b) RedHat refuses to support this (http://bugzilla.mozilla.org/show_bug.cgi?id=133534#c6 indicates this), rendering Mozilla unuseable for the asian business world. Choice <b> would indicate that RedHat has no interest in the asian market...
a) Printing Asian fonts work fine with the Red Hat RPMS. All you have to do is assign font names for the various language groups for the postscript driver, which we do for you. b) Red Hat does care about the Asian market which is why we make sure that you can print Asian text with the postscript driver.
blizzard: Who "owns" the RPM generation script in mozilla.org's CVS ? Redhat ? AFAIK other vendors use the same scripts - but they may have another opinion about this case... ... I can't get the point why you refuse this... ;-(
*** Bug 174166 has been marked as a duplicate of this bug. ***
*** Bug 177212 has been marked as a duplicate of this bug. ***
when will this bug be fixed ?
Did you read comment #6 ? the bug owner refuses to fix this bug (ignoring the fact that the alibi support for asian locales in the PS module does not work properly)
This bug should not have been reopened. Xprint is an optional build feature. The lack of an optional feature does not constitute a bug. If you want a xprint-enabled rpm, you can grab the source, compile and contribute one yourself or post to news://news.mozilla.org/netscape.public.mozilla.unix and request that someone build you a xprint-enabled rpm.
Alright people, now hear this: I assume we can all see for ourselves that 1) it is an "optional" feature, 2) Red Hat has support for asian languages in postscript as well (and hence no real *need* for Xprint), 3) this does not constitute a real "bug," and 4) we can download the source and enable it ourselves if we wish. On all four points: that is all very well, but I'd say this is still grounds for a feature request, even if it isn't a bug. I'm quite happy for it to remain WONTFIX, but for the sake of enlightenment, I'd like to know what the reasoning is behind not "fixing" this. If Xprint provides *ANY* additional functionality over the Postscript driver, and assuming enabling it does not require inordinate amounts of additional resources or stupid/silly dependencies, surely it would be more beneficial than harmful to enable it by default, right? I'm willing to accept that there may be a good reason not to enable it by default, but I'd like to know what it is, since I cannot imagine any drawbacks to this that would outweigh the benefits. So will someone please correct me if I'm mistaken?
Error detected. Too many re-opens.
So now that you've assigned it to me, does that mean I am truly allowed to "fix" this feature request? (Assuming I can figure out how, which I won't say is totally impossible--I am guessing it involves a relatively minor tweak to the SPEC file for the RPM. Correct me if I am mistaken.)
Daniel, I figure you may as well enable Xprint in mozilla. Doing so does not stop the default Postscript driver from being available, if users prefer to stay with it. Note that Debian (which I use) and I believe Mandrake, maybe others, have had Xprint enabled for some time now. The latest version of Xprint (v 0.0.9) is in final stages of testing, might be a good point for you to fix RedHat's mozilla (see xprint.mozdev.org).
Would fixing this help Firebird with the same issue or should a seperate bug exist for that?
*** Bug 229538 has been marked as a duplicate of this bug. ***
resolving INVALID. we don't ship RPMS (and we don't ship xprint)