Is a checksum required in the Code128 barcode specification?

Question

Introduction

Step 1

I tried to read the barcode (see image below) using a mobile barcode reader and online tools and got it: data - 30925018, visualization algorithm - Code128C

Step 2

Then I tried to generate a barcode from given data and got these images:

Original barcode

Generated barcode

Step 3

As you can see, the images are different. So, I decided to decrypt it by myself. Here is the result:

Original decrypted barcode

Generated decrypted barcode

Сlarifications

As Wikipedia says (https://en.wikipedia.org/wiki/Code_128):

The check digit is a weighted modulo-103 checksum. It is calculated by summing the start code 'value' to the products of each symbol's 'value' multiplied by its position in the barcode string.
I tried to generate barcode from the given data by Java libs in my application, and by online tools. Both gave me the same result.

Questions

Why do online tools generate barcodes without a checksum, but with FNC1 at the end?
Why there is a FNC1 at the beginning of the barcode?
Is a checksum required by Code128 specification?

My thoughts

I think GS1-128 specification can be cause of FNC1 at the beginning of the barcode
FNC1 at the end can be just a checksum. It is just a coincidence.

Terry Burton · Accepted Answer · 2018-11-03T21:57:40.007

The original image is a GS1-128 (formerly EAN-128) representing the following GS1 Application Identifier formatted data:

(30)925018

The meaning is Count of items: 925018.

I think GS1-128 specification can be cause of FNC1 at the beginning of the barcode

Correct. By definition a Code 128 beginning with an FNC1 character in first position is a GS1-128 and should therefore contain data encoded according to the GS1 specification.

The background provided in the following answer describes the principles behind this encoding: https://stackoverflow.com/a/31760872/2568535

FNC1 at the end can be just a checksum.

The checksum is mandatory in the Code 128 specification (and any derivative application standards) and is not normally displayed in any human-readable text. In your generated symbol (not a GS1-128 since there is no "FNC1 in first") it would just be a coincidence if the checksum character happened to match FNC1, although - as noted by Brian Anderson - it doesn't.

score 2 · Answer 2 · answered Nov 01 '18 at 20:48

The original barcode had the FNC1 at the beginning. Neither barcode has an FNC1 at the end. As Terry Burton states, the FNC1 at the beginning indicates the barcode is used for GS1 and the data for that code is normally denoted (30)925018. The checksum calculated for the first barcode is the number 09 or Code 128 character ')' for right paren.

105
102
30*2 = 60
92*3 = 276
50*4 = 200
18*5 = 90
(105 + 102 + 60 + 276 + 200 + 90) = 833
833 % 103 = 09 (')')

The second checksum for the barcode without the FNC1 is the number 26 or Code 128 character ':' for colon.

105
30
92*2 = 184
50*3 = 150
18*4 = 72
105 + 30 + 184 + 150 + 72 = 541
541 % 103 = 26 (':')

It is possible to have a checksum equal to the FNC1 character? Yes. The checksum is a result of the modulo operator on the weighted sum of the elements in the barcode and the number 103, therefore any number up to 102 (FNC1) can be the result of the checksum. Because the Code 128 standard doesn't attribute any special significance to the character in the checksum position (last character before the STOP), it won't matter.

When you try to decypher a Code 128 barcode, keep in mind that there is no such thing as intercharacter spacing. A character will be the exact same width (11 "dots") unless it is the stop character (in which case 13 "dots"). The width of each dot scales with the graphic. You are better off not ignoring each character's trailing "zeroes". They are significant.