Version: (using Devel) Installed from: Compiled sources OS: Other GraphicsMagick 1.2.X is released and is not 100% API compatible with GraphicsMagick 1.1.X. Some long deprecated macros and functions (deprecated before GraphicsMagick existed) were removed. Most significantly the complex profiles data structure has been removed from Image and replaced with a general purpose accessor/iterator API. Given the significant performance, quality, and security improvements in GraphicsMagick 1.2.X, I expect that KDE will want to support it as soon as is reasonably possible. This chunk of compiler error output was provided by someone who attempted to build Krita using GraphicsMagick 1.2.1: 031 if /bin/sh ../../../libtool --silent --tag=CXX --mode=compile i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I. -I../../../lib/kofficeui -I../../../lib/kofficeui -I../../../lib/kofficecore -I../../../lib/kofficecore -I../../../lib/store -I../../../lib/store -I../../../lib/kwmf -I../../../lib/kwmf -I../../../lib/kopalette -I../../../lib/kopalette -I../../../krita -I../../../krita/core -I../../../krita/sdk -I../../../krita/core/tiles -I../../../krita/kritacolor -I../../../krita/ui -I../../../lib/kofficeui -I../../../lib/kofficeui -I../../../lib/kofficecore -I../../../lib/kofficecore -I../../../lib/store -I../../../lib/store -I../../../lib/kwmf -I../../../lib/kwmf -I../../../lib/kopalette -I../../../lib/kopalette -I../../../lib/interfaces -I../../../lib/kopainter -I../../../lib/kopainter -I/usr/include/GraphicsMagick -I/usr/lib/qt-3.3/include -I. -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O3 -march=i686 -mtune=i686 -m32 -fomit-frame-pointer -maccumulate-outgoing-args -pipe -fPIC -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DHAVE_KNEWSTUFF -fexceptions -MT kis_image_magick_converter.lo -MD -MP -MF ".deps/kis_image_magick_converter.Tpo" -c -o kis_image_magick_converter.lo kis_image_magick_converter.cc; \ 032 then mv -f ".deps/kis_image_magick_converter.Tpo" ".deps/kis_image_magick_converter.Plo"; else rm -f ".deps/kis_image_magick_converter.Tpo"; exit 1; fi 033 kis_image_magick_converter.cc: In function 'void<unnamed>::setAnnotationsForImage(const Image*, KisImageSP)': 034 kis_image_magick_converter.cc:185: error: 'const struct _Image' has no member named 'generic_profiles' 035 kis_image_magick_converter.cc:189: error: 'const struct _Image' has no member named 'generic_profile' 036 kis_image_magick_converter.cc:189: error: 'const struct _Image' has no member named 'generic_profile' 037 kis_image_magick_converter.cc:191: error: 'const struct _Image' has no member named 'generic_profile' 038 kis_image_magick_converter.cc: In member function 'KisImageBuilder_Result KisImageMagickConverter::decode(const KURL&, bool)': 039 kis_image_magick_converter.cc:483: error: 'Downscale' was not declared in this scope 040 kis_image_magick_converter.cc:537: error: 'Downscale' was not declared in this scope 041 kis_image_magick_converter.cc:581: error: 'Downscale' was not declared in this scope 042 kis_image_magick_converter.cc:611: error: 'Downscale' was not declared in this scope 043 kis_image_magick_converter.cc: In member function 'KisImageBuilder_Result KisImageMagickConverter::buildFile(const KURL&, KisPaintLayerSP, KSharedPtr<KisAnnotation>*, KSharedPtr<KisAnnotation>*)': 044 kis_image_magick_converter.cc:815: error: 'Upscale' was not declared in this scope 045 kis_image_magick_converter.cc:851: error: 'Upscale' was not declared in this scope 046 kis_image_magick_converter.cc:882: error: 'Upscale' was not declared in this scope 047 kis_image_magick_converter.cc: In static member function 'static QString KisImageMagickConverter::readFilters()': 048 kis_image_magick_converter.cc:993: warning: unused variable 'matches' 049 kis_image_magick_converter.cc: In static member function 'static QString KisImageMagickConverter::writeFilters()': 050 kis_image_magick_converter.cc:1067: warning: unused variable 'matches' 051 make[4]: *** [kis_image_magick_converter.lo] Error 1
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.