So does this mean that we can close the TclTk ticket for this? If anything, it seems like a d.mon issue, not a TclTk issue.
Michael On 5/15/08 12:53 AM, "GRASS GIS" <[EMAIL PROTECTED]> 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. > >> 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 __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
