5

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?

Richard Chambers
  • 16,643
  • 4
  • 81
  • 106
GorillaApe
  • 3,611
  • 10
  • 63
  • 106

1 Answers1

3

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

LtH
  • 692
  • 7
  • 18
  • thanks for replying.. things have changed a bit. However apart from one chinese manufacturer who says that they are compatible with epson OPOS, others told me that there isnt such a thing OPOS and that i am talking nonsense.So you believe that graphics is better for modern printers ? – GorillaApe Jun 27 '12 at 10:32
  • I come from a background working with printers and to hear a manufacturer saying OPOS doesn't exist is just.. mind boggling. Here's some info about the standard it belongs to called UPOS: http://www.nrf-arts.org/content/unified-pos-frequently-asked-questions#WhatAre – LtH Jun 27 '12 at 11:18
  • And as for graphical printing, it all depends on what OS, what ports are available, what will be printed on the receipt, and what your customer wants. Lots of factors there! Some graphical commands are tricky to code when you compare them to just dumping text to the port, but they make your receipts look really sharp as you know. That's the trade off. :) – LtH Jun 27 '12 at 11:19
  • It seems that indeed things have changed. The printers i have dont have Pos for .NET support. All of my printers dont have a POS for .NET driver and only gprinter 80250 claims compatibility with EPSON but i havent tested that,but i doubt whether it is going to work.However almost all have 64bit drivers for windows. Also for barcode scanner Motorola released a new SDK but has only OPOS support but at 64bit even with CCO pos for .net didnt work.Using their ocx and SDK works fine though in 64bit.It seems that support is minimal though,and vendors rely on custom SDKs to do the most of work.. – GorillaApe Jul 01 '12 at 12:21
  • I have seen android sdk etc but i amnot sure whether these devices should print directly and not through a server – GorillaApe Jul 01 '12 at 12:22
  • Yeah, if you want to print from Android (iOS and Blackberry too) you need a 3rd party API since there's no printing system officially included on those OS's. That Star SDK I linked you to supports ethernet, wifi, bluetooth, and USB. Epson's supports ethernet, wifi, and bluetooth. Also, AirPort Express is another option you might consider. In that case, you can turn a USB or ethernet printer into wireless. – LtH Jul 03 '12 at 05:12