POS Printer OPOS interface and When to Use It

Question

I am developing a POS system for cafe-bar-restaurants. It works fine, but I have some problems regarding printers. People here suggest I use POS for .NET.

But I can't because:

1. My client has a machine with windows home edition as server. So POS for .NET has no luck at one of his two stores.

2. The previous pos software he had printed to thermal printers using GDI graphics.But was too slow dont know why.. you had to wait for 10 sec to print a receipt.

3. I get complaints because font is a bit small using these printers.(42 chars 80mm paper) And that is true. Native printer's font sucks way too much. All of the printers i see suck because they arent from a good brand.Also guys that developed the fonts were too bored that used latin letters mixed with local ones. But prints from graphics mode look WAY WAY WAY better and antialised and smooth and clear and nearly same speed.

4. Printers dont have OPOS.NET drivers. I sent emails at chinese companies that produce these printers and said that they didnt have developed one yet..

5. Some of these printers dont support some basic ESC/POS commands! Even command for paper feed is problematic. Only the newer printers are almost compatible but the older ones arent at all.

6. Using plain text + esc/pos i cant make the font larger only x times larger.

7. GDI seems to be the most compatible way unluckily

8. Our fiscal device seems to not support sending raw text to printer. It is partly implemented and works only for 32 bit systems as it is for "DOS".. Had no luck installing it. So I had to use graphics. Actually it is a virtual printer. The company that has the fiscal device told me that graphics is the best way to print a thermal receipt and I should not use plain text etc... Also asking them for OPOS drivers for some of their printer told me "what the f* are you talking about?"

So I don't know what to do. I think that I should support 3 ways of printing: POS for .NET / raw text / graphics.

Also, how do you overcome difficulties with thermal printers when sending raw text? Because graphics give you more freedom. Does the fiscal device suck for not supporting text mode?

Answer 1

Comments related to your numbered points:

1. You're right. POS for .NET won't even install on home edition. The officially supported OS's are Windows Embedded for Point of Service , Windows Server 2003 Service Pack 1, Windows Vista Business, Windows Vista Enterprise, Windows XP Service Pack 2. (http://www.microsoft.com/en-us/download/details.aspx?id=5355) Windows 7 also works from my experience. (Of course, you need the .NET framework installed as a prerequisite.)

2. It's probably an interface issue and I'm assuming the interface type is serial since you mentioned DOS. Serial printers take forever to print graphics.

3. Not only is print quality better, but speed increases dramatically if you're using any interface besides serial. Ethernet is the best modern connection type for most kitchens.

4. Any printer manufacturer that doesn't have POS for .NET support (or any other ARTS standard) is cutting corners and you shouldn't do business with them. The price might be cheaper, but part of the reason is they don't provide full solutions. Bad driver/software support, hardware features are lacking... That's when we developers run into these headaches.

5. See #4. But if you're using ESC/POS commands (which is manufacturer-specific), then you're not using POS for .NET.

6. ESC/POS has commands to make text double high and double wide:

   ESC ! n (27,33,n) Change print style:

   n=0 all styles OFF

   n=16 double high print

   n=32 double width print

   n=48 double high & wide print

7. Not necessarily a bad thing; I elaborate more on this below.

8. Echoing my comment for #4... OPOS is an industry standard and has been around since the 90's. If the manufacturer doesn't know what you're talking about when you ask about it, they shouldn't be in the printer business.

I don't see any requirements binding you to using POS for .NET or OPOS based on what you wrote. These standards are great for quick development and supporting lots of printer models at once.

However, if you're using a DOS-based system, you're probably dumping all print data to a COM port. This doesn't mean you need to use a serial printer though. The major players in printer manufacturing offer a virtual serial port. You install a USB/ethernet printer driver (which allows you to print graphics) and then enable the virtual port. Your software sends all the data to COMn (no change). The virtual port "listens" to that COM port, intercepts the commands, and then translates them into what the USB/ethernet printer can understand.

Even if you take this route, print data sent direct to port isn't pretty and customizing it can be troublesome.

The TSP100 is probably what you'd need. It comes with a configuration utility which has both a virtual serial port and a setting to convert device font (the print data being dumped to the COM port) to graphical font of your choice. Check this link out: http://www.futureprnt.com/receipt-redesign-tool/

This question was asked a while back so maybe the requirements changed. Tablets and smart phones are taking the restaurant industry by storm now. In that case, you should definitely investigate Star's SDK for Android and iOS which includes a printing API for these OS's, print samples, and manuals: http://www.starmicronics.com/support/SDKDocumentation.aspx