Other posts seem to indicate that DataWorks DWBAR39.TTF barcode font is to be used for Epicor. Has anyone deployed a Human Readable Code 39 font (i.e. Archon 39) instead of DWBAR39? It seems that a Human Readable barcode font would economize on space of labels and forms by eliminating redundancy. Please advise.
Barcode is just a font. You should be able to change it to the one you want.
2 Likes
You need the DWBAR39 so Epicor reports work with it, because you wont customize every report. As for the reports you do customize, you can pick any font… I think I always switched to the Code-128 FULL Ascii which is slimmer and supports more characters. All Scanners even the cheap ones read Code-128 I am not sure why the industry is stuck on Code-39, its bulky and consumes ton of space.
3 Likes
I made up my own SSRS Data Matrix generator using Zint to keep barcode size tiny.
1 Like
This barcode is human readable:
(my attempt at being funny)…
Like said above, barcodes are simply a font… so if you want to have the barcode, and then text, you will need to print the value two times. One in the barcode font, and one in the regular font that people can read.
Something like this:
3 Likes
Because any program can create a Code-39 barcode. Each character in Code-39 has its own bar pattern.
Not exactly… Barcodes like Code-128 have an effective “compression” built in. There’s no specific bar pattern for an ‘A’ in Code-128. The pattern totally depends on the entirety of what’s being encoded.
It’s like comparing a Bitmap to a lossless JPEG. Each pixel in a BMP image is uniquely defined. A JPEG encoded image relies on the values of the neighboring pixels.
2 Likes
I feel compelled to write a conclusion to this post as “Solved” for future readers.
We deployed the DWBAR39 barcode font for those Out of Box reports, and added the Archon Code 39 Human Readable barcode font for those cases where we are are modifying an SSRS report and want to economize on space by eliminating the redundant text, or are generating a report from scratch. We intend to stay in the Code 39 realm, and just play by the rules (no case sensitive fields, no spaces, only period and hyphen special characters).
Fun Fact: If Caps Lock is on, the value returned by the barcode is not forced to all caps, but rather changes the case of that which is scanned. Since Code39 returns only upper case letters, if caps lock is on, they will be returned as lower case letters, which may play havoc on any case sensitive fields.
1 Like
Rookie- can i ask you a dumb question - I’m pretty sure its dumb, but I have to ask!
I’m completely new to barcoding and so have found your posts and contributors really helpful. My question is - can you include more that one field of data in one barcode? and use separators ?
or does each field have to be its own barcode?
if you can, do you have examples?
Disclaimer: I am no expert in the field of barcoding, just struggled through it and cared to share my experience.
The first thing is that you need to stay within the character set of the barcode. Code39 is alphanumeric, A thru Z, 0 thru 9, with the decimal point (.), and hyphen (-). The 39th character is the asterisk (*) which is used as the stop/start character (it is not part of the list of usable characters). Every barcode is defined by the value with the asterisk at the beginning and the end. You may be able to concatenate two or more fields, and use the hyphen as a delimiter, but then you need to decode the on the other end. That precludes you from using the hyphen as a value in any of the combined fields. (It is noteworthy Code39 will only return upper case letters.) In practical terms, it is probably easier to leave the individual fields and have the employee scan them as individual fields.
1 Like