Glynn Clements wrote:
Good point. It makes sense to set the default line width to 1 unit, at
the very least for PNG output, to make sure it's consistent with the
behavior of other pixel-based monitors.
Note that you cannot get consistency with XDRIVER; X intentionally
doesn't specify the rendering of thin (zero width) lines, so that a
hardware implementation can be used. IOW, zero width lines are
rendered however the graphics chip decides to render them.
X may be an exception in that respect. Then again, have you ever used a
system that didn't render them as 1 pixel lines? ;-)
Anyway, assuming that the default line width is 1 unit for pixel based
output (to be consistent), then the problem remains.
At this point, it's largely moot.
Integrating the cairo driver (e.g. modifying libraster to allow direct
rendering via the cairo driver) is probably too destabilising a change
now that 6.3 is at the release-candidate stage, so gis.m will likely
continue to use the PNG driver.
It may be moot with respect to 6.3.
I just want to make the driver as useful as possible. Since I still
don't see any downside implementing the offset (other than a few extra
lines of code), but a significant benefit, I see no reason not to do so.
It's by no means urgent, though.
7.x will use floating-point display coordinates throughout, so there
will be no need for any offset.
True. This will be very nice indeed! Btw, do we expect more 6.x releases
after 6.3, or will all work shift to 7.x?
/ Lars
--
Lars Ahlzen
[EMAIL PROTECTED]
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
