This bug describes a problem noted when investigating bug 689222. I have a solution to it, but it's a change that will have wide ranging (but hopefully minor) impact on all rendering, so it's worth describing separately in detail and soliciting opinions on the best way to test it. All the bitmap output devices I have tested in ghostscript (with the exception of the display device under windows) use a "vertically flipped" page matrix (henceforth referred to as "inverted"). This means they are typically of the form: [scale_factor 0 0 -scale_factor 0 page_height] The windows display device, by contrast uses: [scale_factor 0 0 scale_factor 0 0] I claim that the bitmap devices are wrong, and should be using: [scale_factor 0 0 -scale_factor 0 0 page_height-(1/256)] Consider a page of page_width x page_height pixels. Ghostscript treats every pixel as a half open region that includes the points on it's left/bottom edge and excludes those on the top/right edges. Thus point (x,y) falls into pixel (floor(x), floor(y)). (0,0) is therefore inside pixel (0,0) and is as low as a point can go and still be on the page. (0, page_height) is therefore inside pixel (0, page_height) and is as low as you can go and be just off the top of the page. Under the 'inverted' CTM, (0,0) maps to (0,page_height) (now off the page), and (0, page_height) maps to (0,0) (now on the page). Thus there is a definite change in which points are on/off the page under the inverted transform. More generally, under the inverted transform, a half open pixel region will change the nature of it's half-openness, rather than including the bottom and excluding the top edges, the image under transformation will exclude the bottom, and include the top edge. The solution to this is to offset the vertical swap by the smallest possible amount. Given that we work in 8 bit fixed accuracy internally, this means 1/256.
Can I demonstrate this is really causing problems with the current code? Not yet. I will try and find a concrete example where it can be shown to render differently in a bit. This is hampered a bit by the inablity to do an automated comparison of bitmap and windows display device. It certainly *does* cause problems when combined with Rays "FILL_ZERO_WIDTH" code, but I'd like to demonstrate that it's wrong at the moment without throwing that into the mix too. A local cluster regression test yesterday shows that changing this will change 16000 of our 24000 test cases. I'm running a test to show the bitmap diffs for these, but that's clearly going to take a VERY long time to complete. Preliminary results show that mostly these are very small changes. Any thoughts on this (both on the correctness of my logic and on ways to test it) would be gratefully received.
This was discussed between myself, Henry and Michael on irc yesterday. The log can be found at: http://ghostscript.com/irclogs/20091230.html.bz2
By 1/256 I assume you really mean to adjust the y-offset down by the minimum "fixed_epsilon" in device coordinates == 1 which is 1>>fixed_shift pixels (in case someone is using other than fixed_shift 8). Most people run the default, but one or two customers have used different values with the warning from us that we don't do testing at other values. Regarding the testing, the main concern is missing elements, not shifted graphics, so I recommend comparing the two bitmaps with 'fuzzy -w 3 ___ ___' to see if anything pops out. (fuzzy.c is in toolbin/tests)
Reassigning to new email address.