We've had some recent inquiries about integrating more advanced bar code capabilities into A-Shell. For simpler bar codes, like 3 of 9 (see Printing Bar Codes for a discussion of that one), you can just obtain the font and output with it nearly as you would for any other font.

But for some of the more advanced bar codes, like UPC and EAN which include graphics and text in such a way that is incompatible with the one-to-one relationship required for normal font translations, some kind of "encoding" operation is required. Here's an example of EAN13:



And here's a 2D code (PDF417):


It is possible to study the specs for these bar codes and then just generate them with raw Basic code using the //GDI primitive drawing functions, but that's probably more work than anyone really wants to do. The best alternative that we've been able to find online is a set of libraries and fonts that can be licensed from a company called ID Automation (here's their product matrix: http://www.idautomation.com/sitemap/ )

So the question is whether it would be worthwhile for us to license one or more of their bar codes and integrate it into the A-Shell/Windows GDI printing subsystems, probably via a new //BARCODE command, so that you could include them in your applications. Obviously there would be costs involved, and decisions to make about which fonts to implement.

I know that many of you have already gone through this process and have come up with other solutions. What I don't know is whether there is a present or future need to implement newer/more-complicated bar codes for which a centralized/integrated solution would be more advantageous than everybody finding independent solutions.

I don't know of a current need for this, but certainly could see it in the future.

We do use bar codes of different flavors, many we let the 'barcode printers' do all the work, others we have used something like Print Wizard that sits between Ashell and the printer and turns simple commands into barcodes. Most of our reports and printouts are using PCL etc, so has always been an issue using or moving towards the GDI.

Anyway, still sounds useful, but dont know when, it could be tomorrow a customer phones up regarding barcoding, or could be in a year or so time.

It would be a good "add-on". And i dont think it would be a problem passing the cost of this to the customers who need this capability down the road. (if it were to be a license/add on package)

Note that the post office DPBC Delivery Point bar code is already done using GDI commands. The routine is in the shared source.

There are also routines to implement the new IMBC Intelligent Mail Bar Code which was to become the new post office standard.

Most of the other bar codes like 3 of 9 and OCR are available for free. I have copies of these.

Just sayin.

Good point. Joe and I put fair amount of work into implementing the new US Post Office bar code earlier this year. Similarly to the other fancy ones (like EAN13), it requires converting the original source text into a special coded string which can then be output as a bar code. (The Post Office supplied the conversion routine code, and I integrated it into A-Shell as USPSBS.SBR.)

But in this case, rather than using a special font, Joe wrote a routine in Basic to render the coded string as a bar code using GDI commands.

The sample program is in the SOSLIB in the [908,52] directory and can be downloaded here:
USPSGDI.BP

And here's a sample of the what the bar code looks like:



Theoretically, a similar approach could be taken for EAN13 and even the 2D codes, but the task would be complicated by the relative lack of public resources (specifications, code, etc.) compared to what the Post Office made available. But, if you're looking for a challenge, I have it on good authority that Jorge would be willing to pay a few hundred dollars for an implementation of EAN13. (Let one of us know if you're interested, before we go head and purchase/implement a commercial version.)

I looked at the EAN13 specification and it looks very much like what I did for the postal bar-code. It shouldn't be too hard to convert that routine to do what you want Jorge. Send me an email with some details on what you are doing and I will see what I can do. I can probably do it next week.

A link to what I found is.......

http://barcode-coder.com/en/ean-13-specification-102.html

Thank you Joe, e-mail sent already...

It really wasn't that difficult. Most of the work was already done in the DPBC barcode routine I had written. I just printed a bar code that looks good. I will clean up the program and document it and send it to you Monday sometime. Then we can talk about customizing it for what you need to do.

Jack will post an EAN13 in the shared source if anyone wants it. It will take the source UPC code and output the EAN 13 bar code using GDI commands. It can probably be easily converted to do other UPC bar codes as well.

A quick look at the 2d PDF417 bar code tells me that could be programmed using GDI as well. It thinks in clusters instead of bars and handles all of the ascii characters but its the same concept. If anyone has an immediate need for this let me know. We would need to find a detailed spec on it but it must be out there somewhere.

Here is a perfect EAN13 sample, 100% produced by the program that Joe wrote, excellent work.



I'm going to convert the program into an SBX and Function, afterwhat, I believe will become public with Joe's agreement.

Many thanks Joe.

Please add the program to the shared source for ashell users.

That's exactly what I'm going to do after Jorge sends me his function and I give it an editorial once-over.

Question(s) from the newbie.
I am coming from not even able to spell "BAR CODE",
I cut and pasted from above to get the spelling correct.

I want to print my inventory stock number tags with bar codes. They are a simple 6 digit number, but I am thinking that I should keep the option open
to read the UPC code from the item as well. Then have a double key index to the data file, for "my stock numbers" as well as the UPC.

How do I decide what bar code to use?
How do I know what scanners will read the code?
Does "any/all" scanners read any barcode?


Thanks, Gary

Hi Gary,
For internal use, my suggestion goes for Code39 barcodes because you can use it as a normal text print and just setting the font to any of the thousands free Code39 fonts you can find on the web (if not, I can send it to you).
Besides you mentioned that you use just six digits, Code39 allow you to mix letters and numbers; the unique detail you must be aware is to prefix and suffix your code code with "*" (asteriscs), an example for the code "123456" is:
//setfont, 90, 3of9, 0, 0, 400
//textout,100,100,*123456*

Hope this helps


P.S. note that "3of9" is just an example of font name I use

Joe, do you have this already adjusted for EAN128 or, would it take too long to do it ?

Jorge, I have a 128a, 128b, and 128c freebie. I'm not sure if this qualifies as EAN128, but you are welcome to it and the code to calculate the check digit, etc. I use 128b because it allows upper and lower case, numeric, and special characters.

Hi Herman, thanks for the offer but, do you build the barcode itself ready to print or just calculate the check-digit? If I remember from a previous post, you mentioned something about you're using the barcode font built in the Lexmark printer, or am I confusing things?
Joe wrote a great routine that handles everything to print a very well formed EAN13 barcode and I would love to have the same adjusted to EAN128.

We are getting away from the barcode font loaded in the printer so ehat I am talking about is not that. This is one I use with GDI printing and is simply a Windows font. I just googled EAN128 and what I have probably is not what you need, but you or anyone else is welcome to it. With this font I have to add a start digit, checksum digit, and ending digit and then print it using textrectangle.

EAN128 looks like a version of EAN13. I think the SOSLIB program can be changed for that. Let me take a look at it and get back to you.

Thank you very much Joe, I really appreciate if you do that adjustment because I tried to do it by myself but I just don't know where to start and, worst, didn't trust in what I was doing.

No problem. The first step is learning the specification. The place we used for EAN13 has the rules for EAN128 also. I think that this is the guideline I will use...

http://www.barcodeisland.com/uccean128.phtml

Check your email for EAN128. You'll need to do some testing but the bar code produced looks like the sample. I don't have a reader to try it.

I found this site which explains the details of many popular bar codes.

http://www.barcodeisland.com/symbolgy.phtml

You are the Bar Code Maestro!

Thanks for sharing your expertise. After Jorge gets a chance to verify that it meets the spec, I'll make sure it gets into the updated SOSLIB.