LiveCode Forums.

Hi,
I’m at the point in a project were I need to finish incorporating the use of barcodes. I have the script pretty much in place I just have some basic “using barcode” questions. I have done some research but it hasn’t gotten me all the info I need. The app will be for Mac/Win so I need the font to work on both machines.

Some of the barcodes I was planning to take from the code that comes on the purchased items. Is this a good approach or should I generate an in-house barcode for every item?

I’m planning to generate in-house barcodes for work orders, sales receipts and so on. Then I was planning to have a start character in the code to identify the use. Am I thinking right, is this the way it’s supposed to work?

From what I’ve read on the forum it seems that 3-9 is easier to work with than 128.
Can someone please explain the reasons why? Are there any advantages to one over the other?
What is the length of the encoded data on a 128 and 3-9 barcode, are they both the same number of characters?

I have a code 128 font but so far all of the free code 3-9 fonts I have downloaded have generated errors when I install them into the font book on my Mac.
Does anybody know where to get a clean code 3-9 font?
Are the free fonts as good as the purchasable ones?

Howdy, Tom, let's get you started.

1) re: the items you are purchasing: If you are referring to store-bought, then they are encoded with UPC (or EAN if you're not in the US)-symbology codes, not Code 39/93/128/etc. UPC CAN be tricky, because seemingly similar/identical items can and/or will have different codes from different retailers. Sometimes the codes are the same, and sometimes they are not. So, yes, you can use the existing UPC codes, but you have no control over them, or when or if they may ever change, so you will have to either work out a deal with the retailer to have access to their database of item numbers (good luck), or you will have to be prepared to have your users update your internal db if and when the retailer/code changes. Using the existing UPC codes gives you a 90% solution.

2) You can also use UPC to generate your own labels: scan the upc code, auto-generate your internal labels, apply those to the items. There are two reasons for doing this:

• Generate 3 labels per container and put them on multiple faces (usually on ajacent faces at the same corner, so that you aren't flipping the container around over and over to find the label to scan it
• When you run into a UPC code problem, it is easy to overcome using your own internal labels

3) 39 is more widely used than 128 because it is older, and it is less dense, so it is more forgiving of abuse. I am seeing some customers switching to 93 (updated 39), but most have settled on 39 and are not switching, just because they don't have to, and have had good results with it. Other requirements are that labels be printed with a thermal-transfer printer to get higher contrast and higher durability, although I have to tell you, for our internal use, we laserprint on regular paper, and scan just fine using just the camera in an ipod touch. You can also purchase mini laser scanners that attach to mobiles. Attached to our warehouse PC's and macs we just have ccd's. They have been plenty fast enough, although they do not scan at a distance.

4) The original code 39 can only encode 43 characters: 0-9, A-Z, and a few punctuation symbols. In applications where more characters are needed, lowercase and others are represented using two characters, but generally those will not be required because all you're using the barcode for is an internal container number or an internal item number.

5) Barcode width will depend on numerous factors including the density at which you choose to print it (which depends on what you're using to print the label), how many characters you are printing, and the symbology. Again, 128 will be denser, 39 will be more forgiving.

6) The other thing that we have chosen to do, because it only adds one additional character, and it ensures that we get good scans every time, is add a checksum. These are supported by the symbologies and only add one extra character. None of our customers use checksums, but all of our customers require lots of other things in the labeling.

7) I have never found a real difference between a paid and a free barcode font, and we have had both. I get errors from fontBook from a variety of fonts, but they work just fine.

Hi Mikey and thank you for the reply.

OK, I’ll stick with 39.

1) I see, scan the barcode off the purchased item and do a little processing to add a start and stop char. The stop char should probably always be the same but I can have the start char be something different and then have LC intemperate the start char to determine what to do with the scan data. Or maybe, I’m thinking, the stop char is the one that should be used to intemperate what to do.

3) You said you’re scanning with an iPod touch. How are you connecting the iPod to the Mac/PC? And, please excuse my ignorance, but by ccd do you mean there is a USB scanner attached to your Mac/Pc?

4) Check.

5) I was thinking that the data part of the code had to be like 14 chars long. So , you’re saying I can have a barcode that has a start char, data char and a stop char? Like this !9%

