GD 2.0.29 or more recent required for MapServer 4.9?

[dmorissette]

The recent labelling enhancements in v4.9 have introduced a requirement for GD
v2.0.29 or more recent. With older versions of GD you get:

maplabel.c: In function `msGetLabelSizeEx':
maplabel.c:420: error: `gdFTEX_XSHOW' undeclared (first use in this function)
maplabel.c:420: error: (Each undeclared identifier is reported only once
maplabel.c:420: error: for each function it appears in.)
maplabel.c:429: error: structure has no member named `xshow'
make: *** [maplabel.o] Error 1

The current configure script looks for GD 2.0.16 or more recent (test on
gdFontCacheSetup). We need to upgrade to look for GD 2.0.29 or more recent at
configure time.

I noticed in the docs a mention of a "gdlib-config" script. We should probably
start using it in the configure script as well instead of doing AC_CHECK_LIB()
hacks.

Before going ahead and modifying the configure script to require GD 2.0.29 or
more recent, can you (Steve) please confirm that this is what we want, and that
we do not want to provide a way for users of older GDs to disable the
gdFTEX_XSHOW option in their local build?

[sdlime]

Can you guys think of a reason we wouldn't want 2.0.29 as a minimum? Personally 
I can't and am fine with that requirement. Is that likely to cause any PHP 
heartburn?

Steve

[dmorissette]

Well, we all know that some Linux distros still ship relatively older versions
of some libs and forcing a recent version of GD may be a pain for some users who
cannot easily upgrade.

I'm fine with the 2.0.29 requirement if it adds some value, I just wanted to
make sure that was the plan before going ahead with the change.

[sdlime]

The curved labels will be a major reason to upgrade so it seems a reasonable 
requirement. I suppose we should check with Benj about how hard it would be to 
issolate the label following code. I think it would be a pain. Perhaps there is 
a workaround to msGetLabelSizeEx? I've cc'd him for comment.

Steve

[benjcarson@…]

So far the new function is only called once from the label path code.  It should
be fairly easy to isolate that call and to either fall back on ANGLE AUTO or to
use an approximation of msGetLabelSizeEx().  (This new function returns the
individual character offsets in a string as returned by FreeType.)  The
approximation could either determine the offset for each character using
multiple calls to the older GD functions (slow but accurate) or it could simply
assume that each character has the same width and divide the total width by the
number of characters (fast but inaccurate).


Benj

[dmorissette]

*** Bug 1808 has been marked as a duplicate of this bug. ***

[sdlime]

I took the easy way out. Label following isn't available without GD 2.0.29 or
higher. I really don't want to get into supporting a work around for older
versions. Version 2.0.29 is detected in the configure script by looking for a
particular function that appears first in that version. If a user tries to use
the FOLLOW keyword without the right version an error message is generated
telling them what minimum version is needed. I've tried with both pre and post
2.0.29 versions and all seems well.

Marking as fixed.

Steve

[dmorissette]

Thanks for taking care of this Steve. FYI I have added the following notes about
GD in the README.CONFIGURE:

  Version 2.0.16 or more recent is required, see http://www.boutell.com/gd/ .

  Version 2.0.29 or more recent is required for the LABEL FOLLOW option 
  to work (curved labels, added in 4.10).

  There is a bug in GD with 1 pixel antialiased lines that requires a
  patch that has not been released in GD yet. See bug 1612:
  http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1612