bug#14798: 24.3.50; Enable Imagemagick for Nextstep

bug#14798: 24.3.50; Enable Imagemagick for Nextstep

[Magnus Henoch]

Severity: wishlist
Tags: patch

As I'd like to be able to resize images in Emacs on Nextstep, I had a
look at what needs to be changed to enable Imagemagick on Nextstep.  Not
very much, it turns out; see diff below.

I'm not sure what it would take to support MagickExportImagePixels.  The
code tries to pass ximg->data as a parameter, but ximg is of type
XImagePtr, and on Nextstep the types are:

  typedef Pixmap XImagePtr;
  typedef void *Pixmap;

Nevertheless, it seems to work without that part.

Regards,
Magnus

diff --git a/configure.ac b/configure.ac
index baf8aab..0333898 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2041,7 +2041,7 @@ if test "${HAVE_X11}" = "yes" || test "${HAVE_NS}" = "yes" || test "${opsys}" =
 fi
 
 HAVE_IMAGEMAGICK=no
-if test "${HAVE_X11}" = "yes"; then
+if test "${HAVE_X11}" = "yes" || test "${HAVE_NS}" = "yes"; then
   if test "${with_imagemagick}" != "no"; then
     ## 6.2.8 is the earliest version known to work, but earlier versions
     ## might work - let us know if you find one.
diff --git a/src/image.c b/src/image.c
index a3e103f..a2328dc 100644
--- a/src/image.c
+++ b/src/image.c
@@ -8054,7 +8054,9 @@ imagemagick_load_image (struct frame *f, struct image *img,
 
   init_color_table ();
 
-#ifdef HAVE_MAGICKEXPORTIMAGEPIXELS
+  /* XXX: it might be easy to get this to work for NS as well.
+     Since ximg is void*, ximg->data is not defined. */
+#if defined(HAVE_MAGICKEXPORTIMAGEPIXELS) && !defined(HAVE_NS)
   if (imagemagick_render_type != 0)
     {
       /* Magicexportimage is normally faster than pixelpushing.  This

bug#14798: 24.3.50; Enable Imagemagick for Nextstep

[Jan Djärv]

Hello.

Checked in into trunk.

Thanks,

	Jan D.

5 jul 2013 kl. 02:05 skrev Magnus Henoch <magnus.henoch@gmail.com>:

> Severity: wishlist
> Tags: patch
> 
> As I'd like to be able to resize images in Emacs on Nextstep, I had a
> look at what needs to be changed to enable Imagemagick on Nextstep.  Not
> very much, it turns out; see diff below.
> 
> I'm not sure what it would take to support MagickExportImagePixels.  The
> code tries to pass ximg->data as a parameter, but ximg is of type
> XImagePtr, and on Nextstep the types are:
> 
>  typedef Pixmap XImagePtr;
>  typedef void *Pixmap;
> 
> Nevertheless, it seems to work without that part.
> 
> Regards,
> Magnus
> 
> diff --git a/configure.ac b/configure.ac
> index baf8aab..0333898 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2041,7 +2041,7 @@ if test "${HAVE_X11}" = "yes" || test "${HAVE_NS}" = "yes" || test "${opsys}" =
> fi
> 
> HAVE_IMAGEMAGICK=no
> -if test "${HAVE_X11}" = "yes"; then
> +if test "${HAVE_X11}" = "yes" || test "${HAVE_NS}" = "yes"; then
>   if test "${with_imagemagick}" != "no"; then
>     ## 6.2.8 is the earliest version known to work, but earlier versions
>     ## might work - let us know if you find one.
> diff --git a/src/image.c b/src/image.c
> index a3e103f..a2328dc 100644
> --- a/src/image.c
> +++ b/src/image.c
> @@ -8054,7 +8054,9 @@ imagemagick_load_image (struct frame *f, struct image *img,
> 
>   init_color_table ();
> 
> -#ifdef HAVE_MAGICKEXPORTIMAGEPIXELS
> +  /* XXX: it might be easy to get this to work for NS as well.
> +     Since ximg is void*, ximg->data is not defined. */
> +#if defined(HAVE_MAGICKEXPORTIMAGEPIXELS) && !defined(HAVE_NS)
>   if (imagemagick_render_type != 0)
>     {
>       /* Magicexportimage is normally faster than pixelpushing.  This
> 
> 

bug#14798: 24.3.50; Enable Imagemagick for Nextstep

[Glenn Morris]

It should be mentioned in NEWS that NS builds can now be built with
ImageMagick support. (Are there are any visible consequences to the
end-user due to MagickExportImagePixels not working; ie does that need
any documentation changes?)

bug#14798: 24.3.50; Enable Imagemagick for Nextstep

[Jan Djärv]

Hello.

8 jul 2013 kl. 18:28 skrev Glenn Morris <rgm@gnu.org>:

> 
> It should be mentioned in NEWS that NS builds can now be built with
> ImageMagick support.

Done.

> (Are there are any visible consequences to the
> end-user due to MagickExportImagePixels not working; ie does that need
> any documentation changes?)

No, it is just an optimization.

	Jan D.