As you're experiencing, the encoding of data for a Code128 barcode can be somewhat complex, particularly when you are encoding via a relational (i.e., non-procedural) manner. The Code128 specification requires the inclusion of a checksum character that, as you realize, uses a Modulo 103-based algorithm. There is no way to circumvent this Code128 barcode requirement, so I call into question why you are using it? There are other, simpler barcodes available.

For example, if the data to be encoded is comprised only of digits and you have only a very small physical footprint available, then 2 of 5 Interleaved (also called Interleaved 2 of 5) is a good choice, as it encodes only digits, and each pair of digits are interleaved into a single barcode character (the bars in a character encode one digit and the spaces/gaps in the same character encode the second digit).

If your maximum data length is 15 digits, these can be encoded into 8 barcode characters plus a start character and a stop character, so the data density is higher and therefore, the barcodes are shorter in length. Conveniently, the inclusion of a checksum digit with Interleaved 2 of 5 is optional, but if included, is calculated using a simpler Modulo 10-based algorithm.

Code 39 (sometimes called 3 of 9) is another alternative. The checksum is optional, but is calculated via the simpler Modulo 10-based algorithm. Each digit is represented by a barcode pattern (no interleaving), so the barcode patterns are longer. Uppercase alphabetic and a few special characters are supported.

Update:

We purchased a barcode 128 font pack with 7 different sizes in that allow for scaling so small barcodes can be printed. Working on the SQL statement has given some barcodes that work; they will print and scan again.

The SQL statement is of the format (just for example purposes, in Infomaker altered for taking in a 7 digit id from the database):

//using 128A

select
'ë' ||
'5694318' ||
chr(mod(sum(103
+ case when length ('5694318') > 0 then (ascii(substr('5694318', 1, 1)) - 32) * 1 else 0 end
+ case when length ('5694318') > 1 then (ascii(substr('5694318', 2, 1)) - 32) * 2 else 0 end
+ case when length ('5694318') > 2 then (ascii(substr('5694318', 3, 1)) - 32) * 3 else 0 end
+ case when length ('5694318') > 3 then (ascii(substr('5694318', 4, 1)) - 32) * 4 else 0 end
+ case when length ('5694318') > 4 then (ascii(substr('5694318', 5, 1)) - 32) * 5 else 0 end
+ case when length ('5694318') > 5 then (ascii(substr('5694318', 6, 1)) - 32) * 6 else 0 end
+ case when length ('5694318') > 6 then (ascii(substr('5694318', 7, 1)) - 32) * 7 else 0 end), 103) + 32) ||
'î'
from dual

id 5694318 becomes ë5694318fî
id 5694319 becomes ë5694319mî
id 5694320 becomes ë56943184î
id 5694321 becomes ë5694318;î

and so forth. These will print out on a label and scan again with the 128 font selected in Infomaker.

The issue is the checksum on certain ids become a non printable character when concated into the string for printing. 5694792 for example doesn’t print anything for the calculated checksum char, therefore won’t scan when printed.

The same issue arises using 128B as well.

I’ve not looked as much at 128C, as the work around for odd number inputs looks more complex.

I’m assuming the statement needs tweaking slightly to alter those out of range into something that works, but I’ve not been able to find by what.

Any ideas?

Thanks.

Looking at the specifications for 3 of 9 (aka Code 39) barcodes in the link I posted earlier, it states that x>=.19mm. In barcode nomenclature, "X" is the width of the thinnest bar/space in a barcode pattern, so the 3 of 9 spec says that X cannot be less than .19mm in order to have a reasonable assurance that a scanner can accurately scan and decode the barcode.

For 3 of 9 barcodes, bars and spaces can also be 2X or 3X wide. The bar & space patterns always take up 15 * X, plus one additional X for the thin space between adjacent barcode patterns. A single 3 of 9 barcode pattern always begins and ends with a bar and contains 5 bars and 4 spaces.

Therefore, the minimum total width of a 3 of 9 barcode character pattern is (15+1) * 0.19mm = 3.04mm

A 3 of 9 barcode must begin and end with start/stop characters (patterns). For many barcode styles, the start and stop patterns are different from one another, but for 3 of 9 they are the same. The purpose of the start & stop patterns is to tell the scanner if the barcode has been read left-to-right (correct side up) or right-to-left (upside-down), so that the entire barcode pattern can be successfully decoded.

A 3 of 9 barcode may contain a checksum character. If included, it always precedes the stop character.

You state the maximum character length of the barcode pattern is 15 characters. You did not state whether or not this includes the start/stop characters and the optional checksum, but for sake of this exercise let's assume 15 characters is the length of the complete barcode.

In order to be able to assure the 3 of 9 barcode is readable, the minimum width of a 15-character barcode is: 15 * 3.04mm = 45.6mm.

You have 32mm available to you, so to be able to squeeze the barcode into the available space, you must reduce the scale by nearly 30%, which is a pretty significant reduction. My guess is that a scanner will not be able to read and decode it at that scale. To use the 3 of 9 barcode style, you must reduce the maximum character count to 32mm / 3.04mm = 10 characters, or use wider labels.

Admittedly, the 3 of 9 barcode style has poor "density"... it requires a generous number or bars & spaces (16 * X) to encode a single character. I don't know if you are able to utilize an alternative barcode style. If the data being encoded is limited to digits only, there are other styles with better "density" (2 of 5 Interleaved, for example) and may allow you to produce a scannable barcode that contains 15 characters in only 32mm. The URL I posted earlier should be helpful, and there are other similar web sites that can be found.

HTH, John

Hi, Hollie(?)/John(?) -

I have numerous questions and am unsure where to begin...

1. What type of barcode are you trying to produce? It sounds like "3 of 9" (aka Code 39), but then you mention Code 128. Which is it?

2. How much information (maximum number of characters) are you encoding into the barcode? Can you provide a full-size image of a working/scannable example barcode?

3. What is Thermo's Nautilus LIMS and what does it do? Is it software? What does it produce?

4. Is @Dotum a TrueType font? Is it a proprietary font? Where can it be obtained?

5. 35mm x 40mm is a very unusual size for a 3 of 9 barcode, as I would normally expect it to be much longer/wider than tall. Again, an example would be most helpful.

6. Was Infomaker 2019 able to produce scannable barcodes prior to switching to version 9.5 of LIMS? If so, that would seem to indicate that the issue is not caused by Infomaker.

Most, if not all, barcode styles have minimum standards that must be adhered to in order to ensure the barcode is scannable. Here is a URL that lists specs for several barcode styles, including 3 of 9:

    https://www.tec-it.com/en/support/knowbase/barcode-overview/linear/Default.aspx

Without more details and example(s), I doubt anyone here will be able to help you.

Best regards, John

I've had multiple different printing issues but that was after going from 2019 to 2022. Have you talked to Thermo support?