Bug 1957, a solution... (sort of)

[Howard Butler]

The situation we have now is untenable as well.  We now have *two*  
critical patches that must be applied to your libgd before you can  
fully take advantage of MapServer in all its glory.  With libgd not  
releasing in almost two+ years, you can also see that distros have  
been steadily increasing their patch level of this library as well.

A possible thing we might try is to entice Boutell into releasing  
libgd with some funding opportunities.  We definitely need to give  
him fair warning that we're considering a fork because of inattentive  
maintenance.  I'm doubtful this would have much effect though.  If we  
have to suck it up and fork, we will probably be in the position  
Frank was with libtiff for a while... not being seen as the  
"mainline" library.  If your system libgd isn't current enough, and  
using a fork of libgd is required to use MapServer, there isn't much  
difference in my mind whether or not the bug fixes are a completely  
new lib or a patchset.

Possible solutions that don't require a fork all have significant  
downsides:
- Placing the offending functions inside of MapServer would cause  
problems for PHP and other MapScripts that might already be linking  
in libgd to do other graphics things
- Placing an entire libgd disto inside of MapServer would definitely  
cause problems for PHP because PHP ships bindings for libgd.   Mixing  
these two could be as bad or worse than the PHP regex mess.
- Distributing a patch set places the burden on users to either build  
a separate libgd or patch their system one.  Building MapServer can  
be scary enough.

Anyone know of other projects besides MapGuide that are using libgd  
to the extent we are?  Maybe we can find some strength in numbers....

Howard

On Nov 13, 2006, at 7:44 AM, Dave McIlhagga wrote:

> If the existing GD guys can't make this a priority -- are they open  
> to new active developers/contributors?
>
> After all -- if we're talking about essentially a GD fork, we're  
> going to be maintaining it ourselves anyway.
>
> Dave
>
>
> Steve Lime wrote:
>> There hasn't been a new version of GD in two years and no indication
>> that one is planned soon. I believe the Autodesk folks had  
>> submitted all
>> of their changes to the GD authors. The last contact I had with  
>> the GD guys was related to the serious bounds checking error they  
>> have with
>> antialiased rendering. At that time he indicated a new version was in
>> the
>> works but never answered follow-up emails inquiring about timing,  
>> access
>> to beta versions and so forth. That was 6 to 9 months ago.
>> Steve
>>>>> Paul Ramsey <pramsey at refractions.net> 11/12/06 11:38 PM >>>
>> Perhaps more back-story is required... why isn't the change just   
>> going into vanilla GD?
>> P
>> On 12-Nov-06, at 9:27 PM, Steve Lime wrote:
>>> Hi all: I've been putzing around with bug 1957 testing. It's a  
>>> problem
>>> with GD where it's clipping too soon with brushed lines which leaves
>>> artifacts along image edges. The wider the line the more obvious the
>>> artifact. Plays havoc when tiling. Anyway, on a whim I installed the
>>> version of GD that Autodesk updated as part of MapGuide figuring  
>>> they
>>> must have seen this behavior. They did and that code works great, no
>>> artifacts.
>>>
>>> So, what to do next? I don't want to have to fix GD yet again and  
>>> I  know
>>> Bob and Gary had always intended to contribute their GD  
>>> modifications
>>> back to that project. I'm wondering about the possiblity of de-  
>>> coupling
>>> the Autodesk version of GD from MapGuide for a broader distribution-
>>> sort of an OSGeo-branded GD. What do folks think?
>>>
>>> Steve
>