Re: UPDATE: graphics/GraphicsMagick
GraphicsMagick update to 1.3.3: http://www.demirmen.com/~okan/GraphicsMagick-1.3.3.diff Great work, thanks! koffice bit with kili's patch for GM 1.3.3: http://www.demirmen.com/~okan/koffice-GM-1.3.3.diff While we've found no regressions so far, neither of us are KDE/koffice users; please test and comment - Thanks. Daniel -- LEVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: UPDATE: graphics/GraphicsMagick
GraphicsMagick update to 1.3.3: http://www.demirmen.com/~okan/GraphicsMagick-1.3.3.diff koffice bit with kili's patch for GM 1.3.3: http://www.demirmen.com/~okan/koffice-GM-1.3.3.diff While we've found no regressions so far, neither of us are KDE/koffice users; please test and comment - Thanks. Cheers, Okan
Re: UPDATE: graphics/GraphicsMagick
On Sun, Dec 07, 2008 at 01:21:51PM -0500, Okan Demirmen wrote:
Fix koffice to work with latest GraphicsMagick?
Please do.
[...]
i'm not interested in krita, nor do i have the time to invest in it
right now. of course, others are more than welcome to do so :)
Untested (I don't even know how to use this krita filter). I built
it against GraphicsMagick-1.2.6, but it should as well build against
the (older) version we currently have in ports.
Ciao,
Kili
Index: Makefile
===
RCS file: /cvs/ports/x11/kde/office3/Makefile,v
retrieving revision 1.53
diff -u -p -r1.53 Makefile
--- Makefile20 Nov 2008 13:40:48 - 1.53
+++ Makefile17 Dec 2008 17:29:33 -
@@ -8,7 +8,7 @@ VMEM_WARNING= Yes
MASTER_SITES?=
${MASTER_SITE_KDE:s...@$@stable/koffice-${VERSION}/src/@}
DISTNAME= koffice-${VERSION}
-PKGNAME= ${DISTNAME}p5
+PKGNAME= ${DISTNAME}p6
MASTER_SITES0= ftp://ftp.kde.org/pub/kde/security_patches/
PATCHFILES=koffice-xpdf-CVE-2007-3387.diff:0 \
Index: patches/patch-filters_krita_gmagick_kis_image_magick_converter_cc
===
RCS file: patches/patch-filters_krita_gmagick_kis_image_magick_converter_cc
diff -N patches/patch-filters_krita_gmagick_kis_image_magick_converter_cc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-filters_krita_gmagick_kis_image_magick_converter_cc 17 Dec
2008 17:29:33 -
@@ -0,0 +1,153 @@
+$OpenBSD$
+--- filters/krita/gmagick/kis_image_magick_converter.cc.orig Wed May 30
23:39:37 2007
filters/krita/gmagick/kis_image_magick_converter.ccMon Dec 15
23:10:01 2008
+@@ -168,32 +168,22 @@ namespace {
+
+ void setAnnotationsForImage(const Image * src, KisImageSP image)
+ {
++ ImageProfileIterator ipi;
++ const char *name;
++ const unsigned char *profiledata;
+ size_t length;
+
+-const unsigned char * profiledata = GetImageProfile(src, IPTC,
length);
+-if( profiledata != NULL )
+-{
++ ipi = AllocateImageProfileIterator(src);
++ while (NextImageProfile(ipi, name, profiledata, length) !=
MagickFail) {
+ QByteArray rawdata;
+ rawdata.resize(length);
+ memcpy(rawdata.data(), profiledata, length);
+-
+-KisAnnotation* annotation = new KisAnnotation(QString(IPTC),
, rawdata);
++KisAnnotation* annotation = new KisAnnotation(QString(name), ,
rawdata);
+ Q_CHECK_PTR(annotation);
+-
+ image - addAnnotation(annotation);
+-}
+-for(int i = 0; i src-generic_profiles; i++)
+-{
+-QByteArray rawdata;
+-rawdata.resize(length);
+-memcpy(rawdata.data(), src-generic_profile[i].info,
src-generic_profile[i].length);
+-
+-KisAnnotation* annotation = new
KisAnnotation(QString(src-generic_profile[i].name), , rawdata);
+-Q_CHECK_PTR(annotation);
++ }
++ DeallocateImageProfileIterator(ipi);
+
+-image - addAnnotation(annotation);
+-}
+-
+ const ImageAttribute* imgAttr = GetImageAttribute(src, NULL);
+ while(imgAttr)
+ {
+@@ -480,7 +470,7 @@ KisImageBuilder_Result KisImageMagickConverter::decode
+ Q_UINT8 opacity = OPACITY_OPAQUE;
+ const ImageAttribute * attr = GetImageAttribute(image,
[layer-opacity]);
+ if (attr != 0) {
+-opacity = Q_UINT8_MAX -
Downscale(QString(attr-value).toInt());
++opacity = Q_UINT8_MAX -
ScaleQuantumToChar(QString(attr-value).toInt());
+ }
+
+ KisPaintLayerSP layer = 0;
+@@ -534,17 +524,17 @@ KisImageBuilder_Result KisImageMagickConverter::decode
+ while (!hiter.isDone())
+ {
+ Q_UINT8 *ptr= hiter.rawData();
+-*(ptr++) = Downscale(pp-red); // cyan
+-*(ptr++) = Downscale(pp-green); // magenta
+-*(ptr++) = Downscale(pp-blue); // yellow
+-*(ptr++) = Downscale(indexes[x]); // Black
++*(ptr++) = ScaleQuantumToChar(pp-red); // cyan
++*(ptr++) = ScaleQuantumToChar(pp-green); //
magenta
++*(ptr++) = ScaleQuantumToChar(pp-blue); // yellow
++*(ptr++) = ScaleQuantumToChar(indexes[x]); //
Black
+ // XXX: Warning! This ifdef messes up the paren matching big-time!
+ #ifdef HAVE_MAGICK6
+ if (image-matte != MagickFalse) {
+ #else
+ if (image-matte == true) {
+ #endif
+-*(ptr++) = OPACITY_OPAQUE -
Downscale(pp-opacity);
++*(ptr++)
Re: UPDATE: graphics/GraphicsMagick
On Thu 2008.12.04 at 18:26 -0500, Brad wrote: On Thursday 04 December 2008 18:16:32 Matthias Kilian wrote: On Wed, Dec 03, 2008 at 04:41:04PM +0100, L?VAI D?niel wrote: at least we don't break the current koffice3, for now. Now I really think we should go down the road you have proposed earlier: Making a 1.1.x/ dir for mainting compatibility with koffice 1.6, and a 1.3.x for the latest stable. What do you think? ewww. I would very much prefer NOT going down that road. i too would not prefer that route, but... Fix koffice to work with latest GraphicsMagick? Please do. that's the right thing, i agree. according to various lists and bug reports on this very issue on kde sites, there is no interest for re-doing the krita filters that use the older GraphicsMagick API; they have admitted that they did not use the correct (public) API, so it is much more of an overhaul than they are willing to do for 1.6x, especially when it seems the 2.x branch is more interesting to those. i'm not interested in krita, nor do i have the time to invest in it right now. of course, others are more than welcome to do so :)
Re: UPDATE: graphics/GraphicsMagick
On Wed 2008.12.03 at 16:41 +0100, L?VAI D?niel wrote: On Tuesday 02 December 2008 03.41.51 Okan Demirmen wrote: seems i've missed a bit here while away... 2 things: koffice 1.6 branch does not support newer GraphicsMagick versions. i still don't understand the no_gs thing. as kili pointed out, it can be pinned down to removing the run dependency of ghostscript, but why? for example, GraphicsMagick supports RAW images, hence a build dependency on dcraw - should we force the user to read the output of gm error messages to guess which additional package one needs to install to get the compiled-in functionality? i'm of the opinion 'no'. same goes with the gs binary being available if the package has been built to support it. What are you suggesting? maybe i used too many words ;) what i'm really asking is: what is the big deal of having ghostscript as a RUN_DEPENDS? if the port is built with ghostscript support, shouldn't it just work when installed? cheers, okan
Re: UPDATE: graphics/GraphicsMagick
On Wed, Dec 03, 2008 at 04:41:04PM +0100, LÉVAI Dániel wrote: at least we don't break the current koffice3, for now. Now I really think we should go down the road you have proposed earlier: Making a 1.1.x/ dir for mainting compatibility with koffice 1.6, and a 1.3.x for the latest stable. What do you think? Fix koffice to work with latest GraphicsMagick?
Re: UPDATE: graphics/GraphicsMagick
On Thursday 04 December 2008 18:16:32 Matthias Kilian wrote: On Wed, Dec 03, 2008 at 04:41:04PM +0100, LÉVAI Dániel wrote: at least we don't break the current koffice3, for now. Now I really think we should go down the road you have proposed earlier: Making a 1.1.x/ dir for mainting compatibility with koffice 1.6, and a 1.3.x for the latest stable. What do you think? ewww. I would very much prefer NOT going down that road. Fix koffice to work with latest GraphicsMagick? Please do. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: UPDATE: graphics/GraphicsMagick
On Tuesday 02 December 2008 03.41.51 Okan Demirmen wrote: seems i've missed a bit here while away... 2 things: koffice 1.6 branch does not support newer GraphicsMagick versions. i still don't understand the no_gs thing. as kili pointed out, it can be pinned down to removing the run dependency of ghostscript, but why? for example, GraphicsMagick supports RAW images, hence a build dependency on dcraw - should we force the user to read the output of gm error messages to guess which additional package one needs to install to get the compiled-in functionality? i'm of the opinion 'no'. same goes with the gs binary being available if the package has been built to support it. What are you suggesting? in any case, i think we should at least update to the latest 1.1.14 release. i've kept the changes i made to make the port more like ImageMagick; additionally, this builds the perl module and brings in libwmf. True. at least we don't break the current koffice3, for now. Now I really think we should go down the road you have proposed earlier: Making a 1.1.x/ dir for mainting compatibility with koffice 1.6, and a 1.3.x for the latest stable. What do you think? Daniel -- LEVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: UPDATE: graphics/GraphicsMagick
Matthias Kilian wrote: On Sun, Nov 30, 2008 at 09:10:16PM +0100, LÉVAI Dániel wrote: No. All you need is a global BUILD_DEPENDS= :ghostscript-*:print/ghostscript/gnu regardless of no_x11 or not. The whole purpose of this dependency is to always get the same delegates.mgk that uses pnmraw for gs-color. The difference between a GraphicsMagick package with FLAVOR=no_gs and without it would be nothing except the latter would have a run dependency on ghostscript. And since there's no need for a run dependency at all, there would be absolutely no difference. Got it. Thanks for your patience (of which I think I've used all :) http://leva.ecentrum.hu/patches/GraphicsMagick_1.2.6.diff Daniel -- LEVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: UPDATE: graphics/GraphicsMagick
seems i've missed a bit here while away... 2 things: koffice 1.6 branch does not support newer GraphicsMagick versions. i still don't understand the no_gs thing. as kili pointed out, it can be pinned down to removing the run dependency of ghostscript, but why? for example, GraphicsMagick supports RAW images, hence a build dependency on dcraw - should we force the user to read the output of gm error messages to guess which additional package one needs to install to get the compiled-in functionality? i'm of the opinion 'no'. same goes with the gs binary being available if the package has been built to support it. is this a route any one wants to go down? in any case, i think we should at least update to the latest 1.1.14 release. i've kept the changes i made to make the port more like ImageMagick; additionally, this builds the perl module and brings in libwmf. at least we don't break the current koffice3, for now. http://www.demirmen.com/~okan/GraphicsMagick-1.1.14.diff cheers, okan
Re: UPDATE: graphics/GraphicsMagick
On Saturday 29 November 2008 22.36.56 Matthias Kilian wrote: On Sat, Nov 29, 2008 at 10:08:12AM -0500, Okan Demirmen wrote: Oh, and I see that GraphicsMagick doesn't recommend gslib, so maybe we should just disable that by default instead of making it a FLAVOR; FYI: only the gtk flavor of ghostscript contains libgs, so a GraphicsMagick flavor depending on libgs (i.e. --with-gslib) would have to explicitely depend on ghostscript's gtk flavor. So, please just keep the CONFIGURE_ARGS += --without-gslib in GraphicsMagick. Then the port now is broken, because no matter what, GraphicsMagick picks up ghostscript. So keeping CONFIGURE_ARGS += --without-gslib only matters if we also remove the BUILD_DEPENDS+= :ghostscript-*:print/ghostscript/gnu[,no_x11] RUN_DEPENDS+= :ghostscript-*:print/ghostscript/gnu[,no_x11] lines. Daniel -- LEVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: UPDATE: graphics/GraphicsMagick
On Sun, Nov 30, 2008 at 09:35:17AM +0100, LÉVAI Dániel wrote: FYI: only the gtk flavor of ghostscript contains libgs, so a GraphicsMagick flavor depending on libgs (i.e. --with-gslib) would have to explicitely depend on ghostscript's gtk flavor. So, please just keep the CONFIGURE_ARGS += --without-gslib in GraphicsMagick. Then the port now is broken, because no matter what, GraphicsMagick picks up ghostscript. So keeping CONFIGURE_ARGS += --without-gslib only matters if we also remove the BUILD_DEPENDS+= :ghostscript-*:print/ghostscript/gnu[,no_x11] RUN_DEPENDS+= :ghostscript-*:print/ghostscript/gnu[,no_x11] lines. No, --without-gslib just ensures that GraphicsMagick isn't linked against libgs, even if libgs is available. It does *not* stop GraphicsMagick from using the ghostscript binary at runtime (for whatever purpose; I didn't yet have the time to look at GraphicsMagick). Ciao, Kil
Re: UPDATE: graphics/GraphicsMagick
On Sunday 30 November 2008 11.08.25 Matthias Kilian wrote: On Sun, Nov 30, 2008 at 09:35:17AM +0100, LÉVAI Dániel wrote: FYI: only the gtk flavor of ghostscript contains libgs, so a GraphicsMagick flavor depending on libgs (i.e. --with-gslib) would have to explicitely depend on ghostscript's gtk flavor. So, please just keep the CONFIGURE_ARGS += --without-gslib in GraphicsMagick. Then the port now is broken, because no matter what, GraphicsMagick picks up ghostscript. So keeping CONFIGURE_ARGS += --without-gslib only matters if we also remove the BUILD_DEPENDS+= :ghostscript-*:print/ghostscript/gnu[,no_x11] RUN_DEPENDS+= :ghostscript-*:print/ghostscript/gnu[,no_x11] lines. No, --without-gslib just ensures that GraphicsMagick isn't linked against libgs, even if libgs is available. It does *not* stop GraphicsMagick from using the ghostscript binary at runtime (for whatever purpose; I didn't yet have the time to look at GraphicsMagick). Aha! I can see clearly now :) In the spirit of that, it's a new patch: http://leva.ecentrum.hu/patches/GraphicsMagick_1.2.6+no_gs.diff Daniel -- LEVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: UPDATE: graphics/GraphicsMagick
On Sun, Nov 30, 2008 at 11:30:06AM +0100, LÉVAI Dániel wrote: Then the port now is broken, because no matter what, GraphicsMagick picks up ghostscript. So keeping CONFIGURE_ARGS += --without-gslib only matters if we also remove the BUILD_DEPENDS+= :ghostscript-*:print/ghostscript/gnu[,no_x11] RUN_DEPENDS+= :ghostscript-*:print/ghostscript/gnu[,no_x11] lines. No, --without-gslib just ensures that GraphicsMagick isn't linked against libgs, even if libgs is available. It does *not* stop GraphicsMagick from using the ghostscript binary at runtime (for whatever purpose; I didn't yet have the time to look at GraphicsMagick). Aha! I can see clearly now :) In the spirit of that, it's a new patch: http://leva.ecentrum.hu/patches/GraphicsMagick_1.2.6+no_gs.diff After a closer look at configure.ac and at the source trees after make configure (with ghostscript installed and uninstalled), I think you really don't need the no_gs flavor. The only relevant part that of GraphicsMagick that will be different is delegates.mgk, and it only differs in what ghostscript device will be used for the gs-color delegate (pnmraw vs. ppmraw). So you can omit the no_gs flavor and drop the RUN_DEPENDS on ghostscript (but not the BUILD_DEPENDS). Then you'll just get an error message whenever ghostscript isn't installed and GraphicsMagick needs a gs-* delegate: $ gm display tiger.eps sh: gs: not found gm display: gs -q -dBATCH -dMaxBitmap=5000 -dNOPAUSE -sDEVICE=pnmraw -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -g661x682 -r86.4681x86.4106 -sOutputFile=/tmp/gmLXBB5a -- /tmp/gmD -c quit. sh: gs: not found gm display: gs -q -dBATCH -dMaxBitmap=5000 -dNOPAUSE -sDEVICE=pnmraw -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -g661x682 -r86.4681x86.4106 -sOutputFile=/tmp/gmLXBB5a -- /tmp/gmD -c quit. gm display: DPS library is not available (tiger.eps). Ciao, Kili -- Now I remember why I don't remember the last time I finished a bottle of this shit. -- Mike Erdely, about Gulden Draak
Re: UPDATE: graphics/GraphicsMagick
On Sunday 30 November 2008 12.59.51 Matthias Kilian wrote: On Sun, Nov 30, 2008 at 11:30:06AM +0100, LÉVAI Dániel wrote: Then the port now is broken, because no matter what, GraphicsMagick picks up ghostscript. So keeping CONFIGURE_ARGS += --without-gslib only matters if we also remove the BUILD_DEPENDS+= :ghostscript-*:print/ghostscript/gnu[,no_x11] RUN_DEPENDS+= : :ghostscript-*:print/ghostscript/gnu[,no_x11] lines. No, --without-gslib just ensures that GraphicsMagick isn't linked against libgs, even if libgs is available. It does *not* stop GraphicsMagick from using the ghostscript binary at runtime (for whatever purpose; I didn't yet have the time to look at GraphicsMagick). Aha! I can see clearly now :) In the spirit of that, it's a new patch: http://leva.ecentrum.hu/patches/GraphicsMagick_1.2.6+no_gs.diff After a closer look at configure.ac and at the source trees after make configure (with ghostscript installed and uninstalled), I think you really don't need the no_gs flavor. The only relevant part that of GraphicsMagick that will be different is delegates.mgk, and it only differs in what ghostscript device will be used for the gs-color delegate (pnmraw vs. ppmraw). So you can omit the no_gs flavor and drop the RUN_DEPENDS on ghostscript (but not the BUILD_DEPENDS). You mean to leave the BUILD_DEPENDS only if we are not building a no_x11 FLAVOR, I presume? Daniel -- LEVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: UPDATE: graphics/GraphicsMagick
On Sun, Nov 30, 2008 at 02:18:26PM +0100, LÉVAI Dániel wrote: After a closer look at configure.ac and at the source trees after make configure (with ghostscript installed and uninstalled), I think you really don't need the no_gs flavor. The only relevant part that of GraphicsMagick that will be different is delegates.mgk, and it only differs in what ghostscript device will be used for the gs-color delegate (pnmraw vs. ppmraw). So you can omit the no_gs flavor and drop the RUN_DEPENDS on ghostscript (but not the BUILD_DEPENDS). You mean to leave the BUILD_DEPENDS only if we are not building a no_x11 FLAVOR, I presume? No. All you need is a global BUILD_DEPENDS= :ghostscript-*:print/ghostscript/gnu regardless of no_x11 or not. The whole purpose of this dependency is to always get the same delegates.mgk that uses pnmraw for gs-color. Ciao, Kili
Re: UPDATE: graphics/GraphicsMagick
On Sunday 30 November 2008 19.22.22 Matthias Kilian wrote: On Sun, Nov 30, 2008 at 02:18:26PM +0100, LÉVAI Dániel wrote: After a closer look at configure.ac and at the source trees after make configure (with ghostscript installed and uninstalled), I think you really don't need the no_gs flavor. The only relevant part that of GraphicsMagick that will be different is delegates.mgk, and it only differs in what ghostscript device will be used for the gs-color delegate (pnmraw vs. ppmraw). So you can omit the no_gs flavor and drop the RUN_DEPENDS on ghostscript (but not the BUILD_DEPENDS). You mean to leave the BUILD_DEPENDS only if we are not building a no_x11 FLAVOR, I presume? No. All you need is a global BUILD_DEPENDS= :ghostscript-*:print/ghostscript/gnu regardless of no_x11 or not. The whole purpose of this dependency is to always get the same delegates.mgk that uses pnmraw for gs-color. But the whole point of the no_gs FLAVOR was that if one doesn't need ghostscript, then don't install it with GM (ie. don't make gs mandatory for GM). With your proposal, gs would always get installed, no matter what... And it's no use either to put that BUILD_DEPENDS only outside FLAVOR:no_x11, because if one already has a no_x11 FLAVORed ghostscript installed, then building an x11 enabled GraphicsMagick would want to install an x11 enabled ghostscript, which is certainly not what the user wanted in the first place. So with the no_gs FLAVOR added, one could build an x11 enabled GM, and can also have a no_x11 FLAVORed ghostscript side-by-side. Besides, one could of course build an x11 and gs free GM too, with FLAVOR=no_gs no_x11. Hope I'm making sense, and please correct me if I'm wrong! Daniel -- LEVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: UPDATE: graphics/GraphicsMagick
On Sun, Nov 30, 2008 at 09:10:16PM +0100, LÉVAI Dániel wrote: No. All you need is a global BUILD_DEPENDS= :ghostscript-*:print/ghostscript/gnu regardless of no_x11 or not. The whole purpose of this dependency is to always get the same delegates.mgk that uses pnmraw for gs-color. But the whole point of the no_gs FLAVOR was that if one doesn't need ghostscript, then don't install it with GM (ie. don't make gs mandatory for GM). With your proposal, gs would always get installed, no matter what... No, it wouldn't. It's just a BUILD dependency. People can install GraphicsMagick without having to install ghostscript, and you can pkg_delete ghostscript after building GraphicsMagick. And it's no use either to put that BUILD_DEPENDS only outside FLAVOR:no_x11, because if one already has a no_x11 FLAVORed ghostscript installed, then building an x11 enabled GraphicsMagick would want to install an x11 enabled ghostscript, which is certainly not what the user wanted in the first place. No, having any flavor of ghostscript installed is enough to satisfy the BUILD_DEPENDS. So with the no_gs FLAVOR added, one could build an x11 enabled GM, and can also have a no_x11 FLAVORed ghostscript side-by-side. Besides, one could of course build an x11 and gs free GM too, with FLAVOR=no_gs no_x11. Repeating myself: when building GraphicsMagick, with or without your no_gs flavor, and with or without ghostscript installed, the *only* difference on the installed files is delegates.mgk, and it looks like this: --- /usr/local/lib/GraphicsMagick/config/delegates.mgk Sun Nov 30 12:03:18 2008 +++ delegates.mgk Sun Nov 30 11:51:56 2008 @@ -83,7 +83,7 @@ delegate decode=fig command='fig2dev -L ps %i %o' / delegate decode=gplt command='echo set size 1.25,0.62; set terminal postscript portrait color solid; set output %o; load %i %u; gnuplot %u' / !-- Read color Postscript, EPS, and PDF -- - delegate decode=gs-color stealth=True command='gs -q -dBATCH -dMaxBitmap=5000 -dNOPAUSE -sDEVICE=pnmraw -dTextAlphaBits=%u -dGraphicsAlphaBits=%u -g%s -r%s %s -sOutputFile=%s -- %s -c quit' / + delegate decode=gs-color stealth=True command='gs -q -dBATCH -dMaxBitmap=5000 -dNOPAUSE -sDEVICE=ppmraw -dTextAlphaBits=%u -dGraphicsAlphaBits=%u -g%s -r%s %s -sOutputFile=%s -- %s -c quit' / !-- Read monochrome Postscript, EPS, and PDF -- delegate decode=gs-mono stealth=True command='gs -q -dBATCH -dMaxBitmap=5000 -dNOPAUSE -sDEVICE=pbmraw -dTextAlphaBits=%u -dGraphicsAlphaBits=%u -g%s -r%s %s -sOutputFile=%s -- %s -c quit' / delegate decode=hpg command='hp2xx -q -m eps -f `basename %o` %i mv -f `basename %o` %o' / The difference between a GraphicsMagick package with FLAVOR=no_gs and without it would be nothing except the latter would have a run dependency on ghostscript. And since there's no need for a run dependency at all, there would be absolutely no difference. If you don't believe me, do what I did: - run make fake on GraphicsMagick with and without FLAVOR=no_gs. - save or rename the WRKDIRs. - temporarily move ghostscript out of scope, or pkg_delete it and comment the BUILD_ and RUN_DEPENDS from GraphicsMagick. - again run make fake on GraphicsMagick with and without FLAVOR=no_gs. - compare the contents of the saved and new WRKDIRs against each other. Ciao, Kili
Re: UPDATE: graphics/GraphicsMagick
On Sat 2008.11.29 at 11:39 +0100, L?VAI D?niel wrote: Hi! It [1] is basically Okan's patch (sorry, but i only found your post recently); I've changed VERSION from 1.2.5 to 1.2.6, and added a no_gs FLAVOR. Also note, that now if one builds it with x11 (ie. not specifing FLAVOR=no_x11) it depends on graphics/libwmf, and will automatically pick up ghostscript (if FLAVOR=no_gs is not specified). Also, patches and PLISTs were regenerated. Tried it out on i386 with gallery2, it works fine. Note: one file was removed from patches/, and one was added, so please use `patch -E`. Please test/comment, thanks! Hi, One major issue/reason for keeping the current GraphicsMagick is koffice3. I'm not sure we can simply drop the filter that is dependent on the old GraphicsMagick - I've looked into it some, but not enough; and koffice3 isn't going away anytime soon. Also note that GraphicsMagick 1.3.1 is out, the now current stable release. I know of at least one existing port that would benefit from a new GraphicsMagick, but I'm sure there are others. For what reason do you need an update - new port or such? Talking out loud, if there are many ports that would seriously benefit from switching to GraphicsMagick, from ImageMagick, maybe we could go down the route of splitting GraphicsMagick into 1.x/ and stable/, or something. Oh, and I see that GraphicsMagick doesn't recommend gslib, so maybe we should just disable that by default instead of making it a FLAVOR; then again, I wonder if we need a FLAVOR over a SUBPACKAGE - I clearly haven't looked ;) There are a few things to consider, hence my lagging on this port. Thanks for your interest though - opinions welcome ;) Cheers, Okan Daniel [1] - http://leva.ecentrum.hu/patches/GraphicsMagick_1.2.6+no_gs.diff -- LEVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: UPDATE: graphics/GraphicsMagick
On Saturday 29 November 2008 16.08.12 Okan Demirmen wrote: One major issue/reason for keeping the current GraphicsMagick is koffice3. I'm not sure we can simply drop the filter that is dependent on the old GraphicsMagick - I've looked into it some, but not enough; and koffice3 isn't going away anytime soon. What are the symptoms of koffice3 with newer GraphicsMagicks? Also note that GraphicsMagick 1.3.1 is out, the now current stable release. Yeah, I thought about it first, but then I thought there is a reason why you didn't make your patch for 1.3 (my best guess was because of the OpenMP support). I know of at least one existing port that would benefit from a new GraphicsMagick, but I'm sure there are others. For what reason do you need an update - new port or such? I needed the new version for gallery2 (which is not in ports, though). 1.2 has improved TIFF handling. Talking out loud, if there are many ports that would seriously benefit from switching to GraphicsMagick, from ImageMagick, I think every port can benefit from GraphicsMagick's stability and performance (over ImageMagick). maybe we could go down the route of splitting GraphicsMagick into 1.x/ and stable/, or something. Oh, and I see that GraphicsMagick doesn't recommend gslib, so maybe we should just disable that by default instead of making it a FLAVOR; I'm completely all right with that. Anyone using it, by the way? then again, I wonder if we need a FLAVOR over a SUBPACKAGE - I clearly haven't looked ;) There are a few things to consider, hence my lagging on this port. Thanks for your interest though - opinions welcome ;) [1] - http://leva.ecentrum.hu/patches/GraphicsMagick_1.2.6+no_gs.diff Daniel -- LEVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: UPDATE: graphics/GraphicsMagick
On Sat, Nov 29, 2008 at 10:08:12AM -0500, Okan Demirmen wrote: Oh, and I see that GraphicsMagick doesn't recommend gslib, so maybe we should just disable that by default instead of making it a FLAVOR; FYI: only the gtk flavor of ghostscript contains libgs, so a GraphicsMagick flavor depending on libgs (i.e. --with-gslib) would have to explicitely depend on ghostscript's gtk flavor. So, please just keep the CONFIGURE_ARGS += --without-gslib in GraphicsMagick. Ciao, Kili
