This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I'm writing an application that uses java printing (java.awt.print.) and I'm getting quirky behavior. When I call PrinterJob.print, I can see that my job is sent to the printer since the printer icon appears on my desktop, but the printer doesn't start printing until I turn off the computer and restart it. By the way, I'm running Fedora Core 5 with Turboprint, but other applications print just fine.
Is that mandatory to use CUPS .. I mean i am printing my datas using java in Unix server. But i find my printer printing only Junk characters . I used the lpr command and printed a document. It works fine but when i call the printer API through my Java code and run it , it does not work neither it shows any exception. i can find my datas are stored temporarily in a location with .ps extension . I am using EPSON LQ-690 printer . Also found out that DataType of the file is shown as RAW whereas when i use lpr to print , it shows as TEXT . So how could i get my datas printed. I went through CUPS and GhostScript sites but i need to know what's the reason for this and how i could overcome this issue.
"Learning is a Culture where your Eagerness & Curiosity plays a major Role".
Unix/Linux doesn't need to use a print daemon, however, since they are both designed as multi-user systems, use of a central spooler helps keep everything tidy and manageable.
Conventionally, printing in *n*x is done as either plain text or PostScript and sent to the printing subsystem (cups or lpd). The output is spooled, then, when an eligible printer becomes free, the printer driver will translate the portable format data in the spool into whatever sequences are required to print on the printer, based on how that printer was defined to the printing subsystem.
You can also output printer data in brute-force format such as PCL4, although this is something you'd normally only want to do if you need to exploit a particular hardware feature.
Possible trouble spots are cases where the translation occurs either too many times or not enough times. A bug in CUPS releases a couple of years ago wrecked my printing for the entire month of August because my desktop was rendering output in Postscript, forwarding it to the main CUPS server, which rendered the PostScript in PostScript, and the resulting output was a PostScript program listing instead of the desired results.