Marking engines

Hi,

I'm writing a barcode label printing routine. The goal here is to avoid fancy/expensive "label printers" with their high supply costs, special equipment, etc. Instead, printing on sheets of self-adhesive labels using COTS laser printers (preferred).

Many of these are relatively low density (600-1200dpi). Many barcode symbologies have small *nominal* module sizes -- on a par with the naive resolution of these printers (e.g., 7mil is commonplace).

With non-contact scanners, we can exploit lower character densities to help alleviate this problem. But, only up to a point! (lower densities have their own problems)

In either case, knowing *exactly* how the marking engine translates its input into dots on a page is a significant issue. E.g., perfect alignment with the underlying "grid" of the printer leaves ink spread as the only real issue affecting printer tolerances. OTOH, misalignment can cost you UP TO a dot width of error (and, like ink spread, this can affect the adjoining bar/space).

And, many printers interpose extra smarts (e.g., REt) between the interface and the marking engine that further distort the mapping between "intended image" and *actual* image.

How can I exploit industry standard interfaces to minimize the potential for error creeping into the images? E.g., will PCL let me directly drive the bitmap used by the marking engine (or, is there other handwaving that happens

*after* PCL)? Can I force a PostScript rendering to a particular underlying implementation?

And, how *bad* are other marking technologies when tight tolerances are a concern? E.g., I assume ink spread on ink jets is too variable to control (media, ink, etc.)?

Thx,

--don

Reply to
D Yuniskis
Loading thread data ...

I would assume that any visual code system that's tolerant to dirt, smudging, etc., would be tolerant to a significant amount of printer mess. As long as the decoder can tell which bars are thin and which are thick, I'd think that would be all you'd need, wouldn't it?

Is this not so, or are you just borrowing trouble now, rather than having it thrown at your head later?

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

The "tolerance" of these systems to these issues is largely a consequence of "scan the label at a different point" (to get around the dirt, smudge, etc.).

In the actual scanning *path*, most symbologies are not very tolerant of these types of problems. E.g., a "speck" that bridges the space between two bars makes the code unreadable (with high reliability*) at that point. Moving the scan path to avoid that point gets around the problem. (note that many handheld, noncontact scanners get this ability "for free" as users can rarely hold the scanner in a fixed position that would cause the beam to repeatedly traverse that "bad spot")

[*You can, of course, *infer* what the marred symbol would have been by ASSUMING all other symbols have been correctly decoded and computing its expected value from the check digit -- if the code has that feature. But, that increases readability with a corresponding decrease in RELIABILITY.]

The specifications for the various symbologies define tolerances for each of these dimensions. Some go so far as to mandate how the decoding should be performed (or, by implication, how it should NOT be performed).

The problem lies in deciding thin vs thick.

Each symbology ("code") has rules governing what is thick and what is thin -- and in each *symbol* ("character"). Most codes use two bar "nominal" widths: "thin" and "thick". Some codes use several *different* widths (e.g., some as many as a dozen or more specific widths WITHIN A GIVEN SYMBOL DENSITY).

Some codes encode information in the "spaces" as well as the bars. I.e., a "speck" in a whitespace alters the dimensions of the bar to which it adjoins (assuming it *does* adjoin a bar and isn't just sitting in the middle of a space)

*plus* the width of the space on which it encroaches.

Some codes use a factor of 2:1 for wide:thin, others 3:1, etc.

By way of example, a bar with a nominal 7mil module width when printed on a 300dpi printer (assuming *perfect* imaging, no ink spread, etc.) gives you 6mil (2 dots) or 9mil (3 dots) wide bars -- *if* the bar edges are perfectly aligned with the marking engine (!). The 9mil bar is 30% oversized; the 6mil bar would be 15% undersized.

If the bars *don't* line up with the marking engine and you tried to print that 7mil bar straddling *4* dots, the marking engine could render it as all four of those dots -- *12* mils wide. (you're now pushing that 2:1 threshold... and we haven't accounted for ink spread, toner granularity, etc.).

On one axis, the marking engine can (typically) retain good dimensional stability (e.g., across the "width" of the page). On the *other* axis, most marking engines have far different dimensional stability (i.e., *down* the page). So, how you ("I") orient the image you present to the marking engine also plays a role.

I'm "doing (good) engineering". :> Identifying the issues that affect performance of the solution to preclude their occurrence. Having been on the other side of the fence (designing barcode scanners/decoders), I know how these issues can affect the accuracy and first pass read rate attainable in a scanner (though I can't speak for sure about particular COTS scanners). Anything I can do to increase my "margin" -- while remaining consistent with the stated goals -- improves the overall system. (e.g., I can chose to round up instead of down; or shift an image to better align it with the underlying marking engine instead of blindly printing it in some particular place... *which* is probably arbitrary to begin with!)

