Closed Bug 49947 Opened 24 years ago Closed 24 years ago

Please add --with-xprint to nightly builds

Categories

(SeaMonkey :: Build Config, defect, P3)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: moshev, Assigned: granrosebugs)

References

Details

Attachments

(4 files)

diff to seamonkey-build to add --with-xprint to daily builds
1.14 KB, patch
Details | Diff | Splinter Review
HP changes... (note one of them is from 67840)
6.42 KB, patch
Details | Diff | Splinter Review
suggested patch for hpux,sol26,irix & aix
2.09 KB, patch
Details | Diff | Splinter Review
Turn xprint detection on by default. Use --disable-xprint to disable.
1.88 KB, patch
Details | Diff | Splinter Review
Please add --with-xprint to nightly builds ./configure, It is otherwise impossible to use Xprt engine to print international web pages.
Blocks: 24824
Reassigning to the keeper of the nightlies...Leaf!
Assignee: cls → leaf
Blocks: 49946
taking from leaf since I do the unix verification builds. what I don't know is what Xprint does and if we want it in mozilla and netscape 6 builds across all platforms. Does this do anything to solaris or hpux, or is it linux only?
Assignee: leaf → granrose
URL: N/A
QA Contact: granrose → leaf
Status: NEW → ASSIGNED
Target Milestone: --- → M18
My advice is that we shouldn't be doing things differently for the nightly builds than we do for regular developer builds... if --with-xprint is to be in the nightlies, it should be getting tested by anyone doing a default build (that is, without any ./configure options).
I did not insist on it being for nightlies only, the bug report is to enable xprint on builds (at least nightlies) so that international printing would be possible to test on Unix. Right now no one except those who compile their own mozilla can test international printing. Since the pool of international mozilla users that test regularly is already much more limited than that of those only interested in english, limiting it farther by requiring to build your own mozilla makes it untested. It is my impression & opinion, that w/o international printing a browser is almost useless for non european/english speaking users and thus it is important that this component get tested.
tao, frank, is this true?
QA Contact: leaf → leaf
> what I don't know is what Xprint does and if we want it in mozilla and > netscape 6 builds across all platforms. Does this do anything to solaris > or hpux, or is it linux only? Xprint is the X11 print system (libXp/Xprt) and is (should be...) available on all X11R6 platforms.
CC Momoi who is tracking international issues of UNIX printing.
To speedup this bug/RFE(and get some experience from the real world): What about enabling --with-xprint for nighlies for... say... one or two weeks. If noone complains about side-effects (any known !?) we can keep that status. Comments ?
Sorry... forgot something: --with-xprint can only be enabled on platforms which have libXp.so (X print extension library). --with-xprint is useless on platforms which don't have Xprint (Solaris <=2.6 if using X11 from Sun). Therefore the default should be: Test if libXp is available --> build with --with-xprint. If not... ignore it. :-)
Guys, We need to be testing at least 3 known methods to print international data on Unix. "xprint" is one of these options and if it is now available in the code, we would like to start looking at it.
Xprint is available in code. Code compiles and (AFAIK) works on little-endian platforms, _using_ it on big-endian platforms results in an error (this is known as bug 49879). Xprint itself had some bugs prior to X11R6.5.1, I suggest to use newest Solaris 7/8 Xsun+Xprt+Xprint patches or compiling Xprt from X11R6.5.1 to get proper results.
How about Linux? Is libXp.so distributed with the Linux version of X11R6?
> How about Linux? Is libXp.so distributed with the Linux version of X11R6? Yes, it is: -- snip -- > uname -a Linux sepia0 2.2.14 #1 Mon Mar 13 10:51:48 GMT 2000 i686 unknown locate libXp /usr/X11R6/lib/libXp.so /usr/X11R6/lib/libXp.so.6 /usr/X11R6/lib/libXp.so.6.2 ... -- snip -- Note that Xprt is an usual X server (which implements the Xprint extension), therefore it isn't required that client&server are on the same machine (e.g. there's no need that build config checks for "Xprt"...)...
from bugid 49946: > However, I didn't add the feature to switch normal PostScript > or Xprt printing because Xprt components would not be built by default. > If Xprt will be built by default (by fixes in 49947), I think > we should add the feature to Print Dialog GUI. Maybe we should change the SUMMARY to "--with-xprint should be enabled per default if libXp.so is present". Are there any reservations against implementing this (if yes... why ?) ?
IFAIK lipXp need not be present since it is X protocol and can be available on the wire.
> IFAIK lipXp need not be present since it is X protocol and can be available on > the wire. Uhm... no. Xprint uses a X11 server which looks like any other Xserver except that it supports the XpPrintExtension. libXp is the client-side support library for the XpPrint extension; the library get's dynamically linked to that module which uses the XpStartJob/XStartPage etc. functions. Xprt can be elsewhere in the network but libXp is required in the client to manage the Xprint extension...
I stand corrected
> I stand corrected ^^^^^^^^^^^^^^^^^^^ Uhm... seems my english is getting worse... what do you mean ?
IANANES (I am not a native english speaker)... I was wrong, You corrected me, I stand corrected, meaning i understand that i was wrong and you are right.
*** Bug 52076 has been marked as a duplicate of this bug. ***
Any update here ? Currently I would vote to kill the --with-xprint option and replace it with --disable-xprint (this means: Xprint should _always_ be build unless someone disables it OR libXp.so is not available on the system).
i think we should turn --with-xprint on for the nightlies, as was suggested, and see if we get complaints... then turn it to --without-xprint when nobody complains. The problem comes when we build on a machine with the libraries, but failure occurs when binaries are run on machines without the libraries. Does this failure happen gracefully?
Nice !! AFAIK libXp.so is linked dynamically into the module - if /usr/lib/libXp.so was available during build but isn't available at runtime the module/application cannot start. But: Normally libXp.so is available on a specific OS release or not. Build Mozilla for that release and it will work on that release (and on future backwards-compatible releases). AFAIK Linux is not a problem because Xfree86 has libXp.so since years. Solaris comes with libXp.so since Solaris 7/MU4. Status of AIX and HP-UX unknown. If they have >=X11R6.3 they should have libXp.so...
HP has /usr/lib/libXp.sl (please do not hardcore .so ANYWHERE in the code or Makefiles) AIX seems to NOT have libXP.so. But will look around.
What is *.sl ?? Has AIX >= X11R6.3 ?
.sl, hp's Shared Library just a different extension. in Makefiles you use $(DLL_SUFFIX) for source there is some 'suffix' define that you use. (i.e. instead of hardcoding dlopen(/usr/lib/somesilly.so); PR_LoadLibrary(/usr/lib/somesilly$(DLL_SUFFIX) Yes, AIX has X11R6, but I might not have put on the 'xprint' ptf. So in ANY case, you can't assume that every platform has it, you probably need a HAVE_XPRINT test inconfigure... check for -lXp or something.
> AIX has X11R6 ^^^^^ Xprint was (AFAIK) new in X11R6.3. "We support X11R6" normally means X11R6.[01] - if a vendor supports X11R6.4&co. they (normally) annouce it with loud noise... =:-) I would vote for the test in ../configure ... :-)
Mhhh, somehow the reference to blocking bug 49879 was not set... fixed. Xprint now works on all platforms (which have libXp.$(DLL_SUFFIX)) regardless of endianess... Are there any problems left with enabling Xprint for the nightly builds (better (as suggested): kill --with-xprint and replace it with --without-xprint) ?
Depends on: 49879
nothing left except changing configure.in and getting cls to super review the change.
How much time would this take (well... I fixed "target milestone"; M18 was long long ago... ;-(( ) ?
Target Milestone: M18 → mozilla0.8
Xfree86 CVS now includes Xprint from X11R6.5.1, next official release after 4.0.2 should include properly working Xprint... :-)
setting milestone to m0.9, adding cls to cc. anyone have any objections to turning this on by default for the nightly builds?
Target Milestone: mozilla0.8 → mozilla0.9
No objections here.
No objections here (except the minor glitch that the Solaris 2.6 builds will still be compiled without Xprint because 2.6 does not ship with libXp.so. Question is if nightly builds using 2.7/MU4 are planned - or not)... After all... please _enable_ it - the remaining "issues" can be solved later... :-)
I need a review and super-review of that patch. I'm doing a linux test build right now (should show up in the 2001-02-14-16 directory in an hour or two) and noticed the configure test for "xprint insanity" doesn't complete: checking for GTK - version >= 1.2.0... yes checking for xprint insanity... checking for XpGetPrinterList in -lXp... yes checking for libIDL-config... /usr/bin/libIDL-config so it looks like there may be a problem there (how small or large I leave to the xprint wizard(s).
r=cls on the seamonkey-build patch. The "checking xprint insanity" message can safely be ignored/removed.
checked in. should show up first in tonight's 8pm mozilla build.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
adding --with-xprint has killed irix65, hpux11, and sol26. I'm about 5 seconds from backing it out unless someone can give me a reason not to. reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Good reason?, how about 2: 1. Mozilla has passed 0.8 and nearing 1.0 milestone. 2. Browser that prints everything but english as gibberish is an English-only browser. if (1 && 2) { decision = somethingWrongWithMozilla | mozillaDoesNotWantMeAsAUser; }
Uhm... need error messages...
I am working on the hp piece of this... already tracked down one piece... (getlogin_r not being defined... need to define _REENTRANT (which wasn't for HP)... I will work on it and let u know my diffs.
yes, and better a working english only browser than no browser at all. sol26 & irix65: "configure: error: Could not find the following XPRINT libraries: -lXp Warning: mozilla configure failed." so no makefiles, so no build. I'm assuming this is a problem with the --with-xprint configure test not correctly testing if Xp exists or not, or at least not on irix and solaris. Frankly, as a Netscape employee, I could care less about Solaris, HPUX, or Irix as long as Linux works. However, I know there are people in mozilla and other parts of Netscape who are very interested in these builds. So if we can't make --with-xprint behave, it's coming out of the nightly builds until it's fixed.
Isn't it possible to hack test for libXp.so in ./configure to fail silently (better: No fatal error) if --with-xprint is given but no libXp.so is available ?
It looks like a test is done in configure, but not sure if it is working... Also there seems to be a BUG with this code: gfx/src/xprint/nsFontMetrics.h declares class nsFontEnumeratorXP : public nsIFontEnumerator and in the .cpp defines nsFontEnumeratorXP::nsFontEnumeratorXP nsFontEnumeratorXP::EnumerateAllFonts (twice) But does NOT define an instance for nsFontEnumeratorXP::HaveFontFor so someone still has some work to do... (this should NOT be put into the nightly builds till these issues are resolved!)
> But does NOT define an instance for nsFontEnumeratorXP::HaveFontFor > so someone still has some work to do... Rahhhhhh... this is bug 67840... It did work until some anonymous programmer checked-in some code which doomed all toolkits except one (Win32!?)... There's a patch in bug 67840 fixing this issue...
Depends on: 67840
bug 67840 should have been fixed already, I'll go push on ftang (not anonymous, we know who did the bad thing) to get dbaron's patch in. /be
to get HP ok with this... -I need the fix for 67840 (see diff I just posted) -I need to define _REENTRANT in configure.in so that getlogin_r is defined for HP (/usr/include/sys/unistd.h) this is HP only.
> I'll go push on ftang (not anonymous, we know who did the bad thing) I know... and maybe - some night... some dark corner of the town... [OK... I am not Stephen King =:-)]
Uhm... getlogin_r()... are we talking about this piece of code in nsXPrintContext.cp ? -- snip -- // Set the Job attribute if (!getlogin_r(logname, loglength)) { sprintf(logname, "Mozilla-User"); } sprintf(cbuf,"*job-owner: %s", logname); XpSetAttributes(mDisplay, mPContext, XPJobAttr,(char *)cbuf,XPAttrMerge); -- snip -- This code can be removed for the following reason: "*job-owner:" attribute is set by libXp.*. This code was only neccesary for older, obsolete and buggy versions of libXp.so which did not have a "*" in front of the attribute name. I hunted this bug myself, killed it myself, wrote the fix for it myself and passed it myself to Sun and X.org. response from Sun enginering: -- snip -- > BugId 4323892 > Synopsis: printjob owner is not adjusted correctly > Evaluation complete: yes > Evaluation: > will fix as suggested fix. > > 2000-03-22 > Commit to fix in releases: x116.4.2_11 -- snip -- Remove that piece of code and HP-UX will be happy... (except HP shippy older libXp.* libs - but that's definately not our problem... =:-)
that may fix hpux, but what about irix65 and sol26? sol26 is our most popular unix build after linux.
Solaris 2.6 does not have libXp.so at all. X11 print system was introducecd with the X11R6.4 update in Solaris 7 (Maintaince Update 4(MU4)) - now the whole stuff is in the "recommended patch cluster" for Solaris 7 == everyone who has Solaris 7 should have it. 2.6 does not have libXp.so (yet!?) and should fail _silently_ (e.g. no fatal error!).
IRIX... was is IRIX ? Mhhh... long long ago there were these SGI boxes, right = =:-)) I don't have an IRIX machine... can't say anything about it. I assume if it has X11R6.4 (note the ".4" !!) it should have libXp.so...
Ok... so removing the getlogin_r fixes the HP need for defining _REENTRANT. As far as Solaris2.6 & Irix... the problem is that configure is dying when it looks for -lXp. "configure: error: Cound not find the following XPRINT libraries: -lXp Warning: mozilla configure failed." So when configure fails the build doesn't happen. So it looks like the configure test of -lXp isn't quite right... (for solaris and irix)
> Ok... so removing the getlogin_r fixes the HP need for defining _REENTRANT. Don't forget to remove some lines in nsXPrintContext.cp... :-) > So when configure fails the build doesn't happen. So it looks like the > configure test of -lXp isn't quite right... (for solaris and irix) What about simply catching that error and turn-off --with-xprint if this error occurs (maybe we should rename the option to --try-xprint-if-available... :-) ?
yes, I did your (sun's) suggests --snip-- As far as the -lXp issue: I am not a configure/autoconf expert so don't know how to tweak it so configure's AC_CHECK_LIB doesn't exit on error. For this I will need some help. BTW: I am going to grab dinner now... so will be gone for a couple of hrs.
> I am going to grab dinner now... so will be gone for a couple of hrs. ...and I need some sleep. Much sleep. Brain uptime ~20h. Shutdown required... :-) BTW: Yesterday I send a "broadcast" to drapeau@eng.sun.com, glen.petrie@eitc.epson.com, katakai@japan.sun.com, petitta@netscape.com, syd@netscape.com, tajima@eng.sun.com, tlogue@vcd.hp.com, waqar@netscape.com to query them for the future of the Xprint module - but no response yet. Any idea what's going on ? I do not feel good to start massive surgery on foreign code... ;-(
I've removed --with-xprint from the daily verification builds until it configures correctly on irix65 and sol26 so that the builds complete.
I don't agree with the silent failure condition for --with-xprint. If the user specifies a build option that has external deps, the configure script *should* fail if they do not have the deps. It might be different if xprint was on by default and the user had no expectations about the optional feature one way or the other.
I really don't get it. May I suggest the following: 1. Xprint is needed for international printing. 2. International users are just as important as Irix users 3. Untill Xprint is in nightly builds it won't be tested. 4. If on some platform --with-xprint is not working now #define around it (disable --with-xprint) on these and only these specific platforms. 5. Open bugs on those platforms where xprint does not work The result of this would be: 1. XPrint in nightly builds for those platforms where it does not cause trouble 2. No XPrint for those platforms where it does not work anyway The way it is suggested here it is one of the two: either Xprint is included in nightly builds for all platforms or No Xprint. I can't see how this is better than what a common sense IMHO suggests: keep it where it works don't enable it where it does not and open appropriate bugs. Rgrds, Moshe Vainer
If the international printing in Linux won't make it into the Mozilla 1.0 I really wouldn't be thinking about using it anymore. I'm using it for year and a half and it still can't print docs in my native language. Please, please fix it.
I am guessing that we can get this in before the end of the week. Seeing as how, it went in, but got pulled means that the intention for it to be in is there. We just have to fix the minor details. Once we nail the 'correct' configure test I think we are home free (but then again I always think that). patience please.
what Jim said. I'm happy to have xprint in the builds, and the more international users the better. However, turning on a configure option that causes configure, and the build, to fail is indicative of a poor configure test. It is up to configure to determine if xprint should be turned on for that build or not and that's failing on irix65 and sol26. Fix configure so that it doesn't fail on those two platforms when you use --with-xprint (for the configure or the build) and I'll put it back in, it's that simple.
It would only be a bad configure test if the test was on by default. Since it is an optional test that the user has to specifically enable, then the user needs to be informed when they don't have the proper dependencies. We do not override the user specified options without a pretty good reason and the desire to give a blanket option to the nightly automation is not a pretty good reason. The current options are: 1) upgrade those boxes to have the proper dependencies 2) turn xprint on by default so configure can autodetect it 3) only give --with-xprint to the boxes that have the proper dependencies
> 2) turn xprint on by default so configure can autodetect it Please autodetect it !!
I would also agree to turn it on by default... but in doing so we need to fix configure and for HP... remove the getlogin_r code... so, so we agree on a patch, I am still pushing for my lastest (2/19/01 17:26).
> If the international printing in Linux won't make it into the Mozilla 1.0 1. Only Xfree86 V4.1.x branch (recent is 4.0.2, upcoming 4.0.3, next big release will be from the V4.1.x branch) will contain Xprint from X11R6.5.1 (=(more or less) working Xprint) 2. Please take a look at my comments in bug 68779 ("2001-02-20 16:11") - Xprint (in general - not Mozilla-specific) is nearly from being doomed by this issue...
Roland, I was talking about international printing and not specifically about Xprt. I would like to remind you about the discussions in bug #24824 : 1. Mozilla prints html pages with ANY encoding to a postscript file with fonts explicitly set to isolatin1encoding. 2. I stated this is a bug even if the user does not have postscript fonts for his encoding because blindly overwriting the most basic parameter of a font (it's language) to something that is in a different language is a bug. 3. I was answered that it is not important, mostly because Xprint is the right way to go. Something along the lines: "just run xprint and everything should work" 4. This bug was started as a result from this reply. Basically it said: forget the bug in postscript output, Xprint is the way we decided to go, postscript is dead. But your last answer suggests that xprint is some future development that may work sometime in the future. And this brings me again to the basic issue: is international printing an important issue or not? If i would right code that would accept an HTML with charset iso-8859-8 and choose a font to display it by looking for all fonts that have charset iso-8859-1, that would be a bug, a major one. But mozilla folks happily ignore it for the last almost two years since i raised this issue. Frankly, i don't know what more can i add. It is the first time that i see an open source project that states bluntly that it only cares about english users. Mozilla is a dead end, at least for me.
To moshev: Xprint is the way to go because it is a _transparent_ way to generate/handle most print systems and output filer formats (including PostScript, PCL and raster formats; planned are Unicode-PostScript, G3 fax support and PDF (these last two can be also be generated by hacking Xprt's config to process PS/PCL driver output and convert it to the "wanted" output format)). Problem listed in bug 68779 is that the _server_ side (Xprt) seems to do crap things. Output is "technically" correct - but without using build-in printer fonts both quality and usuability (ever tried to send 700MB PS jobs down the printer spooler ?) of the output is "limited". Xprint support is not the source of the problem - these issues have to be solved on server side (which is more or less under control of HP/Sun staff) by... a) ...skrinking PS print job size by downloading fonts to printer instead of creating bitmaps for each glyph (which also looks pretty ugly (this may also be a side-effect that 100dpi bitmap screen fonts are scaled to fit in 300dpi/600dpi. And then this issue ends-up in font licensing issues as some companies have licensed their fonts for certain screen DPIs - but not for printer resolutions... ahhhh.... ;-( )). b) ...fixing Xprt/XListFonts()&co. to return only internal printer fonts if "*xp-listfonts-modes: xp-list-internal-printer-fonts" is set.
Roland, thank you again for promptly explaining the issues to me. Please understand that my cry is not for my personal web experience. I have two PC's on my desk and a switch and vnc between them, when i want hebrew/russian or whatever, i switch to windows. My concern however, is to make mozilla, and through it linux, acceptable where i live. I reread the comments in bug 24824, and here are few issues: 1. Isn't font embedding in postscript can be done once for each font glyph, and not for each character of the text? 2. Most local printers already have local fonts embedded. 3. If not, most local users of linux and/or other os's have their postscript fonts updated to include versions in their local versions. 4. I believe that's how lyx prints hebrew. 5. defaulting to isolatin1 is worse than not printing at all. (the reason for this is that the most basic and important property of any text is the ability to read it.) Now to your remarks: 1. I don't know what licensing issues are involved here. 2. If i understand the whole Xprint issue correctly, you are saying that it is not mozilla'z job to provide correct postscript output, you would rather delegate it to Xprint. Am i right? If so, why to print in languages other than english at all? if there is no engine that is capable to take care of correct printing, just don't print.
> 1. Isn't font embedding in postscript can be done once for each font glyph, > and not for each character of the text? AFAIK yes... but the Xprt _sample_ implementation of the PostScript driver may be too simple to handle that (but AFAIK someone is working on that issue (reducing print job size)...). > 2. Most local printers already have local fonts embedded. Mainly yes - but Xprt needs to _know_ about that fact (see comments in bug 68779). Unfortunately the X11R6.5.1 release only contains three sample configs - but AFAIK there are hundreds of configs available (mainly for HP printers... :-) Seems we have to "ask" (force!? =:-) HP to release the remaining ones... > 3. If not, most local users of linux and/or other os's have their > postscript fonts updated to include versions in their local versions. It would be nice to fix [1] if it hasn't already be done (unfortunaltely I lost my ability to "understand" PostScript without spending hours in front of the code - I cannot check this...) > 4. I believe that's how lyx prints hebrew. ???? > 5. defaulting to isolatin1 is worse than not printing at all. (the reason for > this is that the most basic and important property of any text is the ability > to read it.) :-)) Xprint does not "default" to any locale - it uses X11 to handle this issues (see comment below "how Xprint works"... ---- > 1. I don't know what licensing issues are involved here. Think about that a vendor may have licensed a font...Courier-bah-bah-100dpi (scalable). As far as I have heared some licenses are limied in DPI, e.g. using this font at 300dpi isn't covered by the license. But these stories are some years old... I don't know if they apply to today OS releases (for example Solaris 2.7/2.8...). > 2. If i understand the whole Xprint issue correctly, > you are saying that it is not mozilla'z job to provide correct postscript > output, you would rather delegate it to Xprint. Am i right? Correct. This is done by the Xprint driver (DDX) in the Xprint print server (Xprt). To explain quick&dirty what Xprint is: Xprint is "just another Xserver" - but instead of displaying windows to gfx card it prints the windows on a printer. This is archived by tracking all drawing commands which are send to the Xserver and sending it to the DDX driver (PostScript/PCL/raster/PDF/G3-FAX - whatever you want... :-). The Xprint extension tracks printer-special features/attributes like page layout, dimension, printer/queue selection, start/end job/document/page markers and so on... Xprint is just another X11 client/server - and in the most cases only <= ~50lines of code (in Motif 2.x) are required to add print support for your application (Mozilla needs "more" because Mozilla implements it's own whole widget toolkit)... Best idea for now would be to join&vote for bug 68779 and try to find out the current status of Xprt - and who's working on it's code and to find out what the future planns for Xprt are... BTW: Xprt has a PCL5 driver, too. Does anyone know a good PCL5 viewer for Linux/Solaris to "test" how the output would look like ? Maybe all those issues do not exist in PCL DDX (+PCL5 supports compression - this should reduce job size little bit)... (I do not own a PCL5 capable printer...)
Leaf: can you review my configure.in patch to turn xprint on by default? (attach 25868) ftang, tao, dcone: can one of you review jdunn's fix for comm unix builds? (attach 25663)
r=leaf for configure.in xprint-enabling.
Target Milestone: mozilla0.9 → mozilla0.8.1
Hi, Brian: Are you familiar (or comfortable) with the code in http://bugzilla.mozilla.org/showattachment.cgi?attach_id=25663? If so, would you give a review? Thanks!
ftang@netscape.com would be a good reviewer for the font stuff, while katakai@japan.sun.com might be a good reviewer for the getlogin stuff (or perhaps he could suggest a good reviewer).
And Roland.mainz@... suggested to remove the "getlogin" stuff because it was a "workaround" for an old, fixed bug in libXp.so The "font" stuff was neccesary to fix a problem introduced by an interface change... :-)
r=ftang for +nsFontEnumeratorXP::HaveFontFor part
this isn't critical to 0.81.
Target Milestone: mozilla0.8.1 → mozilla0.9
accepting.
Status: REOPENED → ASSIGNED
Has this patch already been checked-in ? Can anyone of the HP/IBM side check if patches in bug 72087 (latest, please) work on HP-UX/AIX, please ?
Blocks: 72087
I will try to get to this sometime this week and try it on both HP & AIX (i am ambi-unix-erous).
To Jim Dunn: Is it possible to hack quickly a build-up and see if it compiles, e.g. does not break the build ? I am very afraid of the situation that the patch in bug 72087 and the one from this bug get's rotten and needs an update - which ends-up in the situation that I don't have the resources yet/anymore to create a new one... ;-( Please... ;-(
target == future == when this won't break linux, hpux, or solaris.
Target Milestone: mozilla0.9 → Future
To Jon Granrose: Current patches in bug 72087 work on Linux/Solaris and should work on HP-UX/AIX, too. I don't have any problems on my radar which prevents us from enabling it - except that we're missing checkin-permission from shaver&co... What about setting "target milestone" to "0.9" or "0.9.1", please ?
To Jon Granrose: Can we try it again, please ? Patches in bug 72087 have been checked-in and that code works on Solaris&&Linux...
"should work" != "works" on hpux. I can let irix slide, but jdunn et al. will be very irate if this goes in and breaks hpux. We got burned by this one before and I'm not going to rock the build boat in the middle of a milestone.
> "should work" != "works" on hpux. I can let irix slide, but jdunn et al. will > be very irate if this goes in and breaks hpux. I hacked the Xprint module code a lot - it should be little bit more portable than the previous code - even the xx)(/"!!""§§"-picky Sun Workshop 6U2EA2 likes it... =:-) (And I even care about IRIX... if it breaks _any_ platform I'd like to fix that ASAP... :-) > We got burned by this one > before and I'm not going to rock the build boat in the middle of a milestone. Agreed. Can this be done after the 0.9 branch ?
I will try to get to look at this sometime this week, but can't promise.
Well I tried to apply the patches in the other bug but got LOTS of HUNKS failed in the dry run... so in order for me to do any testing I will have to hand apply the patches... and I just don't have time to do that in the next day or 2. If someone can tar up the xprint directory (with the patches applied and email it to me... I can just blast them over the existing files and see if that works...)
jdunn: Small hint: The patches in bug 72087 have already been checked-in...
[sorry, accidently hit "Commit" on wrong bug... ;-(] jdunn: Small hint: The patches in bug 72087 have already been checked-in... :-)))) Just pull current CVS and "configure --with-xprint" and it should work...
Ok (thanks!) During building it stops in gfx/src/xprint/xprintutil_printtofile.c can't find wait.h. Looking at this >#ifdef XPU_USE_THREADS >#include <time.h> >#include <pthread.h> >#else >#include <wait.h> >#endif /* XPU_USE_THREADS */ >#include <unistd.h> >#include <sys/time.h> > >#define NeedFunctionPrototypes (1) /* is this legal from within an app. !? */ >#include <X11/Xlibint.h> >#include <X11/extensions/Print.h> >#include <X11/Intrinsic.h> > >#include "xprintutil.h" where is XPU_USE_THREADS supposed to be set... I see it is set in xprintutil.h but, that is included AFTER this line of code.. So as is... this code is 'bad'. fix it and let me know
Ouch... that's fun... =:-) Originally XPU_USE_THREADS was set in Makefile.in - but due review complaints I moved this into xprintutil.h which checks for USE_MOZILLA_TYPES anyway... (The code still works on Solaris/Linux but uses the fork() version instead of the threaded one... nice... =:-) The quick&dirty workaround is to change the follwing line in mozilla/gfx/src/xprint/Makefile.in from -- snip -- DEFINES += -D_IMPL_NS_GFXONXP -DUSE_MOZILLA_TYPES -- snip -- to -- snip -- DEFINES += -D_IMPL_NS_GFXONXP -DUSE_MOZILLA_TYPES -DXPU_USE_THREADS -- snip -- I have to fix three other bugs in my queue before this one will scream&die with pain... =:-))
Stupid question: Does it work if you move #include "xprintutil.h" before #ifdef XPU_USE_THREADS ? (I cannot check this yet... my build is still compiling (nearly a day now thanks to bug 66529... ;-(( ).
no... lots of nspr include issues... so instead I just hacked it and did a #define XPU_USE_THREADS 1
but it does work if I move the ifdef XPU_USE_THREAD clause AFTER the include of xprintutil.h
I assume my original idea to remove XPU_USE_THREADS from Makefile.in wins the award for "dumbst idea in Mozilla.org history". Ouch... ;-(( ---- Looking at waitid(2) - what does HP-UX/IRIX include to get the prototype for the waitid() call (cut&paste from Solaris 7 manual page) ? -- snip -- System Calls waitid(2) NAME waitid - wait for child process to change state SYNOPSIS #include <wait.h> int waitid(idtype_t idtype, id_t id, siginfo_t *infop, int options); DESCRIPTION The waitid() function suspends the calling process until one of its child processes changes state. It records the current state of a child in the structure pointed to by infop. It returns immediately if a child process changed state prior to the call. The idtype and id arguments specify which children waitid() is to wait for, as follows: o If idtype is P_PID, waitid() waits for the child with a process ID equal to (pid_t)id. o If idtype is P_PGID, waitid() waits for any child with a process group ID equal to (pid_t)id. o If idtype is P_ALL, waitid() waits for any child and id is ignored. The options argument is used to specify which state changes waitid() is to wait for. It is formed by bitwise OR opera- tion of any of the following flags: -- snip --
jdunn: No further problems ?
well that waitid prototype looks the same on HP. So what is the 'fix' to add -DXPU_USE_THREADS in the Makefile? If we do this then HP will build and I am cool with this. I haven't don AIX... but since xprint isn't supported on my version of the OS, I am not too worried about this code being built.
> well that waitid prototype looks the same on HP. But in which _include_file_ is it ? I'd like to keep the code as portable as possible - even the fork()-version of xprintutils should work... :-) > So what is the 'fix' to add -DXPU_USE_THREADS in the > Makefile? AFAIK yes. But I would prefer the reordering of the xprintutil_printtofile.c and move the block -- snip -- #ifdef XPU_USE_THREADS #include <time.h> #include <pthread.h> #else #include <wait.h> #endif /* XPU_USE_THREADS */ #include <unistd.h> #include <sys/time.h> -- snip -- below xprintutil.h ... this would be easier and still matches the original review for bug 72087... :-) Or does anyone here see problems with that idea ? > If we do this then HP will build and I > am cool with this. Me, too... :-) > I haven't don AIX... but since xprint isn't supported > on my version of the OS, I am not too worried about > this code being built Are you _really_ sure that no AIX version has libXp.so ? And what about IRIX ?
on HP, stdlib.h include sys/wait.h and waitid is defined in sys/wait.h so on HP you don't even need to include wait.h directly. As for AIX, yes, I am sure that AIX 4.3.3 has a libXp, however, I don't have a AIX 4.3.3 build system setup... and when I get around to it... then I will worry about this. As for IRIX... no idea, you might want to ask richard hess (rhess@engr.sgi.com). I don't have a system handy to try it on (nor the time/inclination).
> on HP, stdlib.h include sys/wait.h and waitid is defined in sys/wait.h > so on HP you don't even need to include wait.h directly. Does that mean it works when we do it like this #ifndef PLATFORM_HP #include <wait.h> #endif /* !PLATFORM_HP */ > As for AIX, yes, I am sure that AIX 4.3.3 has a libXp, however, I > don't have a AIX 4.3.3 build system setup... and when I get around > to it... then I will worry about this. Can we CC:' some IBM staff to check this out, please ? > As for IRIX... no idea, you might want to ask richard hess > (rhess@engr.sgi.com). I don't have a system handy to try it on > (nor the time/inclination). I put his email into the CC: field... =:-)
It doesn't matter whether u include wait.h or not on HP... (i was just letting you know where waitid was defined...) so don't do anything special (other than moving the include after the headerfile) and if you can find someone to cc from ibm... that would be great... i have been trying to get someone involved forever...
No version of AIX has libXp or Xprt support. We are investigating if it can be added.
Blocks: 78548
I filed bug 78548 ("Xprint 2nd revamp...") to address the portability issues listed here...
No longer blocks: 78548
Depends on: 78548
Jim Dunn: Can you check whether the latest patch in bug 78548 has any portability issues left, please ?
Adding mkaply to get someone from IBM "in" this bug. We have to be "AIX-clean" before we enable Xprint per default on all platforms... Yes... I know that most AIX versions do not have libXp - but can someone check please what happens when it is available on this platform ? ---- Jim Dunn: Is it possible to set the milestone to 0.9.3 or 1.0 ? I assume it is possible to get Xprint nearly completely functional until 0.9.2 (most time is cycled in getting r=/sr=/checkin for the patches... ;-((( )...
For what it's worth, IRIX does NOT support Xprint. We use a package called Impressario to provide print support for our Desktop Applications... :-l
Roland: > most AIX versions do not have libXp It's not most, none has it. > can someone check please what happens when it is available on this platform ? What do you mean? I'm still investigating if Xprint support will be added. But if it is added, it probably will take a while until it is available, so let's just build conditionally and turn Xprint off for AIX. If support is not added, AIX Mozilla needs to look into fixing the postscript problem of bug #24824.
Mary Hoetzel wrote: > > most AIX versions do not have libXp > It's not most, none has it. ;-((( > > can someone check please what happens when it is available on this platform ? > What do you mean? Take at the patches attached to this bug... they only enable Xprint when libXp.so is available... > I'm still investigating if Xprint support will be added. But if it is added, > it probably will take a while until it is available, so let's just build > conditionally and turn Xprint off for AIX. See above. Xprint on AIX would only be build if libXp.so is available. No libXp - no Xprint support. > If support is not added, AIX > Mozilla needs to look into fixing the postscript problem of bug #24824. This far out of my scope... all my current Xprint builds can print these pages without any problems[1] (assuming you have the matching fonts installed - if you have those fonts as PS fonts Xprt will download them with the print job to the printer...). I really wish more people would work on the Xprint solution because this solves nearly[2] all i18n-printing issues on Unix... and Xprint is faster, has a smaller footprint (+module size - compare the plain module filesize - I assume that the native PS module will still grow in size when additional features are added - but Xprint module will continue to shrink when reuseage of other toolkit code will be implemented...), is far easier to maintain, has server-side configuration for all applications and all printers, is network-transparent (in theory you can run one Xprt for a whole cluster - no need for the BSD print protocol anymore (+better resource control and authentification)), cross-platform (interoperability!!) and so on... [1]=Still fighting with "proper image scaling" vs. "xlibrgb.c"... Need help... ;-(( [2]=(more work must be done on the Xprt side to implement PPD, Unicode-PostScript and PS-Level-3 support... help wanted...)
Richard Hess wrote: > For what it's worth, IRIX does NOT support Xprint. ;-(( Why ? > We use a package called > Impressario to provide print support for our Desktop Applications... Do you have any URLs which describe the functionality offered by "Impressario" ? I'd like to compare both solutions...
Can anyone please r=/sr= the patch (http://bugzilla.mozilla.org/showattachment.cgi?attach_id=25868), please ?
I am ok with this change (note I don't have authority for a r= or sr=) but for what it is worth, I think it is fine to add. I have verified that this latest change works (i.e. doesn't cause problems on AIX or HP-UX) Heck I would approve this just to get Roland to be quiet (just kidding!)
jdunn: Uhm... AFAIK everyone can do r= - but the set of people who can give sr= is restricted.
Build config changes should be reviewed by cls and are exempt from super-review. xpinstall/packager/packages-unix probably also needs to be modified. This won't be approved for 0.9.1 - it's way too late in the 0.9.1 endgame to be turning on modules.
tor: I am definately not shooting against 0.9.1 - this bug is something for 0.9.2 or 0.9.3... :-) There is only one bug left which is still shooting at 0.9.1 (hint hint... :-) ...
Blocks: 83989
r=cls on attach 25868
cls: Thanks !! ---- Can anyone give this patch a= for "trunk", please ?
a=blizzard on behalf of drivers for the trunk
The patch has been checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
cls: 1. THANKS! 2. Just a last question: Is the following warning neccesary: -- snip -- checking for XpGetPrinterList in -lXp... yes configure: warning: Xprint support enabled -- snip -- Xprint isn't that evil... =:-)))
that's what you think; just try making a build with --disable-auto-dep, then make depend in gfx/src/xprint. Then witness the evil of xprint! :p
leaf: More details about your problem would be usefull... Wanna visit bug 87422 and check if this is the problem your're describing here, please ?
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: