Is there any possibility to print document in Linux to standard output, formed for later sending directly to printer's queue and is there any generic format, suitable for all network printers?
Indeed, I do need to do the following process:
1. Print doc to the above mentioned formatted output (or file).
2. Transfer this to the remote device.
3. Send this to the Printer.
Some more details: Document is printed on one hardware Server, being sent to some Device with no printer Driver (so, it Detects printer as a Network device) and then send the Document to queue as a TCP client.
I would recommend that you print to PostScript or PDF. For example, here is a CUPS PDF printer. Another way to do it would be to write your own backend. Here is an example of how to write a CUPS backend in a shell script.
There is no format all printers understand, other than plain text of course. Which has nothing to do with Linux, really. But if you're willing to include some processing in step 3, sure, just write pdf or postscript and send that through the standard printer queue.
is there any generic format, suitable for all network printers?
No. Some printers will understand PostScript, others will understand PCL, and others will require other specific formats. There is no "lingua franca" in the printer world as far as hardware is concerned, which is why you must go through a print manager.
Is there any possibility to print document in Linux to standard output, formed for later sending directly to printer's queue
Since there is no common printing format, you can't make such a document. The simplest thing on Linux is to print either to PostScript or to PDF, and feed that again to CUPS (or any other print manager you use) when you want to output on a specific printer.
Related
The problem
I have a Windows XP pc connected to a printer. This pc runs a piece of software from where i create and send print jobs to the printer. Recently, the printer died and there is no way i can get a new one. The program is configured to print to this specific printer, which is now a problem.
The question
Is there a way to catch the data send to windows print spooler? From what i've found, i have to develop a print monitor (.dll file which will be read by spooler.exe, correct me if i'm wrong), however this seems pretty overcomplicated for such a matter. I've been searching the Print Spooler API, but the GetJob method returns, from what i can see, only informations about the print job, and not the actual data of the print.
I would like to catch this data and then process it in a another program that I will make myself. This is not really the issue, I am more concerned to know if it is possible to catch the data from the print spooler, and if possible some hints to how i could do it.
Thank you.
Your problem is more serious than you might realise. The task of transmitting spooled printer data to a specific printer is calls a Print Processor, which sits in the printer chain preceding the Print Monitor. Documentation here: http://msdn.microsoft.com/en-us/library/windows/hardware/ff551771%28v=vs.85%29.aspx
The spooled data can be in one of several different formats, and for some of them it may not be possible to redirect to a printer of a different type. You didn't mention what types of printers you are dealing with.
This is fairly serious stuff: writing and debugging one of these babies takes significant low level skills and understanding of Windows tech.
Edit: There's a good chance the data is in Enhanced Metafile format, and you need to take advantage of the built-in converters to turn that into commands for your new printer.
I am thinking of implementing a sort of daemon/service in C/C++ for linux, that would communicate with a specific gpib device through shell (using linux-gpib library).
The idea is that the daemon would scan for all existing devices and would create a file/pipe /dev/gpib#-* (where * would be their address on specified gpib bus) for each device. The use would be such as of /dev/com#. I could then type into command-line:
echo "*IDN?" > /dev/gpib1-12
which would send the "*IDN?" string to device 12 on board 1. So far it is a peace of cake...
The problem starts, when I want to retrieve data from the device. I want it to work analogically, so that
cat /dev/gpib1-12
would write out what has the device to say... But I can not know which command, I have sent to the device, would make the device to return a string (value) and which wouldn't. So my options are:
Repeatedly check (while-loop) if the device has anything to reply and send it to the corresponding pipe afterwards.
-or-
Query the device only when the client program attempts to read from the /dev/gpib#-* pipe. This would have to be served through 'signals' and 'waits'.
For obvious reasons (performance and/or latency handicap) I do not want to implement solution 1. I do not know how to do the the other thing though... I feel, that it must be possible to implement on the ol'mighty linux, but how? I did read this and I think that some spin of the function select() is the right way forward, but I can not figure out how to use it for my problem. I also stumbled upon this, where the guy explains how to do something similar, yet sooo different (code mosfet.c).
The question is: how can I immediately detect and react upon an attempt to read from the other side of pipe/FIFO/file via signaling, waiting or interrupts?
Thanx for answers.
PS: It is half past seven in the morning here (yep another sleepless night), so please excuse my broken English...
PPS: Oh yes, and if anyone would already know of such gpib daemon for linux, or if the think I am asking (accessing individual devices through file I/O) would be possible via the linux-gpib library, please let me know. I did read the doc's and src's for linux-gpib, but found nothing helpful. All the linux-gpib library provides are bindings to C, Python, etc.
PPS: Are there maybe other alternatives to using pipes?
If you just need a nice terminal for your gpib device, you can use python (or even better ipython).
linux-gpib comes with python wrappers (for the code look here). so in your shell open python by typing python
In the python interpreter you can easily communicate with the device like this
>>>import Gpib
>>>device = Gpib.Gpib(pad=2)
This opens a connection to the gpib device with the primary address 2. To communicate with it simply do
>>>device.write('*IDN?')
>>>device.read()
'HEWLETT-PACKARD,33120A,0,8.0-5.0-1.0'
To simplify it even further, use ipython instead of plain python. This gives you tab-completion and much more.
How do I most properly use libusb to talk to connected USB devices?
Specifically, how do I transfer data to the USB devices, receive information from the devices, find out the name of the connected device, if they have storage, etc.
More specifically, I will be running this on a Mac OS X machine, so I know I can't just use Windows header files.
If there is a good explanation on libusb and USB devices, that would be helpful too.
Here is a post on a similar question that might be useful to you. I include plenty of links.
But maybe you'd rather see it here. So in that case, here it goes!
Libusb allows you to enumerate devices and select the one you want based on a specific Vendor/Product id (V/P Id). If you don't know this and can't find it online with the product's description then you can easily find it.
If it is not online you will need to use an app similar to lsusb on Linux. (I don't believe it is on Mac.) When you run lsusb it lists connected devices and their V/P Ids. You can easily find your device by unplugging, running lsusb, and plugging the device back in and comparing. It's a piece of cake. Any usb list app on Mac will hopefully display the V/P ID like lsusb does.
Then once you have this V/P ID you will use libusb (if using 0.1) to enumerate all devices and find the device that matches that id. (I support using libusbx which happens to have a single find device function based on V/P id - in fact, libusbx is a whole lot more concise all around.)
After selecting your device you will send a packet using either Feature or Output Reports. This is the most complicated part because the packet you send is dependent on the individual device I believe. It is 8 bytes of data and only one of which is a single character you wish to send to the usb device. (If you wanted to send 8 characters, you would have to loop through an array of chars and send a feature or output report for each character.)
As an example feel free to reference a rather specific terminal example I wrote for controlling two LEDS. If it's helpful, great! It contains a libusbx and libusb-0.1 example.
I hope this helps!
The official site for libusb 1.0 (the newer and recommended version) is https://libusb.info/. The API documentation is at http://api.libusb.info. Click on the Modules section to walk through the different function areas. The source is at https://github.com/libusb/libusb and you can see some working examples at https://github.com/libusb/libusb/tree/master/examples. Hope that helps!
The article from #user2469202 is a good basic intro also.
The process that you can follow is:
Get the VID, PID for the device that you want to communicate using lsusb
Try to open the device and read the device descriptor
If you want name of the device use string descriptor to get that
Check if any kernel driver is attached. If it is, then detach it and do some raw data transfer
After getting the response again re-attach the driver.
I want to know that, is there any way to access the file that is going to print.
Suppose i have a software that has a print button. If i click the print button it will call the printer to print. Can i get the file from printer driver or from any other source during these process.
Regards
Ansif
Programs don't send "files" to a printer. In the case of PostScript and PCL printers, programs send commands to the printer, such as "draw text "foobar" at point (10,23)".
Modern (especially cheaper) printers in the past 17 years or so, are often GDI printers, where programs use Windows' GDI functions to "draw" the printed page to a raster buffer which is then sent to the printer, which makes the printers cheaper as they don't need a command interpreter and processor built-in.
So to answer your question, "no", you cannot access files that are going to print, because they don't exist.
I have a feature request on a project I work on, it is to integrate with a Paylife CC handheld, which has a USB connector to connect with the computer. I have the docs, and am reading up on it.
When I searched on google how to read/write to a usb device on linux, it said, use libusb.
I was wondering, is there another possibility? Can't I just open it like a file and write a stream to it, and read a stream from it?
I don't actually need to do anything fancy. I just need to write a string of control codes to the device, and it would be mildly nice to read back the ACK and Error codes. But since those are already displayed on the device screen, I don't have to do much with it, just deliver the total required for payment.
So my question is, what are my options?
The connected computer is a regular ol ubuntu linux box.
It is definitely possible when the device complies with one of the USB device classes -- drivers for them are universal.
If that's not the case, then you may stick with a manufacturer-provided or a third-party driver, given there is one and you possess enough of it's documentation.
If that's also not the case, libusb-1.0 is your resort, unless you want to write a kernel driver youself :)