Contents
Introduction
to Bar Codes. 1
Hardware bar code readers. 1
Choosing a bar Code. 1
Code 128. 1
RM4SCC. 1
QR. 1
Testing your Barcodes. 1
Barcode Clean Up. 1
Barcode Integrity (Ensuring it works). 1
Rasterizing (Convert to bitmap). 1
Neighbouring Print. 1
Aspect. 1
Rotation. 1
Many business applications often have to produce bar codes
or maybe could benefit from them. Bar codes are typically printed onto physical
paper work so they can be scanned at some point so the human operator does not
have to worry about “keying in” a particular reference code. Big advantage
being improvements on speed and input error.
Bar codes generally fit into these groups, based on their
structure:
·
1D Traditional Bar codes, like on a can of beans.
·
2D Square, High density bar codes like QR.
·
3D Square with Colour, not implemented as not commonly
used.
If you just want to encode a simple reference number then 1D
is the way to go. If you want to ‘store’ data in the bar code the 2D is for you.
These days you can get pretty good 1D and 2D bar code
readers for around £20 all be it on the slow boat from China.
Many moons ago the only bar code reader you could get for
£20 was a 1D CCD/LED scanner, these performed awfully, you don’t really see
them anymore. Avoid them, they have a row of around 6 LEDs in the front of
them.
The more you pay the better performance you should, in
theory, achieve. I haven’t tested any expensive scanners of recent so I’m not
going to comment any further on them.
The 1D and 2D scanners use completely different technology
and each have their pros and cons:
·
1D – Uses a laser, only scans 1D, good scan distance and ambient
light performance, will not scan from computer screen
·
2D – Uses a camera, scans 1D and 2D, scan distance performance
not so good, will scan from computer screen
The decision is pretty simple; for shop floor where only 1D
is required use a laser based 1D only scanner, for everything else use a camera
based 2D scanner.
The camera 2D scanner is great for the developer because it
scans everything and you can even point it at your screen without having to
print anything out.
From the user’s PC perspective the scanner behaves like a
USB keyboard (old PS/2 has a pass-through). The user scans a bar code and it is
as if they just typed in whatever is encoded in the bar code. If they are
entering data into a form then the input field on screen must have focus (just
like with the keyboard when you enter data).
Having said that many scanners will allow you to configure
them to work over a serial port so you can create an application that receives
data directly from them independently of keyboard input, which may give a more
robust UI experience (no need to worry about a textbox having focus).
Barcode readers are often configured using a set of magic
bar codes that are in the manual. Things like which bar code types are accepted
and whether or not it automatically puts new lines on the end (hits enter after
the data). Normally the default is fine.
There are 2 native built in barcode types Code 128 &
RM4SCC.
All other barcode types are handled by ZXing.net, so the
“Spludlow.ZXing” assembly needs building and present in Applications.txt on the
host that will print the document. This will give you the following bar codes:
Bar Code ID
|
Full Name
|
Contents
|
Usage
|
|
|
|
|
Built in
|
|
|
|
Code128
|
Code 128
|
Same as “Code128B”
|
General Purpose (defaults B)
|
Code128A
|
Code 128 set A
|
ASCII 32-95 (space to underscore) and ASCII
control
|
If you need ASCII control
|
Code128B
|
Code 128 set B
|
ASCII all printable characters 32-127
(space to tilde and DEL)
|
All the ASCII printable characters
|
Code128C
|
Code 128 set C
|
Digits
|
Digits encoded in pairs for higher density
|
RM4SCC
|
Royal Mail 4-State Customer Code
|
Alphanumeric
|
UK Post codes
|
|
|
|
|
ZXing 1D
|
|
|
|
CODABAR
|
Codabar
|
Digits and: - $
|
General Purpose
|
CODE_39
|
Code 39
|
Alphanumeric, space and: - . $ / + %
|
General Purpose
|
CODE_93
|
Code 93
|
Alphanumeric, space and: - . $ / + %
|
Higher density and security enhancement to
Code 39
|
CODE_128
|
Code 128
|
ASCII or Digits
|
General Purpose
|
EAN_8
|
EAN-8
|
7 Digits
|
European Article Number
|
EAN_13
|
EAN-13
|
12 Digits
|
European Article Number
|
ITF
|
ITF
|
Digits
|
Interleaved 2 of 5 ITF-14
|
UPC_A
|
UPC-A
|
11 Digits
|
Goods identification
|
UPC_E
|
UPC-E
|
7 Digits
|
Goods identification
|
MSI
|
MSI
|
Digits (0-9)
|
Modified Plessey
|
PLESSEY
|
Plessey Code
|
Hex (0-9 A-F)
|
Hexadecimal
|
|
|
|
|
ZXing 2D
|
|
|
|
AZTEC
|
Aztec Code
|
2D
|
|
DATA_MATRIX
|
Data Matrix
|
2D
|
|
PDF_417
|
PDF417
|
2D
|
|
QR_CODE
|
QR Code
|
2D
|
|
|
|
|
|
ZXing not Implemented
|
|
|
|
MAXICODE
|
|
|
|
RSS_14
|
|
|
|
RSS_EXPANDED
|
|
|
|
All_1D
|
|
|
|
UPC_EAN_EXTENSION
|
|
|
|
IMB
|
|
|
|
Run the method “Spludlow.Drawing.BarCode.TestSheet(filename)”
to produce a code demo:
NOTE: If “Spludlow.ZXing” is not present then only the first
5 native codes will be printed. The filename can be .png or .jpg if you want
.pdf then “Spludlow.Drawing.PDF” must be present.
Code 128 is well supported and covers many characters, if
you require a 2D code then consider it first.
Set C gives double density when using digits only, make sure
you zero pad to an even length (native encoder will automatically do this),
single digits are not encode-able. (“0123” rather than “123”).
Some additional built in functionality is also provided like
changing sets within the barcode and encoding further characters using
“Function 4”. I doubt anyone would use this in practice.
Used by the Royal Mail. This bar code is the lowest tech 2D
barcode; of its equally spaced bars and gaps there are 4 shapes of bar, so
standard 1D barcode readers will not read these.
If you require 2D.
Get a 2D scanner for £20. If you are waiting for the slow
boat from China you can use “Spludlow.Drawing.ZXings.Decode(filename)” provided
“Spludlow.ZXing” is present.
Other than then the look on the web for online decoders. Not
many things decode RM4SCC I did find a web page that did this.
The framework bar code data in is cleaned up before turning
into rectangles. All whitespace around the edges will be removed and rectangles
will be joined up where possible.
Here you can see the rectangle simplification in practice
applied to the ZXing output matrix:
Trimming whitespace simplifies page layout, the barcode sits
in the specified rectangle. You may have to add whitespace yourself for certain
barcode types, basically put a white rectangle that is slightly bigger behind
the barcode.
Simplifying the rectangles will also benefit the barcode:
·
Better bitmap rendering with antialiasing (you can see faint
white lines between individual rectangles)
·
Smaller PDF size (The all on one sheet test sheet was 14K
compared to 74K)
·
Simpler vectors are better for incorporating into an artwork
design
What you don’t want is your barcodes not scanning, either
from paperwork printed by your system or a PDF that the end user prints out.
Problems can arise when the barcode is rasterized (converted
from descriptions of rectangles into a bitmap). There will be a point where
barcode density is too great for the available pixels, antialiasing can also
impair the barcode further.
As the framework uses vectors internally and customer
printed documents are usually PDF then rasterization is performed at the last
stage, physical printing, the bitmap should be printed at the printers native
resolution (in theory at least 300dpi). Antialiasing may occur within the
printer but the resolution is sufficiently high to make this irrelevant. So by
default everything is fine.
What you should be aware of is supplying barcodes in bitmap
formats. Even if they are spot on pixel perfect bitmaps placed into a PDF, when
they get printed the image may get scaled and distorted (fluffed up). To avoid
this you could place higher resolution bitmaps in the PDF, but this will add to
file size.
NOTE: In reality these problems aren’t as bad as I make out
here, just be aware.
Some barcodes have rules within their specifications for how
much white space should be around the barcode, you should check this.
1D bar codes can handle being stretched in either direction
without ill effect (provided you maintain the resolution across the barcode).
2D bar codes are a bit fussier:
·
RM4SCC – bar width should give 20 to 24 bars per inch (this range
should allow for post code lengths varying with a fixed width). Height around
10mm
·
PDF417 – Seems to cope with being stretched in each direction in
tests I did, although nice to keep it looking like a boarding card. The spec
says: Row height must be at least 3 times the minimum width
·
Square types (Aztec, Data Matrix, and QR) – Don’t like not being
square, always keep the width and height equal.
The framework allows you to rotate a bar code by 90 degrees.
No other rotation angles are supported. Rasterizing barcodes at non-square
angles will lead to jagged edges making reading difficult for the scanner and
should never be done. NEVER!