A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
1. I am looking to intercept the data going from the POS application to the POS printer. What is the best way to capture this data? Is there one single way that works for all POS Printers based on OPOS, JPOS or standard Windows based drivers? Or is there a different way that works better for each of these POS Printers?
2. What command do the OPOS and JPOS Compliant Applications use to print text output on the printer? PrintLine (or its equivalent) commands or do the PrintBit(or its equivalent) commands? Does the standard enforce this or is it left upto the application developo to choose?
Any help will be deeply appreciated.
There is no one standard way to capture the data. Unless you can alter the POS application code you will basically have to scrape the data by filtering at the interface level. In other words, if it is a serial printer you will need to write a serial port filter driver and monitor the output. This is a really crappy way of capturing data but it is the only way if you don't have access to the code or if you can't reconfigure the application.
You could also write a proxy driver layer that forwards commands on to the appropriate service objects (OPOS or JPOS). The POS application would be configured to talk to your proxy drivers and then your drivers would be configured to talk to the OPOS or JPOS service objects.
As for the methods used to print, most applications will rely solely on printNormal to print text and printBarcode along with printBitmap for barcodes and images.
Saturday, December 27, 2008
Thanks for the info.
Can you please provide more details on both these methods viz. port filter driver and proxy driver layer? I am a beginner in the field, so will helpful if you can point me to any resources that can help me understand these methods better. Would you also recommend one over the other?
For the printNormal command used to print text, where does the font rasterization take place? The POS application host or the printer?
Scraping the port contents is going to be a pain. However, this is a very common approach for third party integration techniques. For example, security systems will often provide a physical hardware device that you plug inline into the serial cable so that it can scrape the data going to the printer and send it to a security system to be overlaid on the video. The same thing can be accomplished in software. The downside of this technique is that you see raw printer data and that data differs by manufacturer. You would need to be aware of which type of printer is plugged in and what the commands are. So your code for an Epson printer will be different than that for an IBM printer. Also, you end up having to write code to support each different interface method (serial, USB, ethernet, parallel).
For the option of writing your own OPOS/JPOS proxy driver the downside is that you have to write a different driver for each interface standard (OPOS vs. JPOS). You also can't easily support Windows printer drivers. For those you have to use a filter driver again so you end up back at option 1 (above). The printNormal command just receives text. The font rasterization is done by the printer.
One other little tidbit that might be of use is that with OPOS and JPOS the drivers typically write directly to the printer in the printer's native command set. This results in very fast printing. With Windows Printer Drivers the data is usually sent to the printer in graphics mode resulting in much slower output.
It would probably help if you told me what you were trying to accomplish. I might be able to steer you in the right direction.
Sunday, December 28, 2008
We are looking to intercept the data going from the POS application to the POS printer. We want to do this without making any code changes to the POS application and with minimal configuration changes (ideally no configuration changes). We want to do this for all or very large percentage of POS applications that are deployed. So if we do it by building OPOS/JPOS proxy driver then we will need to support OPOS, JPOS and also have a solution for POS applications using Windows drivers. If we do it at port interface then we will have to do it for all interfaces serial, parallel and USB. And as you mention support multiple manufactures to get enough coverage.
If we do this by building a proxy driver for OPOS and JPOS only (no support for Windows drivers) then roughly what percentage of POS applications will we be able to cover?
Appreciate your help in steering us in the right direction.
It's hard to say what percentage of POS applications you will be able to cover by going the OPOS/JPOS proxy driver route. What is easier to say is that there are different classifications of applications (targeted at different types of retailers) that use each method. First, let's talk about the methods currently used by most POS applications.
1) Windows printer drivers - mostly used by low-end applications targeting "Mom and Pop" stores.
2) Direct communication or homegrown API (EPOS, etc.) - Used mostly in legacy or middle tier applications. This method consists of writing directly to the serial port or parallel port (USB support is rare).
3) OPOS/JPOS - the method of choice for enterprise POS systems.
What you will see above is that each type of interfacing technique tends to be geared toward a specific tier. So instead of asking how many POS applications you will be able to support using each method; a better question is, what types of retailers can you get by using each method?
If you are looking to sell your product to big retailers (this is the market I currently work for) then going the OPOS/JPOS proxy route is a pretty safe bet. Sure, there will still be some retailers whose POS system can't be supported by this method. But that just goes with the territory.
If you are looking to sell your product to "Mom and Pops" then you will find that scraping the port is probably the best bet. There are hundreds of different POS systems that target this market and they all work differently. The good news is that Epson printers pretty much rule the roost in this market so you could potentially get by with only supporting the Epson ESC-POS (EPOS) command set.
As you can probably tell, scraping the port contents is the most universal way. It requires no modifications to the POS application itself and is potentially the least intrusive. But you are working with raw data and you will need to potentially support both text based and bitmap based commands. You will also have to support Serial, Parallel, and USB port scraping. Ethernet is also available for some printers but is not widely used outside of restaruants. This method is technically challenging and requires that you be able to write Windows device/filter drivers. Also, some printer drivers will use virtual COM port drivers (especially for USB support) which means you will need to support physical as well as virtual ports.
The OPOS/JPOS route is probably the least technically challenging. You can support any interface type (Serial, USB, Ethernet, etc.) with only one set of code (technically, you need two sets of code: OPOS and JPOS). But it requires a configuration change on the POS so that it points to your proxy driver instead of the original manufacturer's driver. Also, the number of different POS applications that support OPOS/JPOS is much smaller. But the number of large retailers using OPOS/JPOS applications is large which corresponds to a much larger number of installed stores. So from a pure sales perspective this method is enticing because you are looking at selling a large number of licenses to a single retailer instead of chasing "onsie twosie" licenses without hundreds of small "Mom and Pops".
Monday, December 29, 2008
Thanks for sharing your insights. Some more follow-up questions:
1. Here is my understanding of the OPOS/JPOS proxy driver. Please let me know if this not correct. The proxy driver exposes an API to the POS application which is same as that exposed by original driver. This is the API defined by OPOS/JPOS standard. The POS application interacts with the proxy driver much the same way as it does with the original driver. Since the APIs of proxy driver and original drivers are identical, the POS application code is not impacted. The proxy driver can then intercept all the function calls by the POS application and then respond to them in a way it chooses to.
2. Can we daisy chain the OPOS/JPOS proxy driver and the original driver? By daisy chaining, I mean that the proxy driver, in response to a the function call made by POS Application, can invoke the same function on the original manufacturer's driver. The API exposed by proxy driver to the original driver is same as that exposed by the POS application and therefore no impact to the original driver code. Is this feasible?
3. For port level scrapping for Epson ESC-POS, is the command set information easily available? We would need this is decode the raw data generated from the scrapping.
4. For port level scrapping, can this be done in a manner that the it does not impact the original driver , if needed? i.e. the scrapping process makes a copy of the raw data while letting the data go to the intended port as well?
5. For port level scrapping, you've mentioned "need to potentially support both text based and bitmap based commands" . Can you please elaborate on that?
6. Is there a single or more prevalent way of this communication for Linux, IBM 4690 and DOS operating system based POS Applications? Would we need separate codes each of the these OSs for port scrapping based solution? I am assuming that OPOS/JPOS proxy driver code should not be much different across the OSs.
See my answers below:
1. Your understanding is correct. The POS application doesn't care what OPOS/JPOS driver (technically called service objects) that it is talking to. So the POS application would be configured to talk to your driver instead of the original printer's driver. Then your driver will take the commands and call the original drivers methods. You are inserting your driver in as a hook to get at the data in a usable form before passing it off to the original driver. So there are now two levels of configuration needed. The POS application needs to be configured to talk to your new proxy driver and your driver needs to be configured to talk to the original driver.
2. Yes, this is what I am talking about with the OPOS/JPOS proxy driver. "Daisy chaining" is probably a better term than "Proxy".
3. Yes, the command set is freely available. You would need to register with the Epson Expert web site to download it. Registration is free. The info is there but the last time I tried to find it I had trouble. It's not intuitive if I remember correctly but hopefully they have remedied that situation.
4. Yes, the port level scraping method can be done using a filter driver such that the original data flow is not interrupted. This is the technique used by applications like portmon from Sysinternals that show you what is going back and forth across the port.
5. Let's look at the scenarios for Epson printers. If you are using OPOS/JPOS/EPOS you are likely sending text data to the printer. This is the native mode that the printer supports and results in the fastest printing speed. So if someone wants to print Hello World they would literally send the string "Hello World\r\n" and it would print. But if you are using Windows Printer Drivers, the driver would send the bitmap equivalent of the phrase. The font rasterization occurs in the driver instead of in the printer. So you would not be able to easily extract the phrase "Hello World" because you would have to opperate on it at the pixel level and wouldn't know what font it was even in. So you would potentially have to either support both methods of operation (graphics vs. text) or just decide to only support text mode printing. Considering that the graphics mode is pretty much only used by low-end POS systems I'm not sure that it would even be worth supporting. But it all depends on your target retailer.
6. The most prevalent way of handling this across OS's is to use a hardware device and plug it inline into the printer cabling. Otherwise, you would need separate code to implement the required filtering for each OS. OPOS only works with Windows while JPOS is cross platform. So if you go with the OPOS/JPOS proxy method you could get some Linux support. I've never worked with IBM 4690 OS but supposedly it supports JPOS as well. With DOS, your only hope is to write a TSR that captures the data and hope that their app will "play nice" with yours. If they install their interrupt handling mechanism in front of yours then you might not get any data at all. Again, I would recommend looking at the retailers you are trying to target. Windows is the most popular OS out there for retailers of all types. DOS is only being used by legacy systems and retailers running it aren't likely to spend much money anyway.
Monday, December 29, 2008
I should also point out that there are other ways to get at the raw data besides writing a filter driver. You could also provide a virtual com port that daisy chains with the standard com port. There are a lot of programs that do this and you could use an OSS one as the basis for your app. One that comes to mind is com0com which redirects data between serial ports.
So the idea would be that your app installs a new virtual serial port, say COM9. The POS application used to talk to a printer on COM3. The POS application configuration is changed so that it now talks to COM9 (your application). Your application is then configured to send the data it receives along to COM3 so that it gets printed.
Again, there are many ways of doing this and all have their own pro's and con's. Some are easier to pull off technically while others are harder but are less intrusive. None are going to be 100% effective for all situations. So you might want to consider supporting multiple options.
Monday, December 29, 2008
This is really very helpful. Some more questions.
1. On the graphics vs. text mode of operations, how do the high-end POS applications print the logo and barcode while printing in the text-mode? Can we intercept the logo and barcode by both the methods we discussed?
2. Is there a reason for POS application, that support graphics based printers, to not support text based printers e.g. through a Generic Text Only Windows driver? I am thinking that if we come across an POS application that does use graphics based printer then can we switch the POS application to print in text only mode (assuming that the application supports both modes)? Does the POS application give-up some functionality by making this switch or is it a printer compatibility issue wherein the printer may not support font rasterization? In case of former, what functionality are we giving-up? Are there any other drawbacks of making this switch?
3. Are there any sources that could give some idea of market share for each of these methods of interacting with the printers? For example, What %age are OPOS/JPOS compliant? What %age use windows drivers in text mode vs. graphics? What is the %age share for each of the hardware interfaces? etc.
Again appreciate your insights on this.
See my answers below. At some point it would probably be beneficial to get on a call together. I'd be happy to make myself available if you think it would help.
1. Printing logos and barcodes is not the same thing as what I call "graphics mode". For graphics mode I really should be calling it "bit-addressable graphics mode". When using that mode the words "Hello World" are sent as a rasterized image. Printing logos uses a different approach. They still send a rasterized image but it is done with a different command. This allows you to intersperse text and logos on the receipt. With pure bit-addressable graphics mode the text and logos are all sent as a stream of graphics.
To print barcodes you typically only send the barcode text along with the type of barcode. So to print a UPC-A barcode with the value "123456789012" you would send ESC commands that are all text that include the UPC-A type and the string "123456789012". No actual graphics commands are sent in that case.
I should also note that there are still a lot of older printers out there that don't support logo/barcode printing or bit-addressable graphics. For printers that do support it you can intercept it using all of the methods we've already discussed. Obviously, it is much easier using the OPOS/JPOS proxy technique for these methods. With port filtering you need to be able to reverse-engineer the binary data.
2. It really depends on what the POS application has been written to support. A well written POS system would be able to support a "text-only" mode such that a generic text printer driver could be used. But there are an awful lot of really lousy POS applications out there. Obviously with a text only printer you can't do barcodes and logos. Some can't do double-high text or many of the other special text emphasis commands that rely on graphics support. But as I said above there are still many old printers out there that don't support this type of stuff so it is up to the POS application developers to decide what they are going to support.
3. Unfortunately there really aren't any good resources on this. And as I've said before the usage statistics are really based partially on the retailer's tier. So there could be significantly more POS terminals installed that are running OPOS, yet fewer overall retailers using it. My guess would be that the options rank this way:
1st - OPOS
2nd - Direct API - POS app writes directly to a port
3rd - Windows printer drivers
4th - JPOS
5th - Other?
We've been talking mostly about printer output. There are other printer functions that you will want to consider the impact of:
a. Slip printing - Document insertion and removal commands use their own command and do not directly correspond to printed output. Not all printers support document/slip printing.
b. Cash drawer support - Most printers have a drawer kick-out connector on them that is driven by printer commands. They can also return drawer status back to the application.
c. Pole display pass through modes - Some printers have a port that allows you to connect a pole display. A command is sent to toggle the output from the receipt to the display so that messages can be shown on the display to the user/customer. You will potentially want to support monitoring this mode change so that you can filter out pole display data.
d. Status commands (in/out) - There are commands that can be sent to trigger status updates back to the application. Also, some printers support "Unsolicited Status Updates" or "Auto Status Back" (ASB) modes where the printer returns data to the application without being asked first. If you are sitting between the printer and the POS app you will want to make sure you pass this data back as well. The main point is that data is bi-directional with printers.
e. MICR Support - Some printers support check MICR reading. There are entire sets of commands for inserting/removing the check as well as reading the MICR.
Again, let me know if you would be interested in having a call.
Tuesday, December 30, 2008
Thanks again for your responses. Yes, having a call is a great idea. However, I will need some time to digest all this information and do some more research before we can have a really productive call. What is the best way to reach you? And what country are you located in?
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz