[GRASS-dev] [GRASS GIS] #72: gis.m: boundary rendering is off by one pixel

GDAL · February 28, 2008, 4:45am

#72: gis.m: boundary rendering is off by one pixel
------------------------------+---------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: minor | Milestone: 6.3.0
Component: default | Version: svn-trunk
Keywords: gis.m, rendering |
------------------------------+---------------------------------------------
Hi,

when rendering an area with gis.m's display manager the boundary seems to
be one pixel off to the right. (or fill is one pixel off to the left
depending on your point of view) In the xmon things are fine, using all
d.vect render methods.

see the screenshot attached to this bug report.

similar things were seen before,
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/
but Glynn has now AFAICT fixed that for all d.vect + Xdriver render modes.

?

thanks,
Hamish

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/72>
GRASS GIS <http://grass.osgeo.org>
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/

GDAL · March 4, 2008, 5:21pm

#72: gis.m: boundary rendering is off by one pixel
---------------------+------------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: minor | Milestone: 6.3.0
Component: Tcl | Version: svn-trunk
Resolution: | Keywords: gis.m, rendering
---------------------+------------------------------------------------------
Changes (by martinl):

* component: default => Tcl

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/72#comment:1>
GRASS GIS <http://grass.osgeo.org>
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/

GDAL · April 15, 2008, 3:07am

#72: PNG driver: boundary rendering is off by one pixel
----------------------+-----------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.3.0
Component: Tcl | Version: svn-trunk
Resolution: | Keywords: gis.m, rendering, PNG_DRIVER
----------------------+-----------------------------------------------------
Changes (by hamish):

  * keywords: gis.m, rendering => gis.m, rendering, PNG_DRIVER
  * priority: minor => blocker
  * summary: gis.m: boundary rendering is off by one pixel => PNG driver:
              boundary rendering is off by one pixel

Comment:

Hi,

This seems to be a generic problem with the PNG driver and 'd.vect
rend=c'.

{{{
#spearfish
g.region n=4928610 s=4919190 w=596700 e=598860 res=30
d.mon x0
d.vect fields type=area
d.out.file offby1

qiv offby1.png
}}}

It was there last time I rand the rendering tests, but I guess I missed
that the error was still there. Using xmag on the tiny peninsula in the
rend=c image shows the problem too:
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_fill_PNGdriver.png

As noted here:
http://article.gmane.org/gmane.comp.gis.grass.devel/23833
"PNG driver: only 'g' lines up correctly. 'c' isn't so bad, it looks ok in
the y, but off by one in the x (boundary line 1px to the right vs fill).
[exploring with xmag]"

thanks,
Hamish

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/72#comment:2>
GRASS GIS <http://grass.osgeo.org>
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/

GDAL · April 16, 2008, 8:50am

#72: PNG driver: boundary rendering is off by one pixel
----------------------+-----------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.3.0
Component: Tcl | Version: svn-trunk
Resolution: | Keywords: gis.m, rendering, PNG_DRIVER
----------------------+-----------------------------------------------------
Comment (by hamish):

Hi, I've just added a new xmag screenshot showing that it is the area fill
which is displaced, not the boundary line. (or both the boundary line and
symbols travel together)

{{{
#spearfish
v.out.ascii fields format=standard | sed -e '1,10d' | \
grep -v '^C\|^B' | grep -v '^ 1 ' > field_corners.dat

v.in.ascii field_corners.dat fs=space x=1 y=2 out=field_corners

# then display them both in gis.m
}}}

Hamish

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/72#comment:3>
GRASS GIS <http://grass.osgeo.org>
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/

GDAL · April 24, 2008, 1:07pm

#72: PNG driver: boundary rendering is off by one pixel
----------------------+-----------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: Tcl | Version: svn-trunk
Resolution: | Keywords: gis.m, rendering, PNG_DRIVER
----------------------+-----------------------------------------------------
Changes (by neteler):

* milestone: 6.3.0 => 6.4.0

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/72#comment:4>
GRASS GIS <http://grass.osgeo.org>
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/

GDAL · May 15, 2008, 6:23am

#72: PNG driver: boundary rendering is off by one pixel
----------------------+-----------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: Tcl | Version: svn-trunk
Resolution: | Keywords: gis.m, rendering, PNG_DRIVER
----------------------+-----------------------------------------------------
Comment (by cmbarton):

It's easy enough to put in the rendering mode for d.* commands. But there
are a couple of questions. 1) Is it ONLY d.vect that has a problem? 2)
I've seen discussion go back and forth over which of these switches to
use. Has that been settled in this case?

Michael

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/72#comment:5>
GRASS GIS <http://grass.osgeo.org>

GDAL · May 15, 2008, 7:53am

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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/72#comment:6>
GRASS GIS <http://grass.osgeo.org>

cmbarton · May 15, 2008, 3:14pm

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@osgeo.org> wrote:

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

Glynn_Clements1 · May 16, 2008, 12:34am

GRASS GIS wrote:

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

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's_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 <glynn@gclements.plus.com>

Hamish · May 16, 2008, 2:13am

So does this mean that we can close the TclTk ticket for
this?

No.

If anything, it seems like a d.mon issue, not a TclTk issue.

it's a PNG driver problem which causes poorly rendered areas in the GUI displays. ie it is not a bug in any .tcl code, but does affect the GUIs. modify the keywords as you like, but keep the bug report open.

Hamish

GDAL · May 16, 2008, 2:40am

#72: PNG driver: boundary rendering is off by one pixel
----------------------+-----------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: d.vect, rendering, PNG_DRIVER
----------------------+-----------------------------------------------------
Changes (by cmbarton):

  * keywords: gis.m, rendering, PNG_DRIVER => d.vect, rendering,
               PNG_DRIVER
  * component: Tcl => default

Comment:

Changed component from TclTk to default. This is not a TclTk problem.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/72#comment:7>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 2, 2008, 12:13pm

#72: PNG driver: boundary rendering is off by one pixel
--------------------------+-------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: d.vect, rendering, PNG_DRIVER
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Changes (by hamish):

* platform: => Unspecified
* cpu: => Unspecified

Comment:

new screenshot added showing 6.4svn PNG driver output (d.out.file) of new
strike_triangle symbol with bad fill/outline alignment.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/72#comment:8>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 2, 2008, 6:55pm

#72: PNG driver: boundary rendering is off by one pixel
--------------------------+-------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: d.vect, rendering, PNG_DRIVER
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by glynn):

Replying to [comment:8 hamish]:
> new screenshot added showing 6.4svn PNG driver output (d.out.file) of
new strike_triangle symbol with bad fill/outline alignment.

Please provide the exact sequence of commands used to create the image.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/72#comment:9>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 3, 2008, 12:46am

#72: PNG driver: boundary rendering is off by one pixel
--------------------------+-------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: d.vect, rendering, PNG_DRIVER
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by hamish):

> Replying to [comment:8 hamish]:
> > new screenshot added showing 6.4svn PNG driver output
> > (d.out.file) of new strike_triangle symbol with bad fill/outline
> > alignment.

Replying to [comment:9 glynn]:
> Please provide the exact sequence of commands used to create
> the image.

{{{
# grass 6.4svn from yesterday
echo "symbol geology/strike_triangle 22 50 50 black black" >
draw_triangle.dgr
d.graph draw_triangle.dgr
d.out.file strike_triangle_PNG_driver
}}}

seems dependent on the symbol size, I tried 125 but it looked ok, so went
back to 22 as per the screenshot and it misaligns.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/72#comment:10>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 3, 2008, 8:54am

#72: PNG driver: boundary rendering is off by one pixel
--------------------------+-------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: d.vect, rendering, PNG_DRIVER
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by glynn):

Replying to [comment:10 hamish]:
{{{
echo "symbol geology/strike_triangle 22 50 50 black black" >
draw_triangle.dgr
d.graph draw_triangle.dgr
}}}

Okay. There were two problems with the existing polygon filler, which
should be fixed by attachment:ticket:72:pngdriver-polygon.patch.

The first is that the x coordinates were calculated for the top of the
pixel rather than the centre, causing an effective downward shift.

The second is that the x coordinates were truncated rather than rounded,
causing a leftward shift.

In the test case, both of these contribute to the gap on the right-hand
side, while the latter contributes to the overlap on the left-hand side.

The one issue which this patch doesn't attempt to address is the fact that
all lines are effectively shifted half a pixel down and to the right. This
is inherent in the use of integer coordinates. While you can draw a
polygon with orthogonal edges perfectly aligned to the pixel grid, you
can't draw a single-pixel orthogonal stroke with its centre-line so
aligned.

I have attached PNG files containing the output before and after the
patch, as well as corresponding SVG files which show exactly what is
happening in more detail. The actual vertices passed to the rendering
functions (both line and polygon) are [(315,240), (320,229), (325,240)].
This corresponds to the black triangle. The red triangle shows the half
pixel down-right shift inherent in the line drawing.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/72#comment:11>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 3, 2008, 10:55am

#72: PNG driver: boundary rendering is off by one pixel
--------------------------+-------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: d.vect, rendering, PNG_DRIVER
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by hamish):

