was a larger discussion about mapserver development

[Stephen Lime]

> Steve,

> Instead of searching for a new image/graphics library, we can just
> adapt the currently used one.  gd has a very open license, and is quite
> easy to extend, only requiring major changes in the getpixel and setpixel
> functions, as well as replacing all of the color allocation,
> deallocation, and matching functions.

>  I have re-written much of the library (in it's 1.2 incarnation) to
> support 24 bit color ( and am extending it to 32 bit as time permits).  I
> also took a polygon renderer from Michael Abrash's computer graphics book,
> and adapted it for use with the library.  I haven't really looked at the
> new polygon rendering code, but since it seems to work just fine, I don't
> think that it would take much modification to update my code using the new
> gd.
  
I re-wrote gd as well, a few years ago. I was 
hoping to add some functions for antialiased 
lines, etc. but that was beyond my programming
expertise at the time. It may be possible to 
swipe some antialiasing code from the Gimp or the
ImageMagick packages. 

I don't use the GD polygon rendering. I rewrote an
algorithm I found someplace when the GD 1.2 
version was busted. It handles disjoint polygons 
and polygons will holes all in one step. Works 
nice and is pretty efficient.

>  Using the standard graphics libraries, it will be simple to include any
> graphics type (with the appropriately named world file) as a base image.
> I currently have jpeg and tiff supported, but including other formats
> would only take a few hours to learn the library api.

GIF and PNG are necessities, GIF especially. With 
and without LZW. Taking advantage of many of PNGs
features may be tricky, but worth it.

> I have also used libttf with my code, and it works quite well.  I
> haven't looked at the new gd ttf code yet, so I cannot say how much work
> it will take to get it all up to date.

I don't think it's worth using the GD 
implementation of gdtf. Actually I think it's just
a straight call to a couple of functions so there
really isn't anything to add. I'd sort of like to
create a mapgraphic.c file with all the drawing
functions (both antialiased and non-antialiased
versions) and image reading, writing functions in
one place, and not worry about GD. It may be years
before 2.0 is out- I don't think they started.

>  I am going through the code right now, adding the correct references to
> code sources, and will send it to this list in a few days.

Keep me posted. Re-writing the graphics piece was
something I didn't want to myself. If others are
interested I think a very cool product could be
just around the corner.

>  BTW, In order to merge better with some of the other projects I have
> been working on, I have written my version in C++, but it can easily be
> rewritten to use the standard c gd function calls again.

A move to C++ will have to happen with the core 
code. Maybe version 4.0 *sigh*. Actually, I do 
have a decent object model in place now. First
though, I need to get 3.3 out to users.

> -Aaron Stafford
> Geographical Information Center
> California State University, Chico

Steve