PDFPipe

Linear (1D) / ITF-14

ITF-14 barcode in a PDF

The barcode printed on shipping cases: fourteen digits, deliberately coarse, and framed by bearer bars that exist to prevent misreads.

Where the symbol comes from

This API renders HTML to PDF. It does not generate barcodes, so the ITF-14 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

Exactly fourteen digits, being a trade item number at case level. Interleaved 2 of 5 encodes digits in pairs, one digit in the bars and the next in the spaces, which is where the density comes from and also why the digit count must be even.

The check digit, and who computes it

The fourteenth digit, modulo 10, and part of your data rather than of the symbol. As with EAN-13 it lives in your product records, so a fourteen digit number that fails its own check is a data problem upstream rather than a printing one.

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.495mm to 1.016mm, which is deliberately much wider than a retail symbol. ITF-14 is printed by flexographic press directly onto corrugated board, and corrugate absorbs ink unevenly, so the symbology is specified coarse enough to survive that.
  • Quiet zone: 10 times the X-dimension at each end, which at the wide end of the range is over a centimetre. On a case label this is usually guaranteed by the bearer bar frame rather than by the layout.

Where it is used

  • outer cases and cartons in a distribution chain
  • pallet and shipper labels where the item number identifies the case rather than the unit
  • anywhere a retailer's inbound specification calls for a case-level code

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="itf14">
  <img src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0i..." alt="ITF-14 15012345678902">
  <figcaption>1 5012345 67890 2</figcaption>
</figure>

<style>
.itf14 {
  margin: 0;
  /* Bearer bars. Interleaved 2 of 5 has no self-checking start and stop
     pattern strong enough to prevent a partial scan, so a scan that
     clips the end of the symbol can return a valid but shorter number.
     The frame makes a partial scan fail instead. */
  border: 4.8mm solid #000;
  padding: 0 10mm;
  background: #fff;
  width: max-content;
  print-color-adjust: exact;
  -webkit-print-color-adjust: exact;
}
.itf14 img {
  width: 110mm;
  height: 32mm;
  display: block;
}
</style>

What goes wrong on paper

Dropping the bearer bars because they look like a heavy border. They are not decoration. Interleaved 2 of 5 can be misread when a scan crosses only part of the symbol, returning a shorter number that is structurally valid, and the bearer bars are the mechanism that turns that silent wrong read into a failed read. A silent wrong read on a case label sends a pallet to the wrong place.

First thing to check when it will not scan

Check that the digit count is even and is exactly fourteen. Interleaved 2 of 5 encodes pairs, so an odd number of digits either fails to encode or gets a leading zero added by the encoder without telling you, which changes the number.

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 ITF-14 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.495mm to 1.016mm, which is deliberately much wider than a retail symbol. ITF-14 is printed by flexographic press directly onto corrugated board, and corrugate absorbs ink unevenly, so the symbology is specified coarse enough to survive that. 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.