what is Printer-based Barcodes,How is it implemented?

Question

How is this technique implemented?

I noticed that they(like Bartender) don't directly concatenate commands like ZPL (etc.).

And also they don't use bitmap(GDI,GDI+ images) transfer to printer-driver.

Printer-based Serialization In print jobs that include serial numbers, many printers can accept a starting value and the incremental step size. When you use this printer-based serialization, you can print a large number of serialized items without having to send any data after the first label.

Printer-based Barcodes Printers that have built-in barcode functionality make it possible for software programs to request complex barcodes by using simple text strings (such as “1234”). This process is much faster than sending bitmap images (or pictures) of barcodes that consume hundreds or thousands of extra bytes per printed item. (When you use software other than BarTender, our driver fonts give you some limited functionality.)

Answer 1

Printer-based barcodes are, as you mention, barcodes that have the symbology / definition stored in the printer firmware. Much like a DLL that you give "12345" and as a result gets a bitmap, an SVG file etc etc.

Many modern label printers know a bunch of common symbologies such as EAN, DM, QR, UPC and similar.

The benefit is obviously that it makes transfer of data much more efficient. Instead of sending a (large) image for every print, the software just sends initial definition (layout, symbology choice and options, ..) + the value needed. Taken to the next level, the printer could receive metadata such as "take this layout, make 500 labels, and in the barcode start at 1, increase 1 every label".

Some disadvantages are

• is that the appearance is left to the firmware designer of the printer firmware
• There may be less coordination between what's being designed and what's being printed, although typically the driver for the printer should adress this.
• The printer firmware may not be updated if the barcode symbology specifications has been updated
• The printer firmware may contain only a subset of the barcode definition

In short, simplificy vs freedom of parameters and appearance.

How it is technically implemented (at printer end, from receiving the number to drawing the actual barcode) is probably out of scope for this forum.

---

Example specification (in newer printer model)

Looking at a random Zebra Printer (ZT600) the built-in barcodes covers nearly every use:

1D symbologies
Code11, Code39, Code93, Code128 (all subsets), 
UCC, ISBT, UPC, EAN 8 / 13, UPC/EAN extensions, 
Plessey, Postnet, 2of5, Logmars, MSI, Codabar and Planet Code

2D symbologies
codablock, PDF417, Code49, Datamatrix, 
QR, TLC39, MicroPDF, RSS14 +composite and Aztec.

Answer 2

When you print an element on a label (barcode or text) you can do that by sending a graphic field or by instructing the printer to pick up the element internally and build the element with the configuration you need. For example, in case you want to print a text, the ZPL command will include the font you want to use, vertical and horizontal size, position of the text and so on.

In the case of a barcode, the barcode selector contained in the ZPL command, will automatically recall the .BAR file stored in the Z memory, which contains the instructions for the printer to build the barcode, then, in the same command and likewise for the text, you have also provide the size of the barcode (usually it's a ratio between the narrow and the bold line), the position, the human readable line and so on.

The graphic method is used for example when a font which is not stored on the printer memory is used: the printer doesn't recognize the font and so it can't build the text, so the print can happen only after a conversion of the text field into a graphic field. This works well with text fields, but the barcodes can have quality issues as, due to how a thermal printers physicall works, the lines of a barcode can be printed like a sort of saw. Moreover you can't see or edit the data since the code is basically unreadable, that's why it's impossible to send serialized data, unless you use a software.

The element printing is not affected by this type of quality issues and allows you to edit the data.

If you want to see the difference, try to use zebradesigner and print to file a label with a barocode. When you select a barcode, you can choose to print it as a graphic or to use the printer element and you'll see that the .prn files will contains different data.

This is what you get using the printer element (128 barcode containing 123456789012) https://justpaste.it/66gvp

and this is the same barcode printed as graphic field https://justpaste.it/27abu