[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libgd-perl moving to PNG



David Huggins-Daines <dhd@eradicator.org> writes:

> On Sun, Dec 05, 1999 at 05:48:44PM -0500, Ben Pfaff wrote:
> > There's no good reason for libgd-perl to be in non-free, that I
> > can see.  The current bad reason for libgd-perl to be in non-free
> > is that it uses libgd from non-free (which would actually place
> 
> No, it doesn't actually.  It uses its own internal copy of the libgd (GIF)
> sources.

Okay, I was unaware of that.

> Part of the reason for moving to a newer version is that newer
> versions are able to link against the system's libgd library instead of
> compiling in their own version.

I see.  I didn't know that either.

> This internal version does LZW compression, unfortunately.  However, we
> could update it to match our current (free) libgd-gif1 package.
>
> This is obviously not what the upstream author wants, and if we do this, our
> package will remain several versions behind indefinitely.

That is obviously undesirable.

> > libgd-perl in contrib, go figure).  For its part, libgd is in
> > non-free because *older versions* had LZW compression code.
> 
> libgd is not in non-free.  Even before the one I just uploaded (1.7.3), it
> was already in main.

I stand corrected.

> > Newer versions of libgd use run-length compression instead, which
> > is not patented.
> 
> No, they produce PNG instead of GIF.  However there's libgd-gif now, which
> is probably what you're thinking of.  It's an older version of GD, after
> the removal of LZW but before the switch to PNG.

That is the one that I'm thinking of.  I haven't used the PNG
version of gd, since PNG is useless if you want to support the
most web browsers.  Not everyone runs an up-to-date
PNG-supporting browser, unfortunately.  If I started using PNGs
everywhere instead of GIFs then my users would complain loudly
until I changed back.

> > IMO, the proper solution is to release a libgd that supports
> > *BOTH* GIF and PNG, and I see no reason why this shouldn't or
> > couldn't be done.
> 
> It would be a fork.  The upstream author most definitely won't do it.

I still think it is a good idea.  If you're willing to take on
the project then I'd like to encourage it.  Depending on how
modular the libgd or libgd-perl code is, it might be a pretty
easy one-time thing to do, just re-applying the patch each time
the package is upgraded.  Of course it's not my package so I
won't try to tell you how to do it.  But it would definitely be a
convenience.


Reply to: