Production of high-quality barcodes requires that the printing process is accurately controlled from end to end. Here I provide guidance that is specific to Code 128 as well as additional guidance that is applicable to linear barcodes in general.
Optimisation of Code 128
There are no mandated size limits imposed on generic uses of Code 128, however applications of Code 128 within particular industries do define such constraints. For your in-house purposes it is really only practical constraints such as the fidelity of your printer and the capabilities of your scanner that will dictate an upper and lower size limit.
You should ensure that the data can be represented within the Code 128 as compactly as possible as this will reduce the required number of bars and space elements, which will provide greater flexibility when sizing the symbol. For example, using numeric-only data will enable efficient use of the double-density "Mode C" digit compression. See this answer for more detail.
This begs the question of whether it is possible for you to drop the dashes from your SKUs and reintroduce then within your application after scanning the symbols? Consider the different widths of Code 128s for your SKUs with and without dashes to see the impact of this:
Also, a quiet zone of at least ten times the X-dimension (width of a narrow bar) must be maintained at either end of the symbol:
The quiet zone should be considered an integral part of the Code 128 symbol as show by the above image.
General guidance for optimisation of linear barcodes
For closed applications (where you have complete control of both the printing and the scanning of the symbol), aim to maximise the width of the barcode provided that it fits comfortably within the scanner's field of view.
For open applications involving multiple trading partners with their own equipment and processes (such as general retail or logistics), ensure that the printed symbol's X-dimension and height fall within the minimum and maximum constraints defined by the relevant application standard.
In all cases, avoid anti-aliasing since many scanners perform edge to similar edge measurements that work best with clearly-defined, high-contrast edges. Anti-aliasing commonly results from scaling up an undersized bitmap image, but it might also occur in the absence of scaling as a result of features designed to improve the appearance of "jaggies" in regular images.
It is especially important to ensure that the intended X-dimension of the output symbol is an integer multiple of the printer's pixel size. Failure to do this will result in instability of element (bars and spaces) widths — elements intended to have the same width may differ by one printed dot. This is due to the set of available X-dimensions being solely determined by the number of printed dots per narrow element, and you cannot allocate fractional dots to a bar.
The specification for Code 128 (ISO/IEC 15417) imposes the following requirements on symbol generation software:
Graphics software used to create bar codes on pixel-based printers
must scale each bar and space exactly to the pixel pitch of the
printer being used. For edge to similar edge decodable symbologies
like Code 128 the number of pixels comprising each symbol character
must be a fixed and constant integer multiple of the number of modules
in the symbol character.
A corollary of this is that the physical symbol size must grow in quantums according to the dot pitch of the printer. Therefore, it is not possible to meet the dimensional constraints required for each application using every model of printer. A well-aligned symbol cannot simply be a bit bigger or smaller, so as to meet some nominal size or to optimally fill a desired space, whilst remaining properly fitted to the physical printing characteristics of the output device.
For example, the GS1 General Specifications for 2D symbols on trade items "not scanned at POS, retail, distribution or regulated healthcare" (SST 4) defines an allowable range for the X-dimension of between 0.380 - 0.495mm. This can be met by a bespoke 5 dpmm (dots per mm) printer by printing two dots per narrow bar, but it is completely unachievable with a more common 8 dpmm printer even though it is a higher resolution device: Three 0.125mm dots would be undersized; four 0.125mm dots would be oversized.
Also, when rasterising a vector path description it is essential to ensure that the origin is properly aligned with the device's dot grid. This way you can avoid bars that are intended to have the same width from being rasterised to differing widths due to pixel-grazing, as demonstrated in this image in which an identical line width is rendered to different printed widths when rendered at different X coordinates:
Failure to follow the above advice will result in an image that has certain bars thickened, as demonstrated by the following impressions:
The leftmost image represents a high-resolution impression; the middle image represents the same symbol rendered as a low-resolution impression (zoomed for scale) that has been correctly grid-fitted and will scan perfectly, because despite the lower resolution the bar-space pattern is identical to the leftmost image; the rightmost image is the same low-resolution impression but in this case has been incorrectly grid-fitted and will not scan because the bar-space pattern has been corrupted.
As an aside, notice that when the middle image has been scaled up (for demonstration purposes), anti-aliasing has been applied only to the text but not to the bars. As mentioned earlier, this is critical for ensuring that the decoding process is provided with accurate distances between the element of the symbol.
With certain printing processes it may also be necessary for the software to compensate for "print growth" (due to ink bleed and other imperfections in the process) by reducing the width of all bars by a small, fixed amount whilst maintaining accurate edge-to-edge spacing.
ISO/IEC 15417 describes this latter process as follows:
General purpose printing software designed
to support a wide range of printers should provide the user the
capability of adjusting the X dimension and bar width growth or loss.
The use of bar width reduction should be restricted to compensating for physical imperfections in the printing process, such as ink feathering. Depending upon the technology, the degree of bar width adjustment may require periodic re-calibration. Bar width reduction cannot adequately compensate for pixel-grazing that is the result of an improperly aligned and grid-fitted image description.
Even if you precisely follow all of the above advice, some devices and drivers contain advanced features (beyond regular anti-aliasing) that can defeat an attempt to print the perfect barcode symbol, especially when rasterisation involves scaling the image, even by an integer factor:
- Some RIPs may attempt to preserve the width of lines to ensure uniform "heaviness" of line art, but in doing this they will adjust the relative ratio of bar widths to space widths. It can be difficult for the human eye to observe this effect with barcodes. It might be considered to be a variation of the print growth phenomenon but in which bars are affected by some uniform scale factor rather than a fixed amount.
- Some RIPs may consider high-frequency, regular lines within a region to be a form of shading and then attempt to preserve the perceived level of gray, either by introducing additional lines of the original width to maintain the line distance when scaling or by entirely replacing the lines within the region with a halftone screen.
In summary, where the target device's resolution is known, generate a source barcode image with an X-dimension that is actually achievable, is well grid-fitted, and preferably where the source image pixels or path description aligns directly to device dots in order to to avoid all unnecessary processing of the image. Always re-verify the printed symbols whenever any component of the printing system (hardware or software) changes.
This answer demonstrates what happens when these process controls aren't followed.
