Lars Ahlzen wrote: > >> Additionally, the fact that GRASS monitors (unfortunately) receive > >> integer data (screen coordinates, line widths, etc) somewhat limits the > >> effectiveness of the high-precision output from the CAIRO driver. For > >> example, in the "Massachusetts Counties and roads" example, the > >> antialiasing breaks down for certain lines because they are divided into > >> smaller segments whose coordinates are rounded before they are drawn. > >> Similarly, zooming in on vector output will also reveal this drawback. > > > > Perhaps that rounding can be toggled based on the output device... > > I wish, and please prove me wrong here, but I believe that this would > require a (minor) architectural change to GRASS. All monitors drivers > get their drawing coordinates as integer data, e.g. "Draw a line from > position 4, 23 to 5, 45", rather than floating point values, like "Draw > a line from 3.84, 22.96 to 5.41, 45.11".
One of the main changes in 7.x is that graphics coordinates will use floating-point. For geographic data, the expected approach will be to set an appropriate transform then use cartographic coordinates. > That makes some sense as long as you only display data on a pixel based > screen/file with no antialiasing or oversampling (like the X or PNG > monitors), but not for higher quality or vector format output. > > The PS driver that is currently in the CVS tree seems to suffer from the > same problem, btw, which limits its usefulness as well. > > Changing this would probably mean adjusting all monitor drivers (which I > don't think would be overly complicated, but it would take a bit of work). Changing the drivers is the easy part; it's changing all of the d.* commands which takes the effort. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
