I'm running out of ideas.
I'm using C by the way via inpout32.dll.
I have these "bytes"(e.g. 0000,00CC) being read from the printer data ports D0-7 or D1-8.
I need to filter out human readable characters when a print job is being done.
This is still very primitive, but I've got a listener function catching these data using inp32.
Basically if I do a print in notepad like 'Hello World', this will be pulled out from the byte being read by inp32 function.
the printer port listener is on a separate app.
the idea is that the app can listen in on any printer.
It's basically a PoC at the moment.
but what I'm using right now to test is a Canon BJC-1000SP, it's pretty old but it's the only parallel port printer we've got at the office. the others are USB types.
I'm using this on Windows at the moment.
Thermal Printers are actually the ones we'll be listening on.
So now I'm trying to use a generic driver that allows raw text file to print.
How can I extract text from it via the port?
If anybody can give me an idea, a function/converter or where to search, that would be great.
If all you read is already human-readable text, just store it all.
If not, you need to think about the character encoding in use. If it's plain old ASCII, you can probably just call isprint() to determine if a byte is a printable character.
The above of course assumes that your printer is talking plain-text, which probably means it has to be a rather old and simplistic printer (like a dot-matrix from ~20 years ago, or so).
If it's a modern "Win-Printer" laser or inkjet, with all the intelligence of page layout being done by the host computer in the driver, you're probably out of luck. In these cases, what is transmitted is the instructions to layout the page, typically in a printer-specific format.
I think you should edit your question and specify exactly what printer you're using, and in which operating system environment you're running your program.
Update: The Canon BJC-1000 printer you're currently using is an inkjet. It very probably relies on the host computer to send it line-by-line (as in ink lines, not text lines) of data to control the various ink nozzles. I don't think it ever sends plain text to the printer. You could investigate by reading through the code of an open source driver. For Linux, the recommended driver is called gutenprint.
Related
I expect it to be possible to simply compose a notepad textfile with text and control chararcters (ESC/POS) and copy that file to an Epson Thermal Receipt printer. Amongst a lot of information that I found on internet, I could not find a sample text file that simply shows how to do such.
I was able to link the USB printer to lpt1 and when I use something like copy /b c:\test.txt lpt1, I get some output. I reached the printer but it doesn't understand the language so to speak.
I did find Epson documentation with the esc codes. It would be of great help if I had a sample text-file and some directions on how to place the control characters in that file.
The Epson information is not a course, it is a manual. That is why I get stuck I guess.
You can see the ESC/POS specifications based on this page.
TOP»POS › TECH.REFERENCE»ESC/POS COMMAND FOR TM PRINTER»Introduction
There is no document compiled in PDF etc., but perhaps it may be available by registering for EPSON's partner program. At least you can ask if it exists.
Epson Advantage Partner Program
LPT devices may also be used for questions like questions, but a more suitable one would be serial port device mode.
If you change the interface setting of the printer hardware from the printer class to the vendor class and install the serial port device driver, you will be able to communicate via the serial port.
Please refer to the user's manual etc.
However, in any case, if there is no paper, the cover is open, or some error has occurred, printing will not be possible.
And you can't know the status just by sending unilaterally on the command line.
In order to deal with such a situation properly, it will be necessary to create a program that communicates with the printer and requests printing, and in that program, monitor the status of the printer and deal with errors.
Is there a simple way to implement communication between two computers running GNUradio using the standard blocks set?
What I am have now is this:
On a Linux computer, GNUradio is running and receiving input from a Radio peripheral. On that computer I can see the received waveform on a WX scope. I can also use sliders and input boxes to change things like the receiver frequency.
What I'd like to do is this:
On a Windows computer, I have the WX scope and sliders. When I move the a slider or change an input box, that data gets sent to the Linux, which is still running the radio receiver on Gnuradio. The received signal goes through a stream back to the windows, and gets displayed on the WX scope on Windows.
Someone elsewhere suggested using the ZMQ blocks, however, when I tried setting up a PUSH/PULL to transmit a sine wave from the Linux to the Windows, nothing went through. The guy who recommended that approach tried the same and also could not get it working, so I think that block might be broken?
So is there any alternative blocks that can do what I'm trying to do? Preferably something well documented, and available on GNUradio-companion.
Depending on the data rate from the receiver, it's possible to encounter performance issues attempting to send raw waveform data using e.g. the UDP blocks, where the sender may print an error similar to the following:
gr::log :WARN: udp_source0 - Too much data; dropping packet.
Because the scope widgets usually only display a portion of the input data, a more ideal way of remotely visualizing the waveform might be to only send the rendered scope widget (e.g. using a remote desktop such as VNC or X2Go). Although this solution reaches beyond your original problem, it is probably easier to use in the long run for cases involving two-way GUI interaction.
For the scope widget data, the UDP sink and source blocks seem to be native to GNU Radio, and are either sufficiently documented solution or simple enough for this problem, again taking firewall configuration into consideration as #Zephyr mentioned.
From GRC, specify in the UDP blocks:
the hostname or IP address of the display computer, and
a choose port number that isn't already in use (and were you using Linux, OS X, or anything UNIX-like, not any port below 1024).
For setting variables over the network, you might try the XMLRPC blocks, as described in another answer. These were recently deprecated, however.
See my other answer for discussion of alternative if performance issues arise.
Both Linux and Windows should have firewalls which might be blocking the connections.
You need to post the error messages displayed in gnuradio-companion.
I'm trying to build a virtual printer.
There are already some answers like this and this.
However my demand is more specific. I just want to create a virtual printer that can be added into the system and can be accessed from any application. On clicking print command, a dialog looks like a real printer pops out and generates a PDF on printing. Then some more actions, like pushing the PDF to my server, are performed.
Do I need to dig into Windows Driver Kit? Or is there any free SDK for this?
Thanks.
Not sure if this question is still relevant to you, but you'd probably want to think about something like this:
Use the WDK (Windows Driver Kit) to create a Unidrv UI plugin. This will allow you to specify UI during the print (for your printer dialogue). The reason why you'd want to show UI here is because it's one of the only printer driver components that runs in the user session (the same process as the printing application). The XPS pipeline and port monitor are both session 0.
If you want to stick to MS convention, you'll do the spool file to PDF conversion in the render filter of the XPS Filter pipeline (this is if you're using an XPSDrv driver). The filter pipeline is where you have the opportunity to modify the XPS spool data coming in and in the final filter, convert it to your output document type (PDF in your case).
To do post print processing, you might want to consider creating a port monitor (again with the WDK) and kicking off a new process to do the post print processing after the port monitor writes out the print output to disk.
Only problem with this approach is that you can't use port monitors in Version 4 drivers (this is the new type of driver in Windows 8). Version 3 drivers still work in Win 8, but I guess they'll be phased out eventually.
Sorry it's probably not very obvious, but as I say, it's a high level overview (and unfortunately driver development is still very complex beyond a simple print to file). Version 4 printer drivers are becoming a lot easier to develop, but unfortunately with the removal of port monitor support and other improvements, it makes it a lot harder to develop anything requiring post processing.
[DISCLAIMER: I'm associated with the Mako SDK R&D team]
I know you asked for a free SDK, unfortunately I don't know of anything that would be suitable, but I know our company offer a Virtual Printer Platform (SDK) which would be good for you (prints to PDF and supports post print processing). You can find more information at the Mako SDK website
Hope this helps a bit anyway. I know printer driver development can be very confusing at times!
After reading up and doing a lot of research, with the aim to setup up something like redmon and use the printer SDK, I have completed the project using this SDK: http://www.novapdf.com/pdf-sdk.html
This solution however will work with windows only.
[I am not affiliated with novaPDF]
I have investigated an OSX version, however this will be a different build, you can probably set something up using this method: http://www.jms1.net/osx-pdf-services.shtml [I have not yet tried this]
I'd like to use port 515 (lpd protocol) to query a printer about its identity, but, unlike some other protocols, lpd does not seem to return any information about the printer when a print request is made. (Judging by the packets captured with Wireshark.) I've looked through Unix's lpinfo, lpadmin, lpstat, etc., as well as RFC 1179 (LPD Protocol) but can't seem to find any commands that will fingerprint the printer over 515 (e.g. "HP2250 LaserJet"). Anyone know how to do this?
LPD makes a huge assumption about the printer with its PostScript roots. It can manage raw print files to any printer (ASCII inclusive), but makes the assumption the the page definition language (e.g. PostScript) will be consumed and rendered by the printer itself. Though queue status information is often available, the rest is not.
This also goes with the history of LPD in that it was not necessarily a printer-level deamon but a server deamon which would then queue/proxy this off to either other LPDs or (line) printers attached locally that would not queue jobs.
Is there something you're trying to accomplish via LPD above and beyond what it is intended?
can you please help me with the following questions...
If I need a virtual printer that will convert a PostScript stream to a different format, do I have to implement a virtual printer from scratch or implement a rendering plug-in?
The rendering plug-in seems to support only certain customizations. Also the data invariably goes to the spooler which is not needed in this case.
If I implement a virtual printer driver does it completely replace the Microsoft PostScript Driver or the Microsoft Universal Driver?
Since my driver is virtual, does it matter if I write a PostScript compliant or a Universal Driver compliant one?
Any other method to convert a printed document to a custom document format apart from implementing a virtual printer driver? Can I hook on as a port monitor or something? From what I could understand I guess not.
What you need is a port monitor. You can create a virtual printer using the Microsoft Postscript driver found in the WDK. You don't need to provide any code for this part, just an INF and PPD file to describe your virtual printer. Once you have that working and installed, users will then see your virtual printer when they print from an app. This printer will produce a stream of Postscript like any standard Postscript printer, which will then be sent to the printer's port monitor.
Now add a port monitor to handle converting the Postscript stream to whatever format you need. Port monitors are considerably easier to deal with than print drivers.
EDIT: Andy points out in the comments that v4 (ie, Win8) print drivers don't support custom port monitors. However, v3 drivers will still work in Win8.
I know this is old, but these answers would have helped me a couple months ago, when I started this project. I spent a lot of time creating a port monitor, only to find a much easier method in the end (see WritePrinter link below).
If I need a virtual printer that will convert a PostScript stream to a
different format, do I have to implement a virtual printer from
scratch or implement a rendering plug-in?
Rendering plug-in is what you want.
The rendering plug-in seems to support only certain customizations.
Correct -- you'll have to decide if it is enough for you.
Also the data invariably goes to the spooler which is not needed in
this case.
This should not be an issue.
If I implement a virtual printer driver does it completely replace the
Microsoft PostScript Driver or the Microsoft Universal Driver?
If you implement a rendering plug-in, it does not replace the PS/Uni drivers. The PS/Uni drivers are in fact used by a huge number (maybe 90%?) of all "printer drivers". OEMs that make printers don't want to write their own drivers, so they use the PS/Uni driver design -- some create UI plug-ins, some rendering plug-ins, some both, some neither.
Since my driver is virtual, does it matter if I write a PostScript
compliant or a Universal Driver compliant one?
It depends what format you want the data in. If you want bitmap format, a Uni driver is better, if you want PostScript format, PS is better. If you want data for each line drawn, text out, and other GDI operations, then either is fine.
Any other method to convert a printed document to a custom document
format apart from implementing a virtual printer driver? Can I hook on
as a port monitor or something? From what I could understand I guess
not.
Most people that want raw access to the PostScript data, usually to use GhostScript to convert to PDF or other format, use a port monitor to do this. For example, the Virtual PDF Printer that Adobe ships with the full version of Acrobat (Writer), uses a port monitor, and also a rendering plug-in and a UI plug-in, for the PSCRIPT5 driver.
The problem with a port monitor is that it doesn't run in the context of the user -- not in the context of the application/process doing the printing. It runs in the context of the print spooler, and requires a lot of hacks to figure out which user/session is doing the printing.
If you want bitmap data, to save as a JPG/BMP/PNG, for example, then just create a rendering plug-in for the universal printer driver and access/save the bitmap data inside IPrintOemUni::FilterGraphics.
If you want PostScript data, to use with GhostScript (or other library, or your own code) to convert to PDF or other formats, then just create a rendering plug-in for the PSCRIPT5 driver and access/save the PS data inside IPrintOemUni2::WritePrinter.
In either case, you want a rendering plug-in. If you want to easily display a UI while printing, and want your code to run in the same context as the user, and not the spooler service, then make sure you set your printer to print directly to printer -- bypass the spooler. If you use AddPrinter to install your printer, you would use the PRINTER_ATTRIBUTE_DIRECT flag.
Not sure I fully understand. You have an app that produces Postscript and you want to convert that to something else? If the application outputs the 'print ready' data then a new printer driver isn't going to help as the 'queue/driver' is just a way to get the data to the printer and not something that is creating the output file.
You might be best to look at something like: Redmon
This can take the output and spawn an new process. The idea would be that you have it output the Postscript to a file and then you launch some console .exe that you create against it.
Just a thought.
Again not sure which way round you are doing this, but ghostscript is the simplest way to convert a PS output into any other format. It's also pretty easy to write your own output format for ghostscript.
This all happens at the app level - no need to write a driver.