I'll attach a PR shortly to demonstrate the bug. I'm far from an expert, but I think the issue might be in roundedRectPath() of fpdf.go. The code puts a q operator into the document, which (according to the pdf specification) pushes the current graphic state settings onto a stack. This is fine, but the problem is that the code never seems to put a Q operator to pop the state off of the stack. The transform operations (like rotation) also seem to rely on this graphic state stack: TransformBegin() pushes and TransformEnd() pops. So, when we rotate a rounded rectangle we have two pushes but only one pop, and the graphic state introduced by the transform also ends up applying to subsequent elements.
I'll attach a PR shortly to demonstrate the bug. I'm far from an expert, but I think the issue might be in
roundedRectPath()
offpdf.go
. The code puts aq
operator into the document, which (according to the pdf specification) pushes the current graphic state settings onto a stack. This is fine, but the problem is that the code never seems to put aQ
operator to pop the state off of the stack. The transform operations (like rotation) also seem to rely on this graphic state stack:TransformBegin()
pushes andTransformEnd()
pops. So, when we rotate a rounded rectangle we have two pushes but only one pop, and the graphic state introduced by the transform also ends up applying to subsequent elements.