Ouch, I responded to the wrong bug report. Redirecting. > Date: Wed, 17 Feb 2021 19:26:38 +0000 > From: Alan Third > Cc: larsi@gnus.org, ynyaaa@gmail.com, 46556@debbugs.gnu.org > > > I've now stepped through the code which implements rotation, and I see > > nothing wrong with the results. The pixel coordinates of the rotated > > square are exact and accurate, without any roundoff that I could spot. > > Each square starts exactly 50+8 = 58 pixels after the previous one (8 > > pixels are taken by the SPC character between the squares), and ends > > exactly 50 pixels after it starts. > > > > So I have no idea why the one-pixel shift happens. Of course, I don't > > really understand what that code does (although I hacked it quite > > extensively), so maybe someone who really understands that stuff could > > take a look and tell what's wrong there. > > Can either you or the OP provide a screenshot? It's not entirely clear > to me what's happening. It sounds like some of the behaviour of this > bug would be explained by the mask not being rotated with the image, > but other bits of the description don't seem to match that. I attach a screenshot, note the 3rd square from the left, where the red square line seems to be 1 pixel off to the right and down of the black background. > The other bug with the single pixel white line sounds more like an > off-by-one in SVG production, but you'd see that in every image, so > it's probably not that. That's the bug I was talking about. I didn't look closely at bug#46556, as it talks about transparency, something I have no idea how it works and indeed whether it's at all supported on MS-Windows.