Alignment pattern
Smaller nested squares that correct for distortion on larger codes.
Alignment patterns are 5×5 module squares — a dark ring, a light ring, a single dark centre — placed at defined coordinates on codes of version 2 and above. Version 1 has none; version 2 has one; large codes have dozens.
What they do. The finder patterns establish the grid, but on a large code printed on a curved surface, photographed at an angle, or on a creased page, that grid drifts. Alignment patterns are known fixed points the decoder can re-register against, letting it correct for perspective and warping across the code.
Why styling them breaks codes. Because a decoder searches for their specific dark/light run pattern. Render them as spaced circles and that signature disappears. This is a real and easily missed failure: in our own renderer, applying a dot style to the alignment and timing patterns made every such code fail to decode while looking entirely correct to the eye. The fix is to always draw structural modules square, whatever style the data modules use.
In practice
A version 3 code (29×29) has one alignment pattern. A version 25 code (117×117) has 25 of them. The pattern count scales with size because the bigger the code, the more the grid drifts across it when the surface is curved or the camera is at an angle.
This is exactly where we found a bug in our own renderer. Applying a dot style to every module — including the alignment patterns — produced codes that looked correct and failed to decode at every version. Restricting styling to data modules fixed it, and the scan test that caught it now runs on every build.
Questions
Why does version 1 have none?
At 21×21 modules the code is small enough that the three finder patterns give sufficient accuracy. Distortion across such a short span stays within tolerance.
Can alignment patterns be styled at all?
Safest answer: no. Decoders search for their specific run pattern, and the gain from styling a handful of small squares is not worth the scan failures.