The address got cut off at the label edge: ^FB and line wrapping

An ordinary text field draws on a single line, from the position ^FO gave it to wherever the text ends. If it ends past the label edge, everything past the edge does not exist.

^XA
^FO40,40^A0N,36,36^FDRua das Flores 1234 apartamento 56 bairro Centro Sao Paulo SP^FS
^XZ

We rendered that label: it comes out reading "Rua das Flores 1234 apartamento 56 bairro Centro S" and stops there, mid-word, exactly where the edge falls.

There is no warning. Conversion succeeds, the PDF opens, and the difference only shows up when someone reads the address. It is the same kind of silent defect as content placed outside the label area, and the cause is the same: ZPL draws where it is told, without an opinion.

^FB declares a block: a width in dots, inside which text folds by itself. It goes before ^FD and applies only to the next field.

^FO40,40^A0N,36,36^FB700,6,0,L
^FDRua das Flores 1234 apartamento 56^FS

With ^FB, the address from the previous example comes out on two lines, whole. We rendered both side by side.

The four values, in order:

• 700: block width, in dots. This is the number that decides where the line folds.
• 6: the maximum number of lines.
• 0: extra space between lines.
• L: alignment. L is left, C centre, R right, J justified.

The 700 in the example is not 700 millimetres nor 70% of the label: it is 700 dots. On a label 101.6 mm wide at 8 dots per millimetre, the whole label is 813 dots. A 700-dot block leaves a margin, and a 900-dot one never folds at all, because no line reaches 900 before leaving the label.

The sum for choosing the number: usable width in mm × dots per mm. For a 100 mm label with a 5 mm margin each side at 8 dots per mm, the block is (100 − 10) × 8 = 720.

If you do not know how many dots per millimetre your file assumes, the guide on 203, 300 and 600 dpi shows how to find out in thirty seconds, by looking at the largest number in the file.

Both position a field, and the difference shows when you line up text of different sizes side by side. ^FO measures from the top of the text; ^FT measures from the baseline, the line the letters sit on.

The practical consequence: with ^FO, a 30-dot text and a 60-dot text placed at the same y look misaligned at the bottom, because the 60 hangs lower. With ^FT, both rest on the same line, which is what the eye expects.

Neither is more correct. ^FO is simpler to calculate and serves most of the label; ^FT solves the one row where different sizes live together.

Convert a single label carrying the longest address you have, and look at the PDF. The long address is the test: if it fits, the short ones fit. Testing with "Rua A, 10" proves nothing.

If you are assembling the file yourself, it is worth putting ^FB on every address field, short ones included. It costs one line and removes the whole class of defect.