Reply to
D Yuniskis

I would strongly recommend you look at Gnu Barcode. I've written both laser barcode drivers and label printer barcode drivers using this tool and whatever scripting language is at hand.

It is incredibly simple, once you figure out what you're trying to produce, and then use a scripting language to drive the printer ... or integrate it directly into the spool driver on unix/linux type systems ... C'est in morceau de gateau (piece of cake).

I've literally done it in Awk, Tcl and Perl for various commercial sites ... and after integrating the driver within the spooler ... there is ZERO support it works well !!!

Reply to
Spam

Generating labels is easy. The problem I am facing is generating *good* labels with the "least capable" printer required. For that, an understanding of what goes on between the "data connector" on the printer -- whether that be PCL, PS, etc. -- and the marking engine is paramount.

The printing (marking?) technology also plays a role in how you present the label "image" to the printer. While I don't want to design something that works with *any* printer, I would like to make sure I understand the consequences of potential technologies and best adapt the label generating code to that/those technologies.

The more you abstract the "label generation" from the actual marking engine, the more vulnerable you are to the vagaries of the printer. E.g., move a label by a fraction of a "dot" and you've now changed the actual sizes of the bars within that label; rotate a label 90 degrees and it's dimensional accuracy changes; etc.

You don't want to print umpteen labels, affix them to their respective homes and *then* discover that they are of poor quality (decodability, etc.)

Reply to
D Yuniskis

Snip

Snip

What about a calibration pass with a scanner involved?

Do that before your bulk run?

Glyn

Reply to
Glyn Davies

. . .

Which barcode format are you actually planing to use.

Low cost printers are much better now than they were even a few years ago, but the high tolerance printers and systems still have better reliability. My experience is printer processing does not harm the readability of barcode that was printed on it. By 600dpi most inventory formats will produce consistently readable results. At that point the biggest printer issue will be ink and regular maintenance.

Regards

Walter..

-- Walter Banks Byte Craft Limited

formatting link

--- news://freenews.netfront.net/ - complaints: snipped-for-privacy@netfront.net ---

Reply to
Walter Banks

Hmmm... I'll read this two ways just in case I misunderstand:

- If I use a *flatbed* scanner (i.e., "page scanner"), then I end up turning the "printer dpi" problem into a "scanner dpi" problem (along with having to write a decoder/verifier for a bitmapped "image")

- If I use a *barcode* scanner, then all I have done is verified that a *particular* scanner is able to decode some particular *set*/instance of labels. This says nothing about the quality of the labels (present and future).

I'd like to be able to convince myself (and impartial "others") that a particular printing technique *should* produce "good" labels. This reassurance also pays off *if* you ever encounter a "bad batch" -- you don't have to question the "design" of the printing algorithm; just the particular *instance* of the printing (bad toner, excessive humidity, etc.).

As barcode labels have become ubiquitous, there are firms that actually make analyzing labels their whole business. There are even standards that spell out how to "rate" the quality of a particular label...

Reply to
D Yuniskis

ABC Codabar. Though probably at 5-6 cpi to enhance my margins.

I *think* at 400dpi I can convince myself that "theoretically" the images are within tolerances for all bar/space dimensions. I don't, however, know what the printer itself does to the "image data" before it gets to the marking engine. "Economode", "REt", etc. all suggest that the data is being "conditioned" to "improve" the resulting marking. Since it is of paramount importance that what I *say* is what I *get*, I need to be able to convince the printer *not* to "do me any favors".

Maintenance *will* be a major concern. People evaluate print quality much differently than "machines" (like scanners) do. Specks, smears, etc. might not be noticeable to a human but could render labels illegible easily.

Normal variations in toner quality alone could have dramatic effects! E.g., RH can vary from a *few* percent to "VERY close to 100%" here. How that affects the flow of toner at a "microscopic" level (hmm... what's a less intense word than microscopic -- milliscopic??) isn't something most folks would typically notice.

Reply to
D Yuniskis

I have designed both printers and barcode systems. The printer image processing is unlikely to make the image worse when printing the barcode and can be essentially ignored.

Print consistency is more important than resolution. Bar Code readers now mostly image and the process making almost any consistent print readable. (Look for example at all the barcode apps that run on cell phones with camera's)

The maintenance issues are printer life and consistent print. If you are not going to used one of the label printers that were designed to print barcode you need to create maintenance procedures and define which ink should be used.

As much literature as there is on variations on toner quality it impacts hand held scanner more than an imaging scanner. Readers that can image the whole printed barcode can make sense out of some very bad images.

Walter..

--- news://freenews.netfront.net/ - complaints: snipped-for-privacy@netfront.net ---

Reply to
Walter Banks

Do you have any information on what these "technologies" actually *do* to the "image data"? (my understanding is that this all happens *above* the marking engine -- or, has that demarcation been blurred with newer printers? i.e. more tightly integrated)

The scanners we will be using are handheld "vibrating mirror" type (or variations thereon). I.e., a linear CCD but the label is still "examined" (avoiding the word "scanned") one-dimensionally.

I suspect the printers that are *actually* used will be reasonably high quality -- 1200dpi "commercial" machines (nothing SOHO). However, in one application, I expect there won't be much in terms of regular maintenance, etc. (there isn't even an IT department there!) Hence, aiming for lower densities with lots of redundancy in the labels themselves will hopefully compensate. If not, they'll have to find some "professional help" :>

I'm stuck in the former class. Not quite as bad as *wands* (so at least the scanner has a chance to "see" the label many times in each scan instead of just *once*)

If push comes to shove, they'll have to budget for better labeling equipment (all I can do is "my best" and they'll have to do *theirs*). Or, I'll redesign the application's frontend and move everything over to RFID.

