It won't be fixed in 1.6 (since there won't be a new release) but it will
definitively have to be fixed for 2.0. As different ABI version of a library
can be installed side by ide I don't expect a problem for distribution for the
time being.

not a koffice bug

Actually I disagree. The main problem is that we use private API of GM to
access profile data. And now that have hidden this even more :( But my take on
this is: will remain broken for the moment, and GM filters should be disable
when GM 1.2.X is found.

It is quite trivial to work around the profile access issue while using GM 1.1
APIs to do so.  This can be  done based on the knowledge that there are only a
few profile IDs which are normally supported: "8BIM", "ICM", "IPTC", "XMP". The
simple solution is to use GetImageProfile() in turn to request access to each
profile type. If NULL is returned, then the image does not contain that
profile.

Of course if there will never be another KDE release then there is no standard
way to distribute the fix.  This is quite unfortunate for GraphicsMagick users
since the slow adoption of newer KDE also slows the adoption of GraphicsMagick
1.2 (and soon 1.3) by a year or more.  There is four years of development
between the GM 1.1 and 1.2 releases.

In fact what we would need is NextImageProfile but it's not available in 1.1 :(
/me is going to resort to using #if )

I apologize for the API oversight in 1.1.X.  At least we got part of it right. 
The generic profile interface was a nightmare. The iterator interface
introduced in 1.2 should stand the test of time.

I just commited a change that should fix the compilation issue with GM 1.2, can
anyone with koffice/trunk and GM 1.2 confirm that now it compiles ? If it does,
I will make a patch for 1.6.x and offer it to packagers (we don't have the
manpower for a full 1.6 release, but still we don't want to prevent other
project to progress ;) )

SVN commit 879490 by berger:

an other attempt to check for version number, sounds like GM 1.2 has a smaller
version number than 1.1 (not sure if 1.3 will keep that trend too...)
CCBUG:161770



 M  +2 -1      kis_image_magick_converter.cc  


WebSVN link: http://websvn.kde.org/?view=rev&revision=879490

SVN commit 879499 by berger:

compilation fix
CCBUG:161770


 M  +1 -1      kis_image_magick_converter.cc  


WebSVN link: http://websvn.kde.org/?view=rev&revision=879499

SVN commit 879505 by berger:

++compilation
CCBUG:161770


 M  +1 -1      kis_image_magick_converter.cc  


WebSVN link: http://websvn.kde.org/?view=rev&revision=879505

If you can explain what you mean by "smaller version number" then surely I can
clear things up.  I don't see any smaller version numbers.  Here is the info
from magick/version.h:

From 1.1:
#define MagickLibVersion  0x0100014
#define MagickLibVersionText  "1.1.14"
#define MagickLibVersionNumber 1,0,14
#define MagickChangeDate   "20081102"
#define MagickReleaseDate  "2008-06-05"

From 1.2:
#define MagickLibVersion  0x020005
#define MagickLibVersionText  "1.2.5"
#define MagickLibVersionNumber 2,0,5
#define MagickChangeDate   "20081102"
#define MagickReleaseDate  "2008-07-25"

From development 1.3:
#define MagickLibVersion  0x030000
#define MagickLibVersionText  "1.3"
#define MagickLibVersionNumber 3,0,0
#define MagickChangeDate   "20081102"
#define MagickReleaseDate  "unreleased"

From the above, I think it is clear that MagickLibVersion is best to use in the
code when checking for baseline API features.  Due to continuing maintenance,
it is possible for the date of a lesser release to be greater than a more
modern one.

Bob

Hi Bob,

Well 0x0100014 > 0x020005, it's best seen that way:
0x0100014
0x020005
The last translate to
0x0020005

I wouldn't have noticed either ;) Unless the test had failed.

Well I guess it's a typo :/ That's why I usually prefer to divide a library
version number in 
LIBNAME_MAJOR
LIBNAME_MINOR
and LIBNAME_REVISION
And if someone trully need a single number, then construct the single number
from the three other number.

Ugh.  Here is how the value is computed in the GM configure script:

# Definition used to define MagickLibVersion in version.h
# As soon as any of these values exceeds 9, a more sophisticated formatting
# scheme must be invented for this string.
MAGICK_LIB_VERSION="0x0${MAGICK_LIBRARY_CURRENT}0${MAGICK_LIBRARY_AGE}0${MAGICK_LIBRARY_REVISION}"

Notice the comment about if a value exceeds 9 that a different formatting
scheme must be invented.  Apparently I never expected a release to be
maintained through so many minor iterations and I totally forgot about this
issue. This means that correct version numering was maintained until release
1.1.9, after which it became bogus.

Since these values are computed dynamically in the configure script I can't use
something convenient and unportable like shell sprintf.

As far as I know, it should be fixed.