Michael Boerner <mboerner at underhilltech.com> wrote: > I am stumped. I have been evaluating XMLMind via the personal > edition and I can not get it to print. I have a default printer under > CUPS but although I don't receive any sort of error the app does not > print anything. The printer is a Laserjet P2015 networked through > its own NIC and the Linux box sees it fine for other applications. > > Suggestions?
Hi, I remember having faced a similar problem some years ago on a similar system (RedHat 9A; if I understand "FD" right to read as "Fedora"): From within all apps except XXE, printing worked fine. Unfortunately, I can't recall how I solved the problem, but maybe the two messages below that were distributed over this list in 2005 can give you some clues: 1) Hussein's answer to my message, dated 2005-11-10. 2) Dominique Lind's solution to his Linux printing problem, dated 2005-11-08. Yves P.S.: Sorry for the mangled indentation. ...................................................................... 1) > Date: 10.10.2005 12:28 > From: Hussein Shafie > Subject: Re: [XXE] Linux: Problem with non-local querying of CUPS printer properties > To: "xmleditor-support at xmlmind.com" <xmleditor-support at xmlmind.com> > [...] > > Yves Forkl wrote: >>> Under Linux, I can't print from XXE at all, and XXE is blocked each time >>> when I try to print. >>> >>> >>> My configuration: >>> >>> XXE V. 2.11 Linux 2.4.20-28.9 (RedHat 9A) Java 1.5.0_02 Gnome >>> 2.2.0 CUPS 1.1.17 >>> >>> >>> Problem description: >>> >>> As soon as I select the "Print..." option from the File menu with >>> any document opened, XXE is completely blocked, while in XXE's >>> parent shell >>> appears a password entry dialog for logging into one of our >>> servers (which I don't have a password for - and shouldn't need >>> to, as I will explain). >>> >>> >>> Findings: >>> >>> I assume it is a CUPS-related problem because I didn't have it in >>> the times when my CUPS was broken, which unfortunately ;-) now >>> works fine. >>> >>> After investigating the issue with our local printing expert, we >>> think having found the following explanation: Obviously XXE tries >>> to build up >>> the list of available printers before showing the Print dialog box. Upon >>> encountering a printer which the local CUPS daemon knows of but which is >>> in the responsibility of a CUPS daemon on a remote machine, XXE (or its >>> "delegate") tries to connect to that CUPS daemon directly in >>> order to retrieve the properties of the concerned printer. In our >>> case, that remote CUPS daemon is run with the option "Require >>> authenticated user" (this is to allow only local users to send >>> print jobs). >>> >>> If the user running XXE cannot be logged in automatically to that >>> remote >>> machine, the password prompt displays, but the user will not be able to >>> log in if he/she has no account there. >>> >>> Suggested solution: >>> >>> 1) Workaround: Make the CUPS Daemon on the remote machine accept access >>> from non-authenticated users as well. This is not always >>> desirable. >>> >>> 2) Real solution: XXE (or its "delegate") should not try to query >>> remote >>> CUPS daemons directly about printers that are assigned to them, >>> but rather restrict its queries for printer properties to the >>> local CUPS daemon, which will then contact the remote CUPS daemon >>> if necessary. Access control is then done on a typically >>> well-established CUPS-to-CUPS >>> basis and does not require the user to log in to the remote >>> machine. >>> >>> What do you think about it? >>> > > XMLmind does not control what happens just before the Print dialog > box is displayed. In Unix, the Print dialog box is a standard > Java[tm] component written by Sun. I don't see how we could solve > this problem. ...................................................................... > 2) > > Date: Tue, 08 Nov 2005 10:08:45 +1100 > From: Dominique Lind <dlind at judcom.nsw.gov.au> > Subject: Re: [XXE] Can't print under linux > To: "xmleditor-support at xmlmind.com" <xmleditor-support at xmlmind.com> > Message-ID: <436FDE7D.6050904 at judcom.nsw.gov.au> > [...] > > Ok figured out the problem. We use CUPS as the printing system on our > linux machines. When we actually had printers manually specified in > /etc/cups/printers.conf then *any* java program had problems > printing. When we removed the printers.conf and made our main CUPS > server advertise its printers then it all worked. > > So in the end it appears to be a problem with java and CUPS rather > than XXE specifically. Thanks for your help. > > Regards, Dominique > > Hussein Shafie wrote: > >>> Dominique Lind wrote: >>>>> Hi, >>>>> >>>>> When I try printing a simple docbook xml file straight from >>>>> XXE it hangs >>>>> and I have to close it. When I run XXE in a terminal I get >>>>> the following >>>>> exception: >>>>> >>>>> Exception in thread "AWT-EventQueue-0" >>>>> java.lang.NullPointerException at >>>>> com.xmlmind.xmledit.gadget.GadgetPrinter.end(GadgetPrinter.java:829) >>>>> at >>>> com.xmlmind.xmleditapp.kit.part.PrintAction.finish(PrintAction.java:205) >>>>> at >>>> com.xmlmind.xmleditapp.kit.CancelableAction.run(CancelableAction.java:68) >>>>> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) >>>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:461) at >>>> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242) >>>>> at >>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) >>>>> at >>>>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) >>>>> at >>>>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) >>>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) >>>>> >>>>> I'm using XXE Professional Edition V3.0 under debian with >>>>> java version 1.5.0_03 Java(TM) 2 Runtime Environment, >>>>> Standard Edition (build 1.5.0_03-b07) Java HotSpot(TM) Client >>>>> VM (build 1.5.0_03-b07, mixed mode) >>>>> >>>>> Is this a problem with XXE or java? >>>>> >>> I don't know. GadgetPrinter.java:829 is located at the very end >>> of the printing process and contains no logic at all. >>> >>> * Does this problem occur with this "simple docbook xml file" or >>> with any other document? If it only occurs with "the simple >>> docbook xml" file, please send me this file. >>> >>> * Does this problem occur with all your printers? >>> >>> * Does this problem occur if you choose "print to file"? >>> >>> * Does this problem occur on other Linux boxes? >>> >>> * Does this problem occur with other versions of Java (e.g. >>> 1.4.1+)? >>> >>> >>> --- PS: You are the first person to report such problem. We have >>> absolutely no problem at all printing on SuSE Linux 9.3/Java >>> 1.5.0_05/XXE V3. We can even say that with Java 1.5.0+, the print >>> output looks very good. > [...]