Reply to
D Yuniskis

The essential ingredient of the more recent printer technology is to create images as true as possible to what is sent then accounting for mechanics of the printer. This means that images are processed knowing how the print mechanism actually delivers the ink to the paper. The printer control software is doing what you have been essentially suggesting you would like to do.

Regards

Walter..

-- Walter Banks Byte Craft Limited

formatting link

--- news://freenews.netfront.net/ - complaints: snipped-for-privacy@netfront.net ---

Reply to
Walter Banks

In my experience, for a given printer, the "scale" of the image affects the ability for it to be read electronically. At some point the barcode will be too small to discern the markings, and the scanner will fail.

My experience has been with mixed text/barcode, and format layout was equally important in the application, as the text was a retail price tag, and the barcode was used for floor inventory. This on both a laser printer, and a thermal label printer, but I got both to work reliably, given that I knew which scanner was being used.

Good luck. Rob.

Reply to
Spam

Indeed

My comment regarding scanning (yes, I meant a test sheet of printed labels) was inspired by my HP office jet.

Part of it's setup involves a print then scan to align things. That may be for colour sync though...

Reply to
Glyn Davies

But, I suspect that is from the standpoint of a *human* viewing the printer's output. I.e., it could opt to antialias an arbitrary input in an attempt to make it

*look* like what it *thinks* you want it to look like.

E.g., imagine trying to print a single dot *at* the boundary between physical dots. It could print a dot of *exactly* the right dimensions -- but OFFSET by half a dot width (i.e., by opting to print *your* dot in the location before or after the straddle point). Or, it could try to print two "half dots" in those two print positions resulting in an actual dot that may be anywhere from 0% to 200% of your desired size.

I had this problem years ago when tasked with designing an interface to emulate a Versatec printer on "our" printer having higher resolution. You can make things *look* the same (ignoring moire patterns) but, under a magnifying glass, the differences are obvious.

I wrote a test script in PCL (which should handle most of the newer HP printers) that deliberately lays down small dot patterns perfectly aligned with the (theoretical) print element. I did the same in PS (querying the underlying printer resolution within the script).

I've only recently returned from some travel and am currently focused on retiring and replacing some servers (end of year equipment upgrades in anticipation of the tax man) so I haven't had a chance to round up an assortment of likely printers on which to run the scripts.

I also want to sort out a way to take accurately dimensioned photos through my microscope so I can quantify the extent of ink creep, etc.

It would be interesting to see how different marking technologies fare in this respect. Though I'm not sure I want to invest that much effort just for the sake of *knowing*... :-/

Reply to
D Yuniskis

The same argument also applies to the scanning engine. It's all about resolution. Whether you are printing it or trying to optically resolve it.

If, for example, you enlarge the "unit" used in printing the barcode label (for those codes that adhere to the concept of a "unit"), then the effects of the resolution of the printer can be minimized. I.e., make unit 10 times larger and printer's resolution is ten times less significant in the resulting (oversized) label.

Given an infinite sized scanner of a fixed resolution (and software that is sufficiently adaptive), a larger label is still *seen* at the same (scanner) resolution but the ratios of the bar/space widths are now less impacted by these variations (data is encoded in these

*ratios*, not in absolute bar/space dimensions).

Some scanners (e.g., vibrating mirror) have a fixed *angular* resolution. So, as the label gets physically larger, you end up having to move the label further from the scanner objective in order for the scanner to "see" the entire label. The *angular* dimensions of the bars then don't really change (assuming you "read" each label in the scanner's "sweet spot") so the effects the finer printing are somewhat different.

I've pretty much decided that there is no need for text as it just complicates the label printing process and doesn't add much value. The barcodes will ultimately be replaced with RFID tags -- so the human readable text on a barcode label would be the equivalent of "reading" a *defective* RFID tag :-/

Reply to
D Yuniskis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.