Replying to [comment:11 glynn]:
> Okay. There were two problems with the existing polygon filler,
> which should be fixed by attachment:ticket:72:pngdriver-polygon.patch.
...
> The one issue which this patch doesn't attempt to address is the
> fact that all lines are effectively shifted half a pixel down and
> to the right. This is inherent in the use of integer coordinates.

any preprocessing floor(0.5+x) voodoo of the line data to align them with
the polygon rendering? [yeah, that's what got us into this mess in the
first place]

> While you can draw a polygon with orthogonal edges perfectly
> aligned to the pixel grid, you can't draw a single-pixel
> orthogonal stroke with its centre-line so aligned.

... as it would have to be zero or two pixels wide.

> I have attached PNG files containing the output before and after
> the patch, as well as corresponding SVG files which show exactly
> what is happening in more detail.

I've attached a zoom of "after" showing the left over stray pixels
shown in the SVG. Even with those, a nice improvement.

thanks a lot for looking into this- to me this issue is a really bad look
for us, sloppy output makes the project look sloppy. (and annoying for me
to have to use xwd instead of d.out.file in 6.4.

I'll try the patch in the AM.

cheers,
Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/72#comment:12>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 3, 2008, 11:21am

#72: PNG driver: boundary rendering is off by one pixel
--------------------------+-------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: d.vect, rendering, PNG_DRIVER
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by glynn):

Replying to [comment:12 hamish]:

> thanks a lot for looking into this- to me this issue is a really bad
look for us, sloppy output makes the project look sloppy. (and annoying
for me to have to use xwd instead of d.out.file in 6.4.

If you want quality, I would expect both the cairo and PS drivers to
produce better results overall than either PNG or XDRIVER. However, you
might run into corner cases where code relies upon the half pixel down-
right shift, which isn't present in those drivers. You might also run into
problems with the distinction between polylines and multiple line segments
(caps versus joins) being visible.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/72#comment:13>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 5, 2008, 6:03am

#72: PNG driver: boundary rendering is off by one pixel
--------------------------+-------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: d.vect, rendering, PNG_DRIVER
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by hamish):

Replying to [comment:13 glynn]:
> If you want quality, I would expect both the cairo and PS drivers
> to produce better results overall than either PNG or XDRIVER.

both are less WYSIWYG. Cairo thickens and antialiases lines, and PS driver
in 6.4 is limited by 6.4, and needs to be passed through pstoimg or
ghostscript to get the web/presentation image which has its own
rasterization quirks.

> You might also run into problems with the distinction between
> polylines and multiple line segments (caps versus joins) being
> visible.

unrelated, but ps.map's region box command has that problem,
obvious once you set the width a bit wider.

I ran some 'd.vect rend=' tests with the latest 6.4svn (w/ Polygon.c
commit). screenshots & scripts here:
http://bambi/hamish/grass/bugs/d.vect/dec2008/

{{{
results for render mode trials 5 Dec 2008

coastline

6.3.0
-----
xdriver: R, C perfect; G near perfect; D, L off (x+y)
pngdriver: R, C off (x); G perfect; D off (y); L off(x+y)

6.4.svn 20081205 (with Polygon.c patch)
-------
xdriver: R, C, G perfect; D, L off (x+y)
pngdriver: R, C off (x); G perfect; D, L off (x)
gis.m: off (x)

inter-version
-------------
xdriver- results mostly unchanged (fixed 1 pixel in G)
pngdriver- D,L slightly improved

boxes

6.4svn xdriver: D, L off (x+y)
6.4svn png driver: all look good.
6.4svn gis.m: looks good
}}}

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/72#comment:14>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 5, 2008, 6:10am

#72: PNG driver: boundary rendering is off by one pixel
--------------------------+-------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: d.vect, rendering, PNG_DRIVER
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by hamish):

Replying to [comment:14 hamish]:
> I ran some 'd.vect rend=' tests with the latest 6.4svn
> (w/ Polygon.c commit). screenshots & scripts here:
> http://bambi/hamish/grass/bugs/d.vect/dec2008/

ahem,

http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/

'd.vect rend=g' seems to work ok with the PNG driver, due to thicker lines
which cover up any gaps (trade one problem for another).

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/72#comment:15>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 5, 2008, 6:20am

#72: PNG driver: boundary rendering is off by one pixel
--------------------------+-------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: d.vect, rendering, PNG_DRIVER
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by hamish):

... another thing I noticed in those screenshots is that 'd.text size=5'
(percent) is different between 6.3.0 and 6.4svn for the same frame size.
shrug.

and of course width=2 covers up minor sins.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/72#comment:16>
GRASS GIS <http://grass.osgeo.org>