#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. > 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) see Glynn's reply of 2008-04-16 which covers the guts of this bug, http://article.gmane.org/gmane.comp.gis.grass.devel/26529 (I can't get on any high-horse about using the trac system right now as the trac server is currently unresponsive, while email continues to flow through) 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. My current workaround is to do: {{{ alias xwdtopng='xwd | xwdtopnm | pnmtopng > ' xwdtopng image.png }}} GRASS 7 is expected to use floating point coordinates for rendering, so the problem goes away (or is replaced by another). Hamish -- Ticket URL: <http://trac.osgeo.org/grass/ticket/72#comment:6> GRASS GIS <http://grass.osgeo.org>
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
