Bug 161770

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.