Hi all, These 2 questions were sent out at about the same time so I though I would address the summary en-masse to keep email traffic down a bit. The original (unabridged) postings are at the bottom of this email. My questions were (paraphrased / concisified): Netscape 4.77: Crashes / closes with (or without) "Bus Error" ; often @ same time as a window-closing. Seems to happen more often with users who do lots of Java-content-page work. Acrobat Reader: Some print jobs cannot print, even though the same PDF can print to the same printer from Acrobat for Windows. Many thanks to all those who replied; too many to list! It appears that I've touched a bit of a nerve with these queries :-) ANSWERS WERE: Netscape: ========= -Alas, these problems are seen by many people elsewhere. Disabling Java and JavaScript is suggested as the best way to reduce instability of Netscape. -Overall, Netscape is criticized by many as being "poorly developed software, especially for unix platforms". Mozilla is felt to be no better (yet) although possibly by Christmas it may be more robust. Then again, maybe santa will show up (for real :-) -As a (relevant, IMHO) aside: I was informed that Opera 5.0b1 for sparc-solaris 8 is now out. I did download this and it seems to work *very* well for "beta" release software. Alas no Java support yet (hopefully this comes with the full release?). For anyone who is vaguely interested, it is a worthwhile ~1.5 meg download IMHO. -I was reminded that IE has been on the scene since IE4 days (although I still suspect IE5 has a different code base completely :-). Alas for my purposes, Java support in IE5 isn't as painless as needed for use here (yet). Hopefully it will improve, although I'm not sure the memory usage of IE5 is quite to my liking (a single instance eats ~25 megs ram when sitting idle; significantly more than netscape.) Given that all of our intranet web pages make extensive use of Java Applets and JavaScript, we cannot make the single most important change to make netscape more stable. Sigh. Acrobat Reader: =============== -These printing problems have been observed by many others as well. -Some suggestions that it is an interaction with how postscript is rendered, fonts required and slight differences in how unix, windows do these tasks. (hence difference between windows acrobat being able to print something where unix acrobat fails). -Suggestions were made to dump the problem PDF file to a postscript file, then use postscript viewing software (ghostscript, etc) to see what *really* is going on. [ie, as a means to diagnose "skanky PDFs".] Excellent suggestion, and one that I will use for examining problem PDFs in the future. -From Ray McCaffity, the following suggestion was made: -edit the file, /etc/magic , and add the following line to the section where a few other similar lines can be found: 0 string %PDF-1.3 Adobe Portable Document Format (PDF) v1.3 This change was made, and it *was* then possible to print one of the "trouble" PDFs which previously couldn't be printed from Unix-AcrobatReader to the HP4050 postscript printer. Huzzah! So. Some joy on this, although the concensus with Netscape is pretty grim right now. I share the opinion with many others who responded that the WWW-browser situation for Solaris *really* needs to improve if Solaris is to be taken as a serious contender for a "desktop OS" (as implied by the SunBlade 100 workstation, among other things). **MANY** thanks to everyone again for their help with this. It certainly is greatly appreciated. -Tim Chipman -=-=-=-=Original Questions=-=-=-=-=-=-=-= Hi all, The first of two "simple but annoying" questions I have today: Running Acrobat Reader 4.05 (the latest version for solaris at the present, it seems) on Sparc Solaris 2.6 systems, we have periodic problems printing PDF files. i.e., 95% of the time, PDF files can be printed without any difficulty (to, say, an HP4050 with 16 megs ram and of course full postscript support). The remaining 5% of the time, we have "problem PDFs" which simply get hung in the print queue ; the printer generates a message indefinitely, "Processing job..." and never stops. All print jobs get backlogged on this printer, and the only way to clear the problem is to delete the offending file from /var/spool/print, then power-cycle the printer once or twice -- and other print jobs can then be printed. We can *never* print the such a "problem" PDF from solaris even after "flushing" things thus. Even more frustrating: We can open these "Problem" PDFs on Acrobat 4.0, 4.05, or 5.0 on WinNT4, Win2000 workstations on the same network, print to the *same* printer -- and there is *absolutely no problem* (the document prints perfectly well). In these cases we are even using a Sparc box running Samba as the "windows print server" (although printing is really being done via LPR). SO: I suspect there is "some issue" with how acrobat reader for unix is working with these PDF files, but I'm not clear if anything can be done. Possibly related: I've installed Xpdf (latest version, 0.92) on one sparc-sol-2.6 box where we observe the problem ; then opened a "problem" PDF file and was interested to note output thus to the console: Error: Kid object (page 5) is wrong type (null) Error: Page count in top-level pages object is incorrect Error: Couldn't read page catalog -- so -- it appears that this particular PDF isn't openable by Xpdf (nothing is displayed) [even though we can open it with Acrobat 4.05 under unix, and can print it from acrobat under windows]. It seems possible, then, that some PDF files are mal-formed or "sloppily generated" and it may be these files that create issues under the solaris version of acrobat reader *only* ?? ... and that xpdf is giving me a hint to this (?) Anyhow. Ultimately, what I am asking: -> Has anyone else ever observed "these sorts of printing problems" with acrobat reader on solaris boxes? -> Even better: Has anyone ever heard of a way to fix this sort of problem .. other than telling our folks to only print PDFs from a MS_Windows environment ... ? Any comments are *very* much appreciated at this point. ===netscape question=== Hi all, The second of two "simple but annoying" questions I have today: We are running Netscape 4.77 (the latest version available I believe in this "lineage") on a number of Sparc-Solaris 2.6 systems. We observe "significantly frequent" instability problems with netscape that are happening often enough to make this a big headache for me and all my users here. Problems are exhibited thus: -> Netscape (communicator, messenger -- all associated windows) closes abruptly without warning, and returns the error on console thus: [1] Bus Error netscape -> In a different manner: When *closing* a single window (be it one communicator window of many, a messenger window, whatever..) by clicking the upper-left-hand-corner and choosing "Close" (last item in the menu, generated by CDE) -- the entire netscape session disappears, closing all netscape windows and quitting the application. No error message is returned in this case. This sort of thing appears to happen "more often" for our users who make frequent use of Java Applets (developed in house) that do use up a bit of memory. However, even users who rarely (never) use the java applets from our internal web sites still experience this problem (occasionaly - albeit less frequently). I've investigated the possibility of using IE5 for solaris (boy, was I suprised when I learned they actually released this a while ago .. must be a port from the Mac-OS-X version :-) -- but alas, the integration of java features isn't yet "up to spec" for our purposes. Likewise, I've investigated Netscape-6 lineage netscape, but have been disappointed with (1) its java behaviour and (2) the requirement for Solaris-8 to run it. Hence, I am not keen with trying to use the "newest & best" netscape incarnation as our workaround. >From seaching google, the net, and Sun, I've found reference to various x-font-patch related issues that may have been involved in netscape stability. Alas, our systems in question already have these patches up-to-spec, so I cannot turn here to point the blame. Finally: We also have done "controlled testing" - and windows workstations running either netscape 4.7 or IE5.5 are able to browse our web site, access our java applets .. all day long .. with lots of use .. and there is no crashing behaviour (hence, leading me to suspect it is not "profoundly malformed java applets" causing the problem). SO: The big questions again come down to: -> Has anyone ever seen this sort of crashing behaviour ? -> Does anyone have any ideas on workarounds that will help resolve the situation? ===end of this too-long-message :-)===Received on Thu Jun 28 16:24:54 2001
This archive was generated by hypermail 2.1.8 : Wed Mar 23 2016 - 16:24:58 EDT