I am java / grails developer working on redesigning a software system.
One of the requirements is to have a sever-side application send data to various network printers to print text data.
I searched the web for info on java network printing, and came up short
I looked into Java Print Service API, java.awt.print, javax.print and did not find anything on connecting to network printers.
Is what I am trying to do possible or favorable. The lack of findings leads me to believe that sever-side software does not interact with network printers directly.
If it can be done, please point me to some resources.
Network printers are typically treated no differently from locally connected printers; they are set up in the OS first and this makes them available to the Java Print Service.
If you need to print directly to a POS printer, they usually have their own binary protocol that you can use over TCP/UDP. Epson has the ESC/POS system, for example.
Depending on the print server, you may be able to send PostScript straight to the printer via CUPS/LRP/LPD/IPP. See http://www.cups4j.org and http://lpdspooler.sourceforge.net.
Related
I have written a java application, it works perfectly, however, it requires printer drivers to be installed. From technical side, how much faster will it be sending tasks directly to a printer ( on slow pc's for example), is there any significant difference in speed or maybe some other disadvantages? Here i'm trying to understand if it is worth investing time into this task or keep the strategy with drivers. And i guess this will eliminate cases where there are no drivers available for certain printers on windows 10 for example (just in theory), wouldn't it?
How do you plan to 'send tasks directly to the printer' ? The whole point of the printer driver is that it takes drawing operations from the operating system API and converts that into 'something else' whcih the printer understands.
In general there are about 6 possibilities:
PCL - An HP Page Description Language but many printers can process it natively.
PostScript - an Adobe Page Description Language, fewer printers support it, but its still common
PDF - another different Adobe PageDescription Language with some similarity to PostScript, again fewer printer support it because of ites resource requirements.
XPS - a Microsoft Page Description Language, not widely adopted for a number of reasons.
Basic bitmap - the host operating system renders to a bitmap at the resolution of the device and sends it. Used to be relatively common on low-end printers because its cheap to implement
something else. Some manufacturers, eg Epson, have their own languages.
On a Mac, PDF is the native format, and on a Windows 8 or better PC XPS is the native format. If your printer supports those then you can send a 'task' directly to it, possibly. If your java application isn't creating the content which needs to be printed but is merely a print server or processor, then you could send the data directly to the printer, because you will be receiving it in the printer native format (eg PostScript).
But in general, you need to convert your 'task' into some other page description language that the printer can understand, and send that to the printer.
Thus its not usually possible to print to a printer if you don't have a printer driver for it, because your operating system doesn't know how to create something the printer understands.
I would like my Java application to detect whether the computer is receiving data from a particular website (it could check for incoming data from a list of website I.P addresses I provide, for example). I don't need or care about what are the contents of the data - I only want to know whether the machine is getting data from those websites either by a web browser or some application.
How could I achieve this?
The native PCAP libraries are able to capture and send packets coming across your network interface. I've only ever used it in a C++ context, but a quick Google search tells me that there are Java wrappers around these libraries. (I cannot vouch for the quality of any of these libraries, though.)
I currently have a web app, which allows users to download files to their computers, edit them with their own editors and automatically sends them back to server upon saving and sends some extra data when closing the file. It utilises a Java applet to handle the client side processing which includes
file download,
sending request to lock the file,
opening the file in default desktop app,
watching for changes,
file upload back to server,
sending request to unlock the file upon closing.
Since chrome will stop supporting NPAPI in September, I need to create an alternative while maintaining the funcionality. I wasn't able to find many alternatives. The only thing I found that would be able to achieve at least something is Native Messaging, but still I can't imagine how could I use it to emulate the behavior of the java applet.
So the question is - what are possible alternatives I can use to replace the applet?
Looking at your comments, I'm going to break down your question into 2 basic questions:
How does native messaging work?
How do I download a file and launch it in an application, etc, in a windows application?
Native messaging essentially allows you to launch an application (which must be registered when installed to allow it to work this way) which can communicate with your extension. You can then talk back and forth with your native messaging application from your extension (or from the web page proxying requests through your extension); your messages have to be essentially json formatted (on the javascript side you provide json encodable values and on the executable side you have to read that from stdin and parse it, then write to stdout the result; there are also 2 byte integers preceding each message indicating the length of the message).
basically once you have communications, you just have to make your application be able to respond to a message that tells it to download the file by doing so, etc. This is something you'll have to figure out how to do -- you could do it with a python script, a windows exe, a .net app, or whatever you want that can be executed, but each has advantages and disadvantages.
Hope that helps
I have a generated post script file and want to print using it. How can it be achieved in java either using javax print API or AWT. Is it possible?
Complicated. Does your printer(s) support PostScript? Is it networked? If so, most networked printers can talk LPR and you can shove the file over as-is. On Windows, you could also stream the file as-is to the lpt1: mapped port via something like NET USE LPT1: \\[Computer Name]\Printer /PERSISTENT:YES.
If you're on a server and you do lots of PostScript handling and your printer infrastructure supports it, I would very much look into the LPR protocol. I've written several LPR/LPD management functions in Java to handle printer jobs, so definetely know it can be done with some relative ease.
http://tools.ietf.org/pdf/rfc1179.pdf
I'm researching ways to create a web radio station of sorts. It will have streaming MP3 audio from TV programs for users to listen to. They should have the option of just listening to the stream or pick the shows they'd like to hear and add them to their playlist.
It needs to be usable by folks on mobile devices, so Flash is out for that reason. Also, the admin folks should be able to add programs to the player and maintain the list of available programs.
Are there any existing tools for such an app? We work in a Unix, PHP, Java environment with MySQL and Oracle db. We'll even take a solution that's in ASP.NET! Your assistance is much appreciated. Thanks.
As a server, you might consider using SHOUTcast, by the same folks who've made Winamp. SHOUTcast can stream audio in a number of formats. Or, you can write a web application that dishes content over HTTP with the proper MIME type set.
SHOUTcast - download info # classic.shoutcast.com
To reference content on clients, you should consider using .M3U format for delivery. This allows you to specify a playlist that is application-agnostic.
M3U format # Wikipedia