There are a number of ways of making bar codes such as FMEasyBarcodes. Geist Interactive has a bar code generator too which I would recommend over FMEasyBarcodes (FileMaker Barcode Creator - No Plugins, No Fonts - Install in Seconds ) mostly because Tim has moved away from FileMaker and Geist is all in with the FileMaker framework. Personally I mostly use Monkey Bread Software because I use it for other functions, it just happens to also have bar code generating functions too. If you are good with API's on the web, there are a number of places that you can use to make RESTful calls to generate bar codes on the web and then display them in a web viewer in FileMaker or save them to a container field depending on what you need. And if you're big into bar coding, you'll find yourself testing things often with an iOS device to read the bar codes. That works for many solutions. But if you have a heavy duty commercial warehousing app, then iOS devices are usually not the best and you can get into rugged scanners that are connected say via bluetooth to a computer or mobile device. I have one now where the iPad is secured to a cart, but they use a rugged blue tooth scanner that can be dropped and banged around a bit without destroying it. Plus commercial grade scanners are a whole lot faster than an iOS device at scanning. That's what you get when you pay for the heavy duty stuff.
you need a barcode font. I've used code 3 of 9 (code 39) extensively with FM. I guess I downloaded the font from somewhere (I thought it was included with FM at some point - anyway ...)
... might be a good source - I haven't tried this particular version.
If you want the barcode to read "1234" you display your data *1234* using the barcode font - the asterisks are "start/stop" characters that the barcode reader uses.
I personally got away from using fonts because you have to make sure every client machine as the font. Using a graphic in a container field can be viewed by all devices. Granted it is not as storage efficient as using a font. Then again, I often use MBS plugin on the server and an unstored calc to generate the bar code temporarily and often never store the bar codes.
In the business I was in, I was generating thousands of barcodes (unique order and line item numbers) every day. Containers would just be too cumbersome. And plug-ins, well, meh.
I agree with you about container storage. My recommendation to customers who ask about it is that barcodes should only live long enough to be printed. Generate -> Print (or other display) -> Delete. Exceptions can be made when speed is more valuable than storage efficiency.
Using barcodes in container fields may involve some developer effort, but certainly no more effort than making sure a barcode font is installed consistently on all the client machines that might be using it. The more client machines there are, the more the comparative effort scale tips in favor of container fields.
Before I made Barcode Creator, fonts still weren't the method I thought of first. Most barcode symbologies are not very amenable to fonts. It's technically possible with many symbologies, but it's more work than it's worth for most. Code 39 is the only symbology I can think of off the top of my head where fonts have any convenience, and that's about the only thing Code 39 has going for it as far as barcode symbology design goes. (Unless fonts are the only option or you have to work with scanners that can't read anything else, Code 39 is not a good choice compared to other symbologies.)
sorry - My opinion is that installing a barcode font along with FileMaker on a new machine is not much effort compared to managing containers. Using a barcode font is just plain easy. No scripting involved - just put it on your layout.
And, if there's any chance of putting the wrong barcode in a container, then fonts are much safer.
(not trying to be uppity)
It's just as easy to apply a barcode font to the wrong field as it is to put the wrong image in a container field.
Scripts get written once, regardless of how many users there are. Fonts must be installed at least as many times as there are machines that need to use it.
... that's about the only thing Code 39 has going for it as far as barcode symbology design goes.
In terms of productivity, FedEx was reading up to 20,000 code39 barcodes off of my package stickers every day. I don't see why anybody should shy away from something that's simple, easy, reliable and productive (and oh, free).
I disagree - If I put <<table::OrderNumber>> on a layout, it is reliable. If I format that Merge field as a barcode, instead of say Ariel, it's still the order number. There is no scripting or calculation.
In my opinion, installing a font (drag and drop) is far easier than other options.
1 of 1 people found this helpful
Depending on the size of the label, the method of printing it and the longevity required, then code 39 does have some limitations. We used it for several years but the thermal Dymo label printer in our hands produced fine lines which faded after several years and generated reading errors.
Since going to the Code 128 symbology, this issue has ceased to exist, as there are fewer bars and the the image is much sharper. I concur with the recommendation to use Jeremy's Barcode Creator.
FedEx would obviously not experience the above issues.
ah, thanks for that.
We definitely didn't need our barcodes to remain readable for more than a few days. But I'm sure that they would last for a few weeks.
1 of 1 people found this helpful
I didn't say that Code 39 isn't good enough for many applications. It's only that the ability to encode data by just slapping a font on it is the only advantage Code 39 has over any other symbology. It is simple and easy as long as you think installing fonts is a good use of time. If fonts aren't an option (such as applications deployed to FileMaker Go), Code 39 is no longer any simpler or easier than any other symbology. Tools are available to render Code 39 for free (even to do it in FileMaker), just like for every other symbology that matters. Code 39 is reliable enough, but almost every other symbology is more reliable thanks to structural features, checksums, and even error correction features in 2D codes. Code 39 may be the least compact symbology around. Plenty of symbologies can handle larger character sets (while still being more compact than Code 39).
For many applications, Code 39 is good enough. But for any application not forced into Code 39 by project constraints, better is possible. Code 128 is a good place to start for folks who don't have anything in particular in mind.