The PDF gotcha that cost an afternoon
A hairline rule in a table looked wrong by 10 to 25 points, only on rows after a letterspaced date chip. The bug wasn't in the alignment math; it was in a PDF operator that survives past where you'd expect it to end. Drag the slider to leak it yourself.
A reportlab-based document generator started drawing right-aligned numbers past the end of their column, by exactly the amount you'd expect from a bug that isn't in the math at all. Values overshot a table's hairline rule by 10 to 25 points, but only in rows following a row with a letterspaced chip in it — rows without one aligned perfectly, and drawRightString looked correct on inspection. PDF has an operator, Tc, character spacing, that a chip sets to widen gaps between its own letters. The bug: Tc is graphics-state, not a property of the text object that set it. It survives past ET, the operator meant to end a text block, and keeps applying to every text object drawn after it on the same page, including the row total two lines down. reportlab's stringWidth, which computes where a right-aligned draw should start, has no idea any of this happened — it measures assuming zero spacing, so the start position is correct for a string about to render wider than that measurement says. The fix is one extra line: reset Tc to zero before the text object closes, not after — by the time you're back in the caller the state has already leaked into the next draw call. What caught it wasn't reading the source, it was rasterizing the page and measuring the rightmost dark pixel per row against the rule. The math was never wrong. An operator from two lines up was still switched on.