Barcode BWR adjustment

[Chief_1975]

If we where sending a file to printer who didn't specify their BWR spec and they where using Litho Offset (either sheet feed or web) then we would apply a BWR of 25 microns. For the litho printers we have worked with over the years who do specify BWR, the range has been 0 to 25 microns.

[Al Ferrari]

Thanks for the response Chief,

Let me double check my self on the math for microns: 1 micron is a millionth of an inch or .000001". So 25 microns is .000025". Correct?

The packaging printer I need to satisfy is asking for a BWR adjustment of -.002". By comparison, your 25 micron adjustment seems tinny. What software are you using to implement it? Does it apply the adjustment to an already generated bar code, or does it apply the adjustment on the fly as it generates the bar code?

Thanks,

Al

[gordo]

Let me double check my self on the math for microns: 1 micron is a millionth of an inch or .000001". So 25 microns is .000025". Correct?

25 microns is 0.00098 in - the width of a 2% halftone dot at 240 lpi or a 1% halftone dot at 120 lpi.

On a 2400 dpi devices that's two CtP pixels (one pixel being 10.6 microns). Put another way, you cannot make a BWR less than one pixel, i.e. 10.6 microns (0.00042") on a 2400 dpi device.

Best gordo

[Al Ferrari]

Thanks Gordon,

But I would have preferred having it pointed out to me that a micron is a millionth of a meter, and not of an inch. That would at least have given me credit for the "millionth" part. Try to catch me doing something right for a change. That's precisely why I started out that post saying I needed to check the math. I knew I had something cockeyed.

The other source of nagging doubt is that I had come across a barcode software company stating that
they took input for the BWR adjustment in microns, although I don't recall them saying how many of those they used.

I still would like to know what bar code software Chief uses.

Al

[meddington]

Supplying a number of packaging printers, I've seen litho BWR requirements ranging from .000" to -.004" (presumably based on substrate type, ink viscosity, impression, etc), with -.002" being the average. Generally BWR is defined at the stage of creation of the barcode.

[Al Ferrari]

Thanks Meddington,

So some packaging printers had no BWR required at all, and presumably they forego that based on a track record of no reported scanning errors at the retail checkout registers.

I am only after the facts here, and not justifying the practice.

While am at it, I see that no one has taken me up on my simulated gain test idea. I had hoped that it would engender a discussion leading to the realization that the printed barcode is only one cog in a complex structure involving the retailer's processing software that needs to have provision for appropriate the handling of faulty scans.

The liability side of the discussion so far was tending toward blaming the printer for the failure of the whole structure, in my view, the printer is only on the hook for the replacement of the faulty press run. Any packaging printer with a contract exposing them to more than that needs a new legal resource.

Al

[billw@mlode.com]

As a flexo printer we have to deal with, technical phrase, "alotta of squish" at press. Years ago we tested different BWR based by barcode size when printed on semi gloss stock with a waterbased varnish. We tested a version A code at 80%, 85%, 90%, 95% and 100% and felt that to best optimize the readability of a code we would apply a different BWR based on percentage.

FYI the BWR's are:

80% -35μ (.001379")
85% - 45μ (.001773)
90% - 60μ (.002364)
95% - 70μ (.002758)
100% - 20μ (.00394)

We use a software program (Barcoda) to create our codes which allows one to enter the BWR at code creation.

I have been with my employer for 27 years this summer, and the BWR test was done early in my career with them. As far as I know we have never had a barcode reject problem from either the CPC or the retail outlets that sell their products.

[Chief_1975]

I use Esko dynamic bar code plug-in for Illustrator, in past I have used Agamik which is stand alone program that creates a EPS file which can then be imported.

There lots other bar code software options out there, both stand alone and plugins for the various software applications, Indesign, Quark, Illustrator etc.

[Al Ferrari]

Thanks very much for the info.

Al

[jlee]

As a packaging printer we apply BWR on all barcodes regardless of printing process. They are however different based on print process, substrate and barcode direction (ladder or picket fence) in relation to press direction. One thing that is extremely frustrating is the fact that there is a significant difference in a barcode verifier vs a retail barcode scanner. All of our customers (primarily pharmaceutical) demand that we have verification reports that show ANSI grades of C or better, this can be an interesting challenge and I actually have a failure on my desk right now which is forcing me to reprint a job due to a barcode that is 1/1000th of an inch out of spec. The worst part is the fact that I can read the number correctly using a scanner, and I can read and decode the code on a verifier. But the verifier actually grades the barcode as a D due to a problem on BWR.

The scanners at the retail level are extremely forgiving, I've actually seen a package where the prepress operator slipped a decimal using 11.5 mil BWR when he should have used 1.15 mil which resulted in the strangest looking UPC style code I've ever seen. We took it to 5 different retailers with different systems and it scanned fine, but it was still out of customer tolerance.

So as much as I agree with you that in offset you don't really need BWR, the question really should be who do you have to satisfy, are you worried about scanning at the retailer level or do you need to meet an ANSI, ISO, GS1 grade requirement. If you need to meet a grade requirement BWR does have an impact. BTW My team also uses Esko dynamic barcode plug-in.