We have a third-party web app that as part of its functionality prints labels with barcodes on.  This was working fine until PCs were upgraded to IE11 and then the printed barcodes could no longer be read by a hand-held barcode scanner!  To confirm the behaviour, downgrading IE back to IE9 fixed the problem and upgrading that back to IE11 broke it once more.  Printing from IE11 to a standard Laserjet printer instead of the label printer produced output that could be scanned successfully.

The printer in question is a Toshiba thermal printer that was chosen for its ability to be powered by a rechargeable battery and its ruggedised nature.  Here it is:


It’s using the Seagull Scientific printer drivers from here.  The barcodes are of symbology Code 39.

One thing that was noted was that the printer is only 203 DPI which means it could be at risk of struggling to fit the needed level of detail into a given space if the barcode is below a certain size.  Measuring a scannable and non-scannable printout showed no difference in printed width (I’d wondered if there was some scaling going on in IE11).  Looking really closely at the printout, the non-scannable barcode did look more indistinct on the thinnest black lines but there were also places where the line patterns for repeated character zeros were inconsistent.  It reminded me of what happens when you shrink an image down without resampling – which is presumably something like what is actually going on – though why differing IE versions should affect this was not clear.

Here are some close-ups of part of the printed barcodes where you can see the most obvious difference in the two printouts.

 Working – from IE9  Faulty – from IE11
 Barcode-Good  Barcode-Bad

Today I found this extremely useful webpage.  To quote:

When printing barcodes fonts to a printer with less then 600dpi, such as a thermal 203dpi printer, the print should be no smaller than 20 points. Otherwise, print at the point sizes specified in the chart below.


It is necessary to use the point sizes specified in the chart above with low resolution printers so that there are the exact number of dots required to create the exact ratio of bar and space sequences. Because fonts cannot calculate or perform operations on their own, they have no method to compensate for low resolution devices.

We had a look at the template that was generating the label and the barcode font was 10 point.  Increasing this to 12 to match the chart above did indeed fix the problem!  We also tried 6 but it was too tiny and wouldn’t scan.

Despite being fixed this still left the question of what was different between IE9 and IE11 that could explain it all.  I’m assuming that it must be something to do with the IE rendering engine behaving differently in IE11.  Remembering from past experiences that printer drivers interact with graphics drivers it made me think about graphics rendering specifically.  Although the following setting was also in IE9, I tried ticking it on an affected IE11 machine:


That fixed the problem and enabled even a 10 point barcode to print in scannable form from IE11!  I don’t fancy leaving that ticked because of potential performance degradation and unknown issues with other current and future web apps, so we’ll be sticking with 12 point for now.  My next – and probably final – port of call would be to try an updated [on-board] graphics driver.