Hi, I'm using a barcode component in the reporting module. I have it set to code 39, and I am appending asterisks to the beginning and end of the string that I use as the data key for the component, but it won't scan using multiple scanners.
To test the barcode, I also tried using a Perspective barcode component also set to code 39 and the resulting barcode is pretty different from the reporting module's barcode.
Here's the code 39 barcode generated by the reporting module:
And here's the code 39 barcode generated by the Perspective barcode component:
Is there a setting or something that I'm missing?
Why?
Or, in other words, can you show a screenshot of the exact configuration of your barcode component in reporting?
Hi Paul,
I added the asterisks as the start and stop delimiters according to the manual:
I also noticed that our customer's barcode includes the asterisks in the raw barcode data.
Here's the customer's barcode:
And here's one from the reporting module that was printed off (different data, but same length):
Here's the config for the report.
seq is a parameter that's passed into the report, then I have another parameter called seqBarcode that appends the asterisks to the sequence number.
1 Like
Hm. Yeah, as far as I can tell you're correct and you're supposed to explicitly include the * around the barcodes in Vision/Reporting. I can't explain why the output is so...bad, given the same data. I'd recommend contacting support so we can start a formal investigation and figure out what's going on.
1 Like
Sounds good, I'm thinking it may be due to a DPI setting or something with the printer that is blurring the lines of the barcode together.
1 Like
For what it's worth, 8.3.0 (our still-beta version, final release sometime before the end of the year) has some improvements to barcode PDF generation to try to use vector shapes where possible, which might help with this.
1 Like
I found the name of the font that the client's old system uses, the IDAutomation Code 39 font. I printed off the same information using this font, a Perspective barcode, a Reporting module barcode, and a Vision module barcode.
All of them worked except for the Reporting module's barcode component. This is what they look like:
IDAutomation Barcode Font:
Perspective:
Reporting:
Vision:
Something doesn't seem right to me, because all of them scan except the one generated by a report.
We use Code_39 barcodes on thousands of labels a day across dozens of Zebra printers.
We do NOT include the asterisk on the data source for the label, and we have no problems with scanning the values?
I don't think the font choice really affects it but ours are set to Arial, 18 Bold
Screenshot of the controls settings.
LotID is a 17 digit string passed as a parameter to the report.
Could it be a scaling issue with the label size and margins?
Is your report set to the exact size of the actual label with margins accounted for?
2 Likes
Thanks for the details. I ended up using a barcode font installed on the server with label/text components on the report. The barcode font is from ID Automation which is what their old system uses.
For Reporting don’t use the * character as part of your data. If you remove the character, your barcode should work. Will write a ticket to address this. Explanation follows.
Code 39 (Regular) data are delimited with the * character as shown below in magenta. The data (the letter G) is in blue. If you scan this you will get G.
-
In Vision when you input the delimiting * character as data, it is ignored. *G* and G produce the same Code 39 barcode. It automatically delimits the data with the * character.
-
Perspective does not allow you to even enter the * character. It also delimits your data with the * character automatically.
-
Reporting also automatically delimits your data with the * character. However, it allows you to enter the * character as data, it is not ignored as it is in Vision. Because of this *G* and G do not produce the same barcode. When you specify your data as *G*, what you’re getting is:
with the green part being part of the data you entered, and the magenta being the delimiting * supplied by Reporting. This is interpreted as
with 2 empty pairs of Code 39 barcodes. A pair in orange, a pair in purple. The G now isn’t delimited at all and therefore is ignored. Also Code 39 barcodes must be separated by an empty space, so even if these pairs were not empty, the barcode will not be able to be decoded.
5 Likes
