[GRASS-dev] Re: [GRASS GIS] #72: PNG driver: boundary rendering is off by one pixel

[Michael Barton]

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" <trac at osgeo.org> wrote:

> #72: PNG driver: boundary rendering is off by one pixel
> ----------------------+-----------------------------------------------------
>   Reporter:  hamish   |       Owner:  grass-dev at lists.osgeo.org
>       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