6) Could you please explain more about setting up the checksum? Is there additional code that needs to be written to handle this or is it interpreted by the scanner or is that when you mean by “These are supported by the symbologies”? Either way it sounds like a very good habit to get into.

7) Check. I loaded this font and it installed without errors.
http://download.cnet.com/Free-TrueType- ... 67143.html

Tom,
1) I'm not sure what you are using to read the barcodes, but if you can, you can limit the symbologies that the scanner will scan, and some can also tell you the symbology of the barcode you just scanned. So, if you limit your scanner to reading UPC and 39, then when you get a scan returned by your scanner, if it is in UPC, you know that it's from the store, not your software. I would suggest that you then do a lookup in a database to see what your corresponding item number is, and print your own labels with that item number on it. Start and Stop characters are not what you think they are. A barcode has a character on the front, and one on the back, that mark the beginning and the end of the barcode. Those are used in the symbology for no other purpose. In Code 39, that is an asterisk. The reader will not even return the start and stop characters to you. They are just for the reader to know that it is seeing the entire barcode. So, if you were printing "MIKE" as a barcode, you would actually print "*MIKE*". Also, I would avoid adding a bunch of extra encoding on your barcodes. You can make your barcodes harder to be confused just by using a checksum, because checksums are not commonly used. If you wish to add something else in your barcodes to tell your app what to do, you certainly can. In automotive industries, and any that use the AIAG label standard, each field has a single character prefix that indicates what type of data is in the barcode, be it a part number, quantity, lot, weight, serial number, etc. So, for example, if MIKE was a part number, the Part Number field would read "*PMIKE*" - the * is the start and stop, and the P means part number. Remember, Code 39 does not encode lowercase by default (you can read up on how to do that if you really want lowercase or other characters that are not in the basic Code 39 set.

3) ipod touch: We have an app that runs on the ipods (and ipads) that we wrote in LC. The employee scans the containers, and then the ipod syncs to the pc's and macs through dropbox, because we don't care if it's done in real time, and I want my warehouses to run in a more wifi fault-tolerant mode - so if the signal is weak, that isn't stopping anyone from doing their jobs. On the PC's and Macs we have CCD scanners attached, as well. A CCD scanner is a handheld scanner that uses LED lights inside to illuminate the barcode so that it can be read by the scanner. They are less expensive than laser scanners, don't have the workplace safety issues (because exposure to laser light can be harmful to the user's eyes), and are cheaper and more durable than laser scanners are. Yes, the CCD scanners are connected to the PC's and macs via USB.

5) 14 characters is a bit long, but it is not unheard of. On a thermal-transfer AIAG label, that would be about 6" long. I don't like barcodes that are that long, because they are a PITA to scan, but it is doable. I would instead use a database in your app and generate shorter barcodes for whatever field you're encoding. Yes, your company's internal part numbers might be fairly long, but that doesn't mean that when you print the barcode you have to encode the part number. You could instead use an id that you generate in your db for that part number, right? You set your table to have an ID field, and that's what you encode. "Fritos Original" might be "1" and "Moutain Dew Game Fuel 16oz Plastic" might be "2".

6) Look up "Code 39 mod 43" or "Code 39 Checksum". That will explain how to generate the checksum (and how to check the checksum against the rest of the barcode to make sure that it matches). It's pretty simple. You are looking up each of the characters in the barcode against the Code 39 table, and adding them together. Then you take that sum, mod 43, look that number up in the Code 39 table, and the character that it corresponds to is what you put in for your checksum. Example (I didn't check the Code 39 table to verify if these are exactly right):
A-1
B-2
C-3
D-4
E-5
F-6
G-7
H-8
I-9

My string is "DAD". D is 4, A is 1, D is 4. The sum of those is 9. 9 MOD 43 is 9, so my corresponding character is "I", so my string is "*DADI*". Now, if I scan a barcode, I will get "DADI" (the scanner eats the start and stop characters). I pull the "I" and do the math to verify that "I" is the correct checksum. If it is, then execution of my script continues. If it does not then scanning continues. Yes, my apps do this in real time, and you would never know because it's so fast.