PDFPipe

Linear (1D) / UPC-A

UPC-A barcode in a PDF

The North American retail barcode: twelve digits, and technically a subset of EAN-13 with a leading zero.

Where the symbol comes from

This API renders HTML to PDF. It does not generate barcodes, so the UPC-A symbol itself is produced by an encoder in your own stack and placed in the markup, either as inline SVG or as a data URI. That split matters more than it sounds: the encoders are mature and correct, and almost every barcode that will not scan failed for a layout reason rather than an encoding one. Everything below is about the layout half.

What it can encode

Twelve digits. A number system digit, a manufacturer code, a product code and a check digit. A UPC-A is an EAN-13 whose first digit is zero, which is why a scanner configured for EAN-13 reads both and why the same product can appear under a twelve or thirteen digit number depending on which system you ask.

The check digit, and who computes it

The twelfth digit, modulo 10 with alternating weights of 3 and 1. Note the weights start the other way round from EAN-13 because the digit positions are offset by the implied leading zero, which is why a check digit routine written for one and used for the other silently produces wrong numbers rather than errors.

Size and quiet zone

The two measurements that decide whether a scanner accepts the symbol, and the two most often lost when a design is adjusted to fit.

  • X-dimension: 0.330mm at 100 percent, giving 37.29 by 25.91mm. The same 80 to 200 percent magnification range applies as for EAN-13.
  • Quiet zone: 9 times the X-dimension at each end, so about 3mm at full size. Symmetric, unlike EAN-13, which is one of the few places the two genuinely differ in a way that affects layout.

Where it is used

  • retail products sold in the United States and Canada
  • coupons and in-store items, through specific number system digits
  • any packaging that has to work at a North American point of sale

Placing it in the markup

The quiet zone is padding on the container rather than part of the encoder's output, so it survives a change of encoder. Dimensions are in millimetres, because a bar width is a physical measurement and a percentage makes it depend on whatever the container happens to be.

html
<figure class="upca">
  <img src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0i..." alt="UPC-A 012345678905">
</figure>

<style>
.upca {
  margin: 0;
  /* Symmetric, 9X each side, unlike EAN-13. Roughly 3mm at 100%. */
  padding: 0 3mm;
}
.upca img {
  width: 37.29mm;
  height: 25.91mm;
  display: block;
  /* Stop any smoothing filter from softening the bar edges when the
     PDF is rasterised by a printer driver. */
  image-rendering: crisp-edges;
}
</style>

What goes wrong on paper

Reusing an EAN-13 layout and keeping its asymmetric padding. The symbol is a different width and wants symmetric quiet zones, so a template shared between the two markets gives one of them too little space on one side. If both markets matter, they are two layouts.

First thing to check when it will not scan

Check the check digit first, because a UPC-A calculated with an EAN-13 routine produces a valid-looking twelve digit number that no scanner will accept as consistent. Then check the quiet zone.

Vector, not a bitmap

Encode to SVG wherever the encoder offers it. A rasterised barcode is resampled when the PDF is printed, and at 203 or 300 dots per inch the bar edges land between printer dots, so the ratio of bar to space drifts by a fraction of a millimetre. That fraction is the whole tolerance. An SVG stays vector inside the PDF and is rendered at the printer's own resolution, which removes the entire failure mode. Where a bitmap is unavoidable, generate it at the final physical size and set image-rendering so nothing smooths the edges.

Frequently asked

Does this API generate UPC-A symbols?

No. It renders HTML to PDF. The symbol is produced by a barcode library in your own application and embedded in the markup as SVG or as a data URI, which is the same way you would put any other generated graphic into a document. What this API is responsible for is that the symbol reaches the page at the size and position you specified.

Why does it scan on screen and fail on paper?

Three reasons, in order of frequency. The quiet zone is present on screen because the browser window is white and absent on paper because the label is not. The symbol was sized as a percentage, so it came out at a different physical width than the one that was tested. Or it is a bitmap, and printing resampled it so the bar-to-space ratio moved outside tolerance.

Can I scale the symbol to fit the space I have?

Uniformly, within the range the symbology allows, and never on one axis. 0.330mm at 100 percent, giving 37.29 by 25.91mm. The same 80 to 200 percent magnification range applies as for EAN-13. is the constraint on the way down. Scaling one axis changes the bar-to-space ratio on a linear symbology and makes a 2D symbol non-square, and neither survives a scanner.

Other symbologies

Codes of the same kind, and one from each of the other kinds.

Paste the markup into the playground with your own encoder's output and see what comes out at the real page size.