To make high quality barcodes, several work-arounds have been adopted by barcoding software:

The pixel size of a high resolution device is too small to be noticeable by even high resolution scanners. The overall accumulation of rounding errors is small. The barcode printed is also very accurate - meaning that you can always achieve the size you want on a high resolution printer.

Another way is to make the width value closest to integral times of a pixel length. Our testing found that this approach worked very well when the bar code element width occupying at least 2 pixels. Based on this theory, when you carefully select the element width value you can still achieve a grade A barcode on a low-resolution printer.

Some software only work with specific barcode printers. They work around the issue by allowing user to enter the length values in the number of pixels. The problem with this approach is that the barcode data is only meaningful to certain category of printers. The barcode data is not portable.

By making the logical units closest to the integral times of the width of a pixel, we calculate the magic numbers as shown in the table below:

From the table above, the smallest width achievable on a 203-dpi thermal printer is 10 mils. On a low-resolution printer you can not achieve high precision - the achievable smallest width on a 203 dpi thermal printer is 5 mils and on the computer screen it is around 10 mils.

When you create barcodes under the screen resolution (96 dpi), you end up with a big X dimension value - 21 mils. As previously analyzed, 1X does not work very well because the accumulated rounding errors may result in a complete loss of an element.

To solve the barcode quality issue while retainig maximum portability, our Barcode DLL aligns all lengths to the edge of pixels. Moreover, the drawings are now in the unit of pixels, instead of any logical units. Doing this ensures you get a quality barcode even on low resolution devices when you are drawing a width at 1-pixel's width level.

However, this approach brings some side effects. Due to the priority to ensure the constant width, the overall length achieved may vary from device to device. You may find that the same barcode prints much bigger or smaller on a thermal printer than on a laser printer. You have to give up the precision to gain the quality. Secondly, the pixel level drawing only happens when ZoomRatio=1.

As you can see from the table, lengths of the barcodes are almost the same on high resolution printers ( 300 dpi and 600 dpi). But on low-resolution printers, it varies greatly, especially on the computer display.

During the rasterization process, the printer driver is consulted to get the best rendition. Text character usually appear bigger than their renditions on laser printers, and some printer models have problem rendering bold fonts. We recommend you do more testing when working on these low-resolution devices, and stick to one configuration which meets the quality and performance.

On low resolution devices, the choices for the actual NarrowBarWidth are limited, especially when we want the barcode as small as possible. The program calculates the NarrowBarWidth based on the resolution of the target device. Although you can specify different values, you may not get different results because the program only draws bars/spaces to the pixel edge. For example, when Barcode DLL draws on a computer display, specifying NarrowBarWidth as 8 mils renders the same barcode as with NarrowBarWidth set to 14 mils. Both lengths turn into 1 pixel at the time of rendering.

With the overall barcode length varying from device to device, the overall layout may look different too.

Graphics exchange file formats are invented to allow the drawings to be transferred from one program to another. Fundamentally there are two categories: vector graphics format and raster graphics format. A vector graphics file stores drawing commands. On the target device, the drawing commands are replayed.

Many people think that the image files produced under high resolutions will have the best quality. This is not correct. When an image produced based on high resolution is renderred on a low resolution printer, the render program has to scale down all lengths. If it is a raster image, several adjacent pixels are compressed into one pixel. If it is a vector image, the lengths are divided by a ratio and rounded to the nearest integer. This transformation process likely causes rounding errors. When the bar width is small, the widths of elements become non-constant, and some drawings may be lost during the compression process.

Transferring images produced based on low resolution to a high resolution device may also have problems, but to a lesser degree. First, if two resolutions are compatible (for example 300 -> 600) there is no distortion or loss at all. And there are no rounding errors converting the logical units to the device units in the second device. Secondly, even if the two resolutions are not compatible (96 dpi -> 600 dpi), the pixel size in the second device is too small that one more or less pixel won't affect the barcode quality at all. And most of important, narrow elements won't be lost when scaled up.

As a result, you should pay special attention when you have to transfer images from one to another. Obviously, the best approach is to produce images under a resolution that matches the target printer. Barcode DLL automatically rounds all length values to the pixel level.

Needlessly to say, you may not have the control over the process under some circumstances. We list several common cases below:

It should be noted that some image processing programs have no concept of "resolution". Although they support vector graphics format, however they simply raster the image into pixels at screen resolution. As a result, if the original images were produced based on a higher resolution, the resulted barcodes usually have very low quality. Do not use those programs to edit barcode images exported from Barcode DLL.