Loading ...
Sorry, an error occurred while loading the content.

1641Re: corrupted symbols: analysis and solution

Expand Messages
  • dagoldman
    Oct 8, 2005
      I took the code snippets and expanded them into a
      program for making the templates Steve mentioned.

      It makes a whole bunch of templates. Don't worry about
      the ones with gaps. The program loops multiple times with
      a varying stringency factor (segDelta) for when to make
      a segment point. The ones at the end don't have gaps
      (segDelta = 0.51). I erred on the side of including
      too many templates, to give more choices.

      code - http://www.ehdp.com/out/pl/pl-temps.c
      output - http://www.ehdp.com/out/pl/10-8-05.txt

      I think the templates hard-coded into a header file,
      as Steve suggested. The irregular ones might need
      some hand editing, to take out some of the border
      points to make look cleaner, or add some border
      points to the ones with gaps.

      Let me know if need something different.

      Daniel

      --- In ploticus@yahoogroups.com, Andrew Schulman <andrex@a...> wrote:
      >
      > > here's a tentative plan for a solution for the lop-sided data
      point
      > > symbols problem.
      > >
      > > grgd.c and x11.c (the two raster-type devices that ploticus
      supports)
      > > would each have a new function for rendering a pixel-based data
      point
      > > symbol at a specific location.. they would share a low level
      function that
      > > would render the data point symbol by using templates to color
      specific
      > > pixels centered around a data point.
      >
      > Sounds good.
      >
      > > what I'll need to come up with are the templates. There will
      need to be a
      > > template for the various data point shapes, each in several
      sizes. These
      > > would be defined in a .h file as program data. For instance, for
      a small
      > > square:
      > >
      > > <pre>
      > >
      > > ooooooo
      > > o*****o
      > > o*****o
      > > o**x**o
      > > o*****o
      > > o*****o
      > > ooooooo
      > >
      > > </pre>
      > >
      > > Each character will control one pixel. x indicates the exact
      center. Two
      > > different characters (o and * in this case) are used in case we
      want a
      > > solid colored symbol or an outlined symbol.
      > >
      > > I can come up with the templates for squares, diamonds, and
      triangles
      > > easily enough. Circles would take a little more effort.. not
      that big a
      > > deal but if anyone can come up with good looking circle templates
      in
      > > various sizes up to ~20 characters in diameter that would be a
      help.
      > > Maybe there's some ascii art on the web somewhere that could be
      used...
      >
      > It seems to me that the algorithm in mark.c is already pretty good
      for this:
      >
      > /* (1=up-tri 2=down-tri 3=diam 4=square 5=pent 6=circ 7=right-tri
      8=left-tri
      > 9=nice-circle) */
      > static int nc[] = { 3, 3, 4, 4, 5, 12, 3, 3, 20 }; /*
      number of
      > corners (constant) */
      > static int nt[] = { 90,270, 0, 45, 90, 90, 0, 180, 90 }; /*
      location
      > (in degrees) of first corner (constant) */
      > static double h[24][2]; /* the offsets */
      >
      > [...]
      >
      > theta = 360.0 / (double)nc[inc];
      > /* get offsets */
      > g = nt[inc];
      > for( i = 0; i < nc[inc]; i++ ) {
      > h[i][0] = r * cos( g * TORAD );
      > h[i][1] = r * sin( g * TORAD );
      > g += theta;
      > }
      >
      > [...]
      >
      > /* draw perimeter */
      > else {
      > Emov( x+h[0][0], y+h[0][1] );
      > for( i = 1; i < nc[inc]; i++ ) Elin( x+h[i][0], y+h[i][1] );
      > Elin( x+h[0][0], y+h[0][1] ); /* close to starting point.. */
      > Elin( x+h[1][0], y+h[1][1] ); /* and do one more so last
      corner is
      > done right.. */
      > }
      >
      > If this is implemented with x, y, and r expressed in pixel units,
      the result
      > should be quite good. Rounding errors in h[][] will be symmetric
      around the
      > origin, so at least the shapes will be regular. There might still
      be some
      > jaggedness, for example in the circle, which could then be a good
      candidate
      > for antialiasing. That algorithm could be used to develop static
      symbol
      > templates as you suggest, or to create them on the fly as is done
      now.
      >
      > > should be able to get this into the next release. Exactly how
      this option
      > > will be invoked by the user is still to be decided.. probably the
      more
      > > automatic the better.
      >
      > Excellent! It seems to me that this option should just be the
      default for all
      > raster devices, or at least for GD to start. I can't think of any
      reason that
      > a user wouldn't want to use the method that plots regular symbols.
      >
    • Show all 12 messages in this topic