GRASS GIS wrote: > #72: PNG driver: boundary rendering is off by one pixel > ----------------------+----------------------------------------------------- > Reporter: hamish | Owner: [email protected] > Type: defect | Status: new > Priority: blocker | Milestone: 6.4.0 > Component: Tcl | Version: svn-develbranch6 > Resolution: | Keywords: gis.m, rendering, PNG_DRIVER > ----------------------+----------------------------------------------------- > Changes (by hamish): > > * version: svn-trunk => svn-develbranch6 > > Comment: > > Michael: > > It's easy enough to put in the rendering mode for d.* commands. > > There is no need for the GUI to expose the render mode to the user, it's a > debug switch to aid development. > > > 1) Is it ONLY d.vect that has a problem? > > no, it's a problem with the rendering library functions. the different > render= switches choose which lib fns to render with.
It's only d.vect that has that option. > > 2) I've seen discussion go back and forth over which of these > > switches to use. Has that been settled in this case? > > For d.vect it has been changed to "c" as the best compromise for GRASS 6. > (where "best" means it was the last man standing; IIRC some of the > otherwise more favoured candidates had the possibility of writing outside > of the X buffer etc. and so were disqualified) That's about right. r, d and l can result in coordinates which exceed the 16-bit limit of the X11 protocol, so don't work with XDRIVER (they might be useful if you will only be using the PNG/PS/cairo drivers), while g uses client-side rasterisation, which is far from ideal when used with non-raster drivers (PS, HTMLMAP, PS/PDF/SVG output from the cairo driver). > I had thought to post new screenshot tests responding to that post > exploring my observation that the current problem is with near vertical > lines. Spearfish's fields vector layer is a good example as it has many > near horiz + vertical boundaries and is the basis of the first 2 of 3 > screenshots attached to this report. The third is varied coastline data, > but demonstrates what happens with a diversity of line angles. In light of > those 3 I don't think any more screenshots would provide any more info. > > > Glynn wrote in the above post: > "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)." > > I'm cautiously optimistic that the problem is with the closer-to-vertical > case. If so, and thus it isn't a major developer drain to fix it, then I'd > really hope we could do that for 6.4 as for GRASS 6 the PNG driver is our > primary d.* hardcopy output method. In that case, the fix is to make draw_line() in lib/pngdriver/Draw_line.c match line() in lib/driver/Polygon.c. Currently, the former uses Bressenham's algorithm[1] while the latter uses floating-point linear interpolation. [1] http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm OTOH, the real issue may be that one of the primitives is rounding the coordinates while the other is truncating them. If so, this is a consequence of the fundamental API flaw, namely the use of integer coordinates. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
