* The Business of Software

A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

We're closed, folks!


» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)


Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

OPOS Printers

Hi - I'm new to using POS printers, hopefully someone will have some insight.

I have a quick turn around time for a touchscreen food ordering system that needs to print to two POS printers (one for the customer, one to the kitchen).  I'm just performing the printer integration.

I've been told that, most likely, Epson POS printers will be used.  And I'm being pushed to use a product like NiceLabel (http://www.nicelabel.com) to design the receipts.  Now I know that the nicelabel product is not meant for POS application, but my boss thinks it will provide for a quick turn-around.

Has anyone used a product like NiceLabel for a POS application?  I will need to use the Epson Windows driver to integrate with NiceLabel.

I appreciate any recommendations.
cheers - Jay
jason bruns Send private email
Wednesday, July 02, 2008
I have a lot of experience with OPOS/JavaPOS/POS for .NET.

First off, you are lucky that you are using Epson printers. In my opinion they are the best in the business from a developer's perspective. Their drivers are solid and readily available.

You can not use OPOS and the Epson Windows Printer Driver (WPD) at the same time. They are two different beasts. OPOS will give you the option of printing to the printer in its native line mode. You can send a command like "printLine" (not the actual command but I changed the name to give you the basic idea) and it will print a single line of text to the printer. This is the native mode for the printer and will be very fast.

If you use the WPD the printer will revert to graphics mode which is significantly slower. We have an old legacy POS system that uses the WPD to print receipts and it is a real dog! There is no reason to print receipts in graphics mode when most of what you are printing is text.

Using OPOS gives you access to the status values from the printer. You can tell when you've run out of paper or if the lid is open. If your printer supports it you can also print to a slip or read checks. You can't do these things with the WPF. Also, it is harder to do simple things like selectively pop the cash drawer when using the WPD because it doesn't have separate commands for this. You have to configure a special escape code in the Windows Printer Control Panel. This means that the value is constant and is always performed for each receipt printed which is not always what is needed on a POS system.

I've never used NiceLabel. What is the point of using that product? Does it provide the ability to do more than print barcodes? If not, ditch it. You can print barcodes from OPOS.

Bottom line, stay away from using the WPD unless you absolutely have to. OPOS has its own little set of quirks but it is an industry standard and will allow you to use other brands of printers in the future without having to rewrite you entire app.

And if you are writing your product in .NET, use the POS for .NET library available from the Microsoft WEPOS team instead of OPOS. It supports OPOS as well as the new POS for .NET standard.
dood mcdoogle
Thursday, July 03, 2008
dood - thanks for the advice.  Just FYI - I have no need to perform any operations other than printing, so no interface with a cash register, or any other POS device.

NiceLabel is a third party app that is normally used to print labels, for various uses, but looks to be mainly for warehouse management.  You can design fixed-size labels (usually stickers that you'll put on your boxes to inventory and organize your warehouse).

The powers-that-be have suggested NiceLabel so someone besides a programmer can change the look of a reciept, since it has a WYSIWYG interface for designing the look.  Also, you can make placeholders in the label for grabbing text from a comma-delimited file to fill in the placeholders.  Also has a service running in the background that monitors a directory for new comma-delimited files, and when one is detected, a new print job is initiated.

It looks like overkill to me.  I've read all about POS for .NET, installed it, and played around with the samples.  I was set to go with it, until the boss told me they really want to use a third party app to speed up development.  Since I've never developed a POS application, I am not certain of the development time, but my gut tells me that OPOS is the way to go.  I just don't know how to convince the powers-that-be - they seem to be set on the NiceLabel idea.  And, of course, I'm waiting for an Epson printer that is on order, so nothing to perform testing on at this time.  I am quite worried about the lag time using the Windows driver, and performing the creation of the comma delimited file, that will be coming to me as an XML file.

Any other thought on this topic?
Thanks for all advice!

Thursday, July 03, 2008

If you ever do want to add support for other devices (line displays, pinpads, signature capture, coin dispensers, and on and on) then the way to go would be OPOS/POS for .NET. If you already have basic OPOS support for one device then adding another device is trivial. But if you go down the WPD route and suddenly need support for other devices then you will be starting from scratch.

It wouldn't be the first time that management has decided that they want the user to be able to use some sort of receipt/report generator to tweak things themselves. The reality is that they never do and you spend countless hours supporting something that never gets used. Instead, you should focus on providing a solid interface for your devices which ends up being the typical "Achilles heel" of a POS system. The time you save will easy cover any customizations that the user might want to do and you could provide these customizations free of charge and still save tons of money in the long run. I've seen it so many times before that is isn't even funny. But it is really hard to convince management of this because they want to try and prevent the need for programming at all costs. Even if those costs are ultimately much higher than it would have been to just use a programmer for the task instead.

Finally, I don't want to imply that OPOS is all wine and roses either. You don't get something for nothing. OPOS was designed to give a consistent programming interface to all types of devices. This means that programming with OPOS is very easy which greatly reduces your development costs. But it comes at the expense of installation/configuration costs to the user. You need to install each vendor's OPOS drivers and each vendor has its own nuances to installing and configuring devices. This can be a real headache. But if you are dealing with just one vendor (Epson) then you are in good shape. Epson does a really good job with their drivers. But if you ever wanted to go to another vendor (say IBM for example) then you could do that by simply installing their drivers (and probably making very minor tweaks to your code). But if you go the WPD way you will likely be restricting your peripheral choices. For example, I don't think that IBM even provides a WPD for their printers.

Good luck.
dood mcdoogle
Thursday, July 03, 2008
Hi dood,

I'm at the stage of implementing POS equipment (well a receipt printer to start with) and have installed WEPOS and all looks good BUT I realy don't know where to start.

Do you know any web locations where I can follow a simple step by step guide as to implementing it.

The SDK is way to in-depth for a beginner and I just hate forking out money for a book that will be read once and then sit on the shelf gathering dust.

glen harvy Send private email
Thursday, July 03, 2008
Glen. Start with the UnifiedPOS programming guide available at the ARTS site. It covers OPOS, JavaPOS, and POS for .NET since they are all related and have the same API's. Unfortunately, you will still have to learn a lot of this stuff on your own. There aren't any good web sites or books that discuss it because it is too specialized. I wonder how many copies I could sell if I wrote a book?  ;)

Anyway, get the latest version of the spec here:


Epson has their own supplemental programming guide at the Epson Expert web site. You will have to register for free to log in and get it.
dood mcdoogle
Thursday, July 03, 2008
Thanks dood,

I joined Epson and downlaoded their real-world samples and am progressing rapidly from there.

This is NOT the place I guess to go into detail but I assume the following:

1. The WEPOS software is distributed and installed by my installer on the Client machine - probably silently.
glen harvy Send private email
Thursday, July 03, 2008
2. woops...
2a. My program (if necessary) scans the machine for devices and installs them in WEPOS.
3. I then use the devices in WEPOS to (in my case) print to.

Makes sense but my biggest problem is I don't have any of the hardware to test it all with. I am using the test software that comes with WEPOS and am initially very impressed.

Anyhow - I drift (off-topic) and thank you again for your input.
glen harvy Send private email
Thursday, July 03, 2008
"1. The WEPOS software is distributed and installed by my installer on the Client machine - probably silently.
2. glen harvy 
Thursday, July 03, 2008  Deleting … Approving …
2. woops...
2a. My program (if necessary) scans the machine for devices and installs them in WEPOS.
3. I then use the devices in WEPOS to (in my case) print to."


1. Yes. Or you can just tell the user to download and install it. It depends on the app. In my world we deal with enterprises who burn in their own machines. They install it themselves at our direction.

2. Yes. But if you already know the name of the device you want to use you don't have to "scan". You just open it directly. There are multiple ways to do this. Again, in my world the enterprise configures the devices and then sets a configuration value in our software telling us the name of the printer device. We don't scan looking for all printers and then give them a choice. They tell us what they've configured the device to be. If we attempt to open/claim it and there is no device of that name then we show them a configuration error.

3. Yes.
dood mcdoogle
Friday, July 04, 2008
Hi dood,

Thanks for the info. Where I was having problems was understanding what WEPOS is - it's the whole darn OS. Once I realised that, the "POS for .Net" interface clicked into place.
My client installs "POS for .Net" on their computer and I interface that - the Chanel9 video helped most of all, plus the Epson demo's etc.
Is it really that easy to use POS peripherals!!
Thanks for your guidance.
Now all I need is to find a support group or similar so I can discover all the pitfalls.

Cheers and thanks again.
glen harvy Send private email
Friday, July 04, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz