>The IMB barcode isn't all that different from postnet or planet barcodes. IMB and planet just prepend a few additional fields ahead of the zipcode.
>
>>The main problem is going to be creating the required input and encoding it.
>>
>>They do provide a DLL for the encoding, so you should only need to hook into that for the encoding.

From a content standpoint it's not a huge difference. But once you have your content prepared. It's a major difference.

Typical string to produce a Postnet or Planet barcode:

s511357594618s

String to produce an IMB barcode:

DAFDTDAFFDFTDADTDDFTTFDTATATFFFDFTTFFFTFDDTDAAFATDFTFDFDTTTDTTFDA

With Postnet most CASS software produces the check digit for you, so add the frame bar characters and bingo, you have a barcode. Pretty easy. IMB has to be run through an encoder to produce the bar pattern.

Want to check your program output with Postnet, turn the font off, instant human readable output. Not true with IMB. Even decoding the bar patterns by hand for verification with Postnet is easy. The same cannot be said with IMB. And when barcode failures can cost you 5 cents each, verification is a big issue. A $5,000.00 error on a 100,000 piece mailing is a big deal to me.

And then there is the issue of real estate on the mail piece. The IMB is both wider and taller. That can be a major issue when it comes to pieces like windowed envelopes and small postcards. Those formats are already severly cramped using Postnet, IMB makes the situation even worse.