Code128 C Type Encoding
Closed this issue · 3 comments
Having a look at the Code128 barcode specs for Royal Mail / UPU tracking barcode(s), they appear to generate a slightly different barcode to this library due to the Type C switch part way through the string.
This library detects 4 or more consecutive digits and starts encoding them as Type C from the start of the string.
Royal Mail and other UPU barcodes all seem to be encoding from the last pair backward.
For example: TT037117696GB
TCPDF:
- 104 - START CODE B
- 52 - T
- 52 - T
- 99 - CODE C
- 03 - 03
- 71 - 71
- 17 - 17
- 69 - 69
- 100 - CODE B
- 22 - 6
- 39 - G
- 34 - B
- CHECKSUM = 78
- 106 - BLANK
- 107 - STOP
UPU Standard:
- 104 - START CODE B
- 52 - T
- 52 - T
- 16 - 0
- 99 - CODE C
- 37 - 37
- 11 - 11
- 76 - 76
- 96 - 96
- 100 - CODE B
- 39 - G
- 34 - B
- CHECKSUM = 5
- 106 - BLANK
- 107 - STOP
Looking at good old wikipedia:
https://en.wikipedia.org/wiki/Code_128#Barcode_length_optimization
Barcodes can save characters by delaying the C Type encoding until we have a even number of pairs:
"...01234"
... 0 [Code C] 12 34 [checksum] [Stop]
vs
... [Code C] 01 23 [Code A] 4 [checksum] [Stop]
Any chance we can add an optional parameter to force C Type encoding to start from the back of the pairs and encode the remainder separately?
Pull request raised: #44
Let me know if there are any issues with the request.
Merged
Thanks @nicolaasuni !