Hamish wrote: > > After 6 release candidates, even tested on MS-Windows, > > I don't see any real blockers any more. I suggest to get out > > 6.3.0 this week and proceed with change to 6.4.release_branch/7.0.svn. > > > > We can have 6.3.1 if needed. > > > > Sounds ok? > > to me, trac bug #72 is a blocker (PNG driver rendering offset) > http://trac.osgeo.org/grass/ticket/72
That issue has always been there, and isn't easily fixed. Lines are drawn along the "nearest" axis. E.g. for a line which is closer to the horizontal than to the vertical, the loop iterates over the X coordinates, with the Y coordinate determined using Bressenham's algorithm. The slope is always less than or equal to one, so at each step the Y coordinate either remains unchanged or increments by one, according to a test which only uses integer arithmetic. Polygons are drawn from top to bottom as a single entity (as opposed to the outline, which is a sequence of individual line segments). For each row, the X coordinates of the left and right edges are calculated using floating-point coordinates, then rounded to the nearest integer. A horizontal line (actually, a one-pixel-high rectangle) is drawn between the two edge points. It wouldn't be particularly hard to make the closer-to-vertical case match, by using the same algorithm in both cases. Making the closer-to-horizontal case match is harder (and messy). But ultimately, this is just one aspect of a more fundamental problem: integer coordinates and odd line widths simply don't mix. You cannot get this case "right"; you just have to choose which flavour of "wrong" you prefer. [X11 largely ducked the issue by stating that single-pixel lines are implementation dependent. Apart from shielding the X developers from flak from users who would have preferred a different flavour of "wrong" (even to the point of insisting that a particular flavour is actually "the right one"), it allows the use of any line-drawing functionality which is provided by the video hardware, regardless of which flavour the hardware uses.] -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
