Re: Consolidation of image support (was Re: Emacs on MAC OS X 10.3)

Re: Consolidation of image support (was Re: Emacs on MAC OS X 10.3)

[YAMAMOTO Mitsuharu]

>>>>> On 18 Dec 2003 01:53:20 +0100, Kim F. Storm said:

> Be aware that I plan (in the near future) to take out the image
> support code from xfns.c, w32fns.c and macfns.c and consolidate it in
> a new image.c file.  
> 
> That should reduce 15000 lines of code to approx 5500 lines.
> 
> It seems that most of the image code in macfns.c isn't actually
> used/ported yet, so it would be a good thing to consolidate the code
> before finishing the image support for MAC.

Actually, I've been porting the image support code to Carbon Emacs,
and I think it's almost ready now although some features are not
implemented yet.  I was planning to send the patch as soon as my
assignment paper is accepted, and currently I'm waiting for the form
to be delivered to me.  Should I send the patch now?  Many parts in
macfns.c is almost identical with those in xfns.c.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Consolidation of image support (was Re: Emacs on MAC OS X 10.3)

[Kim F. Storm]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> >>>>> On 18 Dec 2003 01:53:20 +0100, Kim F. Storm said:
> 
> > Be aware that I plan (in the near future) to take out the image
> > support code from xfns.c, w32fns.c and macfns.c and consolidate it in
> > a new image.c file.  
> > 
> > That should reduce 15000 lines of code to approx 5500 lines.
> > 
> > It seems that most of the image code in macfns.c isn't actually
> > used/ported yet, so it would be a good thing to consolidate the code
> > before finishing the image support for MAC.
> 
> Actually, I've been porting the image support code to Carbon Emacs,

That will make MAC users happy I suppose :-)

> and I think it's almost ready now although some features are not
> implemented yet.  I was planning to send the patch as soon as my
> assignment paper is accepted, and currently I'm waiting for the form
> to be delivered to me.  Should I send the patch now?  

No need to do so.

I don't expect to actually work on the consolidation until CVS is back
up again.  I want to be sure to get any fixes to that people -- like
yourself -- may have laying around waiting to be committed before I
start.

>                                                       Many parts in
> macfns.c is almost identical with those in xfns.c.

I would have expected that (otherwise there would be no reason to
consolidate the code :-)


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Image support for Carbon Emacs (Re: Consolidation of image support)

[YAMAMOTO Mitsuharu]

[-- Attachment #1: Type: Text/Plain, Size: 1901 bytes --]

>>>>> On Thu, 18 Dec 2003 22:57:00 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> Actually, I've been porting the image support code to Carbon Emacs,
> and I think it's almost ready now although some features are not
> implemented yet.  I was planning to send the patch as soon as my
> assignment paper is accepted, and currently I'm waiting for the form
> to be delivered to me. 

My assignment paper seems to be accepted.  Because I've never made
larger patches to emacs, I'd like to post the patch for comments, both
on style and code. (That was suggested by Kim F. Storm.  Thanks.)

  Current status:
  - I tested it on Mac OS X 10.1.5, 10.2.8, and 10.3.2.
  - Supported image types:
    XBM, PBM, PNG, JPEG, TIFF, and GIF are supported out of the box.
    XBM and PBM are self-contained as in other platforms.
    PNG (in 10.2 and 10.3) and JPEG use Quartz 2D functions.
    PNG (in 10.1), TIFF, and GIF use QuickTime Graphics Importers and
    Movie Toolbox.
    You can also use libpng and so on by defining some flags such as
    HAVE_PNG and providing libraries, but I don't recommend that and
    there is no support by configure.  (Actually, I used only these
    libraries in earlier versions.)
  - Unsupported image types: XPM and PostScript.
  - Stipples and color maps are not implemented.
  - Tool bar can be displayed with PBM images (try `M-x
    tool-bar-mode'), but no tooltips.
  - The patch includes changes about code conversions with respect
    to font names, which I posted to emacs-pretest-bug last year.
    http://mail.gnu.org/archive/html/emacs-pretest-bug/2003-01/msg00112.html
  - I also added some changes to make compilation with MPW-GM in Mac
    OS 9 successful.  But I cannot try to run it because it does not
    run on a machine with more than 256 MB of RAM as mac/INSTALL says.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

[-- Attachment #2: ChangeLog.bz2 --]
[-- Type: Application/Octet-Stream, Size: 3886 bytes --]

[-- Attachment #3: emacs-carbon-image-20040113.diff.bz2 --]
[-- Type: Application/Octet-Stream, Size: 45325 bytes --]

[-- Attachment #4: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[Stefan Monnier]

>     OS 9 successful.  But I cannot try to run it because it does not
>     run on a machine with more than 256 MB of RAM as mac/INSTALL says.

This limit should now be 512MB, by the way.  Maybe some Mac mode needs to
be fixed to accept upto 512MB before the mac/INSTALL file can be changed,
but at least the underlying limit has been bumped.


        Stefan

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[YAMAMOTO Mitsuharu]

>>>>> On 13 Jan 2004 10:55:09 -0500, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> OS 9 successful.  But I cannot try to run it because it does not
>> run on a machine with more than 256 MB of RAM as mac/INSTALL says.

> This limit should now be 512MB, by the way.  Maybe some Mac mode
> needs to be fixed to accept upto 512MB before the mac/INSTALL file
> can be changed, but at least the underlying limit has been bumped.

Thanks to your change on 2004-01-14, I could avoid a warning about
memory size by detaching a memory module from my laptop.  But I still
got "Error Type 2" and could not launch Emacs on Mac OS 9, and what is
worse, this error makes the operating system unstable.  I'm not
familiar with Mac OS 9 at all, so I don't think I can fix it soon.

Also, it is found that the changes of defines from HAVE_CARBON to
MAC_OS, which I made in my patch, did not reflect the intention of
these defines.

  http://mail.gnu.org/archive/html/emacs-devel/2003-03/msg00225.html

(The above is a post by Andrew Choi.  Kim F. Storm gave me a reference
to it.)  So it seems to be better to withdraw the changes about Mac OS
9 from my patch for now.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[Sébastien Kirche]

Do the patchs provided by Mitsuharu Yamamoto have been checked in ?

Sébastien Kirche

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[Steven Tamm]

They are currently waiting on the re-verification of legal papers.  
When that is done, they will be checked in as soon as possible.

-Steven

On Jan 28, 2004, at 4:48 AM, Sébastien Kirche wrote:

> Do the patchs provided by Mitsuharu Yamamoto have been checked in ?
>
> Sébastien Kirche
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[Kim F. Storm]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> >>>>> On Thu, 18 Dec 2003 22:57:00 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:
> 
> My assignment paper seems to be accepted.  Because I've never made
> larger patches to emacs, I'd like to post the patch for comments, both
> on style and code. (That was suggested by Kim F. Storm.  Thanks.)

I have looked briefly on the code, and overall it looks really good.

There are some things in the ChangeLogs which can be improved; see below.  

I cannot test your patch, but I suggest that you commit it, and see how
it is received (provided that you are prepared to handle the complaints
and bug reports :-)

When you commit your changes to CVS, pls. commit one file at a time, and
use the corresponding changelog entry for that file as cvs comment.

You should write a small entry for etc/NEWS.


Here are my comments on your change logs.  Note that the is is not a
complete list; there are other places that need similar changes.


	* dispextern.h: Change HAVE_CARBON to MAC_OS to cope with Mac OS
	8/9 version.

This applies to all of dispextern.h, so the following line is not needed:

	(struct glyph_string): Likewise.


	emacs.c (main): Likewise.
	frame.c (x_set_frame_parameters, x_report_frame_params)
	(x_set_fullscreen, x_set_border_width, Vdefault_frame_alist):
	Likewise.
	xdisp.c (define_frame_cursor1, expose_window, expose_frame):
	Likewise.

The above entries should be moved to the relevant file sections below.
For these, "Likewise" should be "Change HAVE_CARBON to MAC_OS".


	* macgui.h [MAC_OSX] (Carbon/Carbon.h): Add #include.
Change this to:
        * macgui.h [MAC_OSX]: Include Carbon/Carbon.h.



	[MAC_OSX] (mktime, DEBUG, Z, free, malloc, realloc, max, min)
	(init_process): Add #undef and #define enclosing the above #include

Move [MAX_OSX] to before the : and maybe simplify text to

	(mktime, DEBUG, Z, free, malloc, realloc, max, min)
	(init_process) [MAC_OSX] : Avoid conflicts with Carbon/Carbon.h.



	dispextern.h [MAC_OSX] (Carbon/Carbon.h): Remove #include and
	enclosing #undef and #define (now in macgui.h).
	macfns.c [MAC_OSX] (Carbon/Carbon.h): Likewise.
	macmenu.c [MAC_OSX] (Carbon/Carbon.h): Likewise.
	macterm.c [MAC_OSX] (Carbon/Carbon.h): Likewise.
	macterm.h [MAC_OSX] (Carbon/Carbon.h): Likewise.

Again, move these lines to the relevant file sections.
Also, simplify text to:
        [MAC_OSX] Do not include Carbon/Carbon.h (now in macgui.h).

	
	* macgui.h [!MAC_OSX] (QDOffscreen.h, Controls.h): Add #include.
Write: 
        * macgui.h [!MAC_OSX]: Include QDOffscreen.h and Controls.h.



	[MAC_OSX] (INFINITY): Add #undef to avoid the definition in math.h
Write:
	(INFINITY) [MAC_OSX]: Avoid conflict with definition in math.h.


	* macterm.h (RED16_FROM_ULONG, GREEN16_FROM_ULONG,
	BLUE16_FROM_ULONG): New #define to extract 16-bit depth color
Write:
	* macterm.h (RED16_FROM_ULONG, GREEN16_FROM_ULONG)
	(BLUE16_FROM_ULONG): New #define to extract 16-bit depth color



In the long list of changes for macfns.c and macterm.c, you don't need
to strictly follow the sequence of the code, so you can should collapse
similar entries like these [not the complete list]:
	
	(x_set_cursor_type): Sync with xfns.c.
	(x_make_gc): Sync with xfns.c but enclose unused `border_tile'
	with #if 0.
	(Fxw_color_values): Sync with xfns.c.
	(valid_image_p, image_value_type, parse_image_spec): Sync with
	xfns.c.
	(image_ascent): Sync with xfns.c.
	(x_clear_image, x_alloc_image_color): Sync with xfns.c.

into just one group:

	(x_set_cursor_type, x_make_gc, Fxw_color_values, valid_image_p)
        (image_value_type, parse_image_spec, image_ascent)
	(x_clear_image, x_alloc_image_color): Sync with xfns.c.

Likewise for "Add declaration", "New function (from xfns.c)", etc.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[Richard Stallman]

Do we currently have someone who wants to take care of maintaining
Emacs on Mac OS?

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[Steven Tamm]

If no one else wants to do it, I can maintain it.

-Steven

On Jan 15, 2004, at 1:22 PM, Richard Stallman wrote:

> Do we currently have someone who wants to take care of maintaining
> Emacs on Mac OS?
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[Richard Stallman]

    If no one else wants to do it, I can maintain it.

Apparently there is no one else.
As I recall, you have write access already, so how about
if you start installing Mac-specific patches as you see fit?

Re: Image support for Carbon Emacs

[Hans-Peter Binder]

* YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> Current status: - I tested it on Mac OS X 10.1.5, 10.2.8, and 10.3.2.
> - Supported image types: XBM, PBM, PNG, JPEG, TIFF, and GIF are

[...]

At first, thank you for your great work. I have applied the diff-file
to the current CVS-Emacs [14.01.2004] and have build a new Carbon
Emacs, (./configure --without-x) on OSX 10.2.8.

Image-Support works fine with Imagetypes XBM, PNG, JPEG, TIFF and GIF
in Emacs.

But when I try to view a PBM-File Emacs crashed. Any suggestions what I
can do.

CrashLog follows:

,----[ Emacs.crash.log ]
| **********
|
| Date/Time:  2004-01-16 01:40:44 +0100
| OS Version: 10.2.8 (Build 6R73)
| Host:       hyperion.mac
|
| Command:    Emacs
| PID:        1187
|
| Exception:  EXC_BAD_ACCESS (0x0001)
| Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x21f5c51c
|
| Thread 0 Crashed:
|  #0   0x91aa8244 in GetCPixel
|  #1   0x001360f8 in XGetPixel (macfns.c:598)
|  #2   0x00139984 in four_corners_best (macfns.c:4073)
|  #3   0x00139aa0 in image_background (macfns.c:4113)
|  #4   0x0013d710 in pbm_load (macfns.c:6934)
|  #5   0x0013a410 in lookup_image (macfns.c:4507)
|  #6   0x00019d90 in handle_single_display_prop (xdisp.c:3572)
|  #7   0x00019474 in handle_display_prop (xdisp.c:3286)
|  #8   0x000181ac in handle_stop (xdisp.c:2535)
|  #9   0x00017bcc in start_display (xdisp.c:2231)
|  #10  0x000460b4 in Frecenter (window.c:5127)
|  #11  0x000de12c in Ffuncall (eval.c:2729)
|  #12  0x0010d3f4 in Fbyte_code (bytecode.c:691)
|  #13  0x000de77c in funcall_lambda (eval.c:2920)
|  #14  0x000de294 in Ffuncall (eval.c:2785)
|  #15  0x000d9e5c in Fcall_interactively (callint.c:870)
|  #16  0x00082ffc in Fcommand_execute (keyboard.c:9654)
|  #17  0x00077a94 in command_loop_1 (keyboard.c:1757)
|  #18  0x000dbf70 in internal_condition_case (eval.c:1334)
|  #19  0x000767d4 in command_loop_2 (keyboard.c:1294)
|  #20  0x000db9dc in internal_catch (eval.c:1094)
|  #21  0x0007672c in command_loop (keyboard.c:1274)
|  #22  0x00076140 in recursive_edit_1 (keyboard.c:990)
|  #23  0x000762c8 in Frecursive_edit (keyboard.c:1046)
|  #24  0x00074db8 in main (emacs.c:1669)
|  #25  0x00003964 in _start (crt.c:267)
|  #26  0x000037e4 in start
|
| Thread 1:
|  #0   0x90073ba8 in mach_msg_trap
|  #1   0x90005ed0 in mach_msg
|  #2   0xc000a954 in __ape_internal
|  #3   0xc0001328 in __ape_agent
|  #4   0x90020c28 in _pthread_body
|
| PPC Thread State:
|   srr0: 0x91aa8244 srr1: 0x0000f930                vrsave: 0x00000000
|    xer: 0x00000000   lr: 0x91aa8200  ctr: 0x902216d0   mq: 0x00000000
|     r0: 0x00000000   r1: 0xbfffe230   r2: 0x91a78bb8   r3: 0x00000001
|     r4: 0xbfffe2f0   r5: 0x00c76920   r6: 0xbfffe270   r7: 0x00000000
|     r8: 0x00000020   r9: 0x21f5c51c  r10: 0x00000000  r11: 0x21f5c51c
|    r12: 0x902216d0  r13: 0x00000000  r14: 0xbfffefc4  r15: 0x00000001
|    r16: 0x00000004  r17: 0x00000000  r18: 0x00000030  r19: 0x02058780
|    r20: 0x00364860  r21: 0x00000000  r22: 0x00f0f8ff  r23: 0x00000030
|    r24: 0x0034d158  r25: 0x00000030  r26: 0x024ff8d0  r27: 0x00c76920
|    r28: 0xbfffe2f0  r29: 0xffffffff  r30: 0x00000000  r31: 0x0013d158
|
`----


Regards/Gruesse
Hans-Peter Binder
-- 
(coffee-mode -1)

Re: Image support for Carbon Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 16 Jan 2004 01:54:29 +0100, Hans-Peter Binder <macosx.pb@gmx.de> said:

> But when I try to view a PBM-File Emacs crashed.

Thanks for your experiment and report.  I could reproduce the problem
in Mac OS X 10.2.8.  In pbm_load, neither img->width nor img->height
are set before calling image_background, and that caused the crash.  I
think similar changes are also needed for xfns.c and w32fns.c.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

*** src/macfns.c-20040113	Tue Jan 13 17:38:05 2004
--- src/macfns.c	Fri Jan 16 13:03:32 2004
***************
*** 6926,6931 ****
--- 6926,6934 ----
    free_color_table ();
  #endif
  
+   img->width = width;
+   img->height = height;
+ 
    /* Maybe fill in the background field while we have ximg handy. */
    if (NILP (image_spec_value (img->spec, QCbackground, NULL)))
      IMAGE_BACKGROUND (img, f, ximg);
***************
*** 6933,6941 ****
    /* Put the image into a pixmap.  */
    x_put_x_image (f, ximg, img->pixmap, width, height);
    x_destroy_x_image (ximg);
- 
-   img->width = width;
-   img->height = height;
  
    UNGCPRO;
    xfree (contents);
--- 6936,6941 ----

Re: Image support for Carbon Emacs

[Hans-Peter Binder]

* YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>>>>>> On Fri, 16 Jan 2004 01:54:29 +0100, Hans-Peter Binder
>>>>>> <macosx.pb@gmx.de> said:
>
>> But when I try to view a PBM-File Emacs crashed.
>
> Thanks for your experiment and report.  I could reproduce the problem
> in Mac OS X 10.2.8.  In pbm_load, neither img->width nor img->height
> are set before calling image_background, and that caused the crash.  I
> think similar changes are also needed for xfns.c and w32fns.c.

Thanks for your Reply. After I have applied the new Patch as you
described, the Imagesupport for PBM-Files works too.

Once more, great work and many thanks for Imagesupport on OSX :-)

Regards/Gruesse
Hans-Peter Binder
-- 
(coffee-mode -1)

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 13 Jan 2004 21:10:33 +0900 (JST), YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>   Current status:
>   - Unsupported image types: XPM and PostScript.

Below is an XPM support patch for Carbon Emacs.  It does not depend on
libXpm, but only supports XPM version 3 without extensions.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/image.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/image.c,v
retrieving revision 1.7
diff -c -r1.7 image.c
*** src/image.c	16 Apr 2004 20:08:15 -0000	1.7
--- src/image.c	20 Apr 2004 05:20:40 -0000
***************
*** 3161,3172 ****
  			      XPM images
   ***********************************************************************/
  
! #ifdef HAVE_XPM
  
  static int xpm_image_p P_ ((Lisp_Object object));
  static int xpm_load P_ ((struct frame *f, struct image *img));
  static int xpm_valid_color_symbols_p P_ ((Lisp_Object));
  
  #ifdef HAVE_NTGUI
  /* Indicate to xpm.h that we don't have Xlib.  */
  #define FOR_MSW
--- 3161,3175 ----
  			      XPM images
   ***********************************************************************/
  
! #if defined (HAVE_XPM) || defined (MAC_OS)
  
  static int xpm_image_p P_ ((Lisp_Object object));
  static int xpm_load P_ ((struct frame *f, struct image *img));
  static int xpm_valid_color_symbols_p P_ ((Lisp_Object));
  
+ #endif /* HAVE_XPM || MAC_OS */
+ 
+ #ifdef HAVE_XPM
  #ifdef HAVE_NTGUI
  /* Indicate to xpm.h that we don't have Xlib.  */
  #define FOR_MSW
***************
*** 3182,3187 ****
--- 3185,3193 ----
  #else
  #include "X11/xpm.h"
  #endif /* HAVE_NTGUI */
+ #endif /* HAVE_XPM */
+ 
+ #if defined (HAVE_XPM) || defined (MAC_OS)
  
  /* The symbol `xpm' identifying XPM-format images.  */
  
***************
*** 3510,3519 ****
--- 3516,3527 ----
  	      || xpm_valid_color_symbols_p (fmt[XPM_COLOR_SYMBOLS].value)));
  }
  
+ #endif /* HAVE_XPM || MAC_OS */
  
  /* Load image IMG which will be displayed on frame F.  Value is
     non-zero if successful.  */
  
+ #ifdef HAVE_XPM
  static int
  xpm_load (f, img)
       struct frame *f;
***************
*** 3745,3750 ****
--- 3753,4218 ----
  
  #endif /* HAVE_XPM */
  
+ #ifdef MAC_OS
+ 
+ /* XPM support functions for Mac OS where libxpm is not available.
+    Only XPM version 3 (without any extensions) is supported.  */
+ 
+ static int xpm_scan P_ ((unsigned char **, unsigned char *,
+ 			 unsigned char **, int *));
+ static Lisp_Object xpm_make_color_table_v
+   P_ ((void (**) (Lisp_Object, unsigned char *, int, Lisp_Object),
+        Lisp_Object (**) (Lisp_Object, unsigned char *, int)));
+ static void xpm_put_color_table_v P_ ((Lisp_Object, unsigned char *,
+ 				       int, Lisp_Object));
+ static Lisp_Object xpm_get_color_table_v P_ ((Lisp_Object,
+ 					      unsigned char *, int));
+ static Lisp_Object xpm_make_color_table_h
+   P_ ((void (**) (Lisp_Object, unsigned char *, int, Lisp_Object),
+        Lisp_Object (**) (Lisp_Object, unsigned char *, int)));
+ static void xpm_put_color_table_h P_ ((Lisp_Object, unsigned char *,
+ 				       int, Lisp_Object));
+ static Lisp_Object xpm_get_color_table_h P_ ((Lisp_Object,
+ 					      unsigned char *, int));
+ static int xpm_str_to_color_key P_ ((char *));
+ static int xpm_load_image P_ ((struct frame *, struct image *,
+ 			       unsigned char *, unsigned char *));
+ 
+ /* Tokens returned from xpm_scan.  */
+ 
+ enum xpm_token
+ {
+   XPM_TK_IDENT = 256,
+   XPM_TK_STRING,
+   XPM_TK_EOF
+ };
+ 
+ /* Scan an XPM data and return a character (< 256) or a token defined
+    by enum xpm_token above.  *S and END are the start (inclusive) and
+    the end (exclusive) addresses of the data, respectively.  Advance
+    *S while scanning.  If token is either XPM_TK_IDENT or
+    XPM_TK_STRING, *BEG and *LEN are set to the start address and the
+    length of the corresponding token, respectively.  */
+ 
+ static int
+ xpm_scan (s, end, beg, len)
+      unsigned char **s, *end, **beg;
+      int *len;
+ {
+   int c;
+ 
+   while (*s < end)
+     {
+       /* Skip white-space.  */
+       while (*s < end && (c = *(*s)++, isspace (c)))
+ 	;
+ 
+       /* gnus-pointer.xpm uses '-' in its identifier.
+ 	 sb-dir-plus.xpm uses '+' in its identifier.  */
+       if (isalpha (c) || c == '_' || c == '-' || c == '+')
+ 	{
+ 	  *beg = *s - 1;
+ 	  while (*s < end &&
+ 		 (c = **s, isalnum (c) || c == '_' || c == '-' || c == '+'))
+ 	      ++*s;
+ 	  *len = *s - *beg;
+ 	  return XPM_TK_IDENT;
+ 	}
+       else if (c == '"')
+ 	{
+ 	  *beg = *s;
+ 	  while (*s < end && **s != '"')
+ 	    ++*s;
+ 	  *len = *s - *beg;
+ 	  if (*s < end)
+ 	    ++*s;
+ 	  return XPM_TK_STRING;
+ 	}
+       else if (c == '/')
+ 	{
+ 	  if (*s < end && **s == '*')
+ 	    {
+ 	      /* C-style comment.  */
+ 	      ++*s;
+ 	      do
+ 		{
+ 		  while (*s < end && *(*s)++ != '*')
+ 		    ;
+ 		}
+ 	      while (*s < end && **s != '/');
+ 	      if (*s < end)
+ 		++*s;
+ 	    }
+ 	  else
+ 	    return c;
+ 	}
+       else
+ 	return c;
+     }
+ 
+   return XPM_TK_EOF;
+ }
+ 
+ /* Functions for color table lookup in XPM data.  A Key is a string
+    specifying the color of each pixel in XPM data.  A value is either
+    an integer that specifies a pixel color, Qt that specifies
+    transparency, or Qnil for the unspecified color.  If the length of
+    the key string is one, a vector is used as a table.  Otherwise, a
+    hash table is used.  */
+ 
+ static Lisp_Object
+ xpm_make_color_table_v (put_func, get_func)
+      void (**put_func) (Lisp_Object, unsigned char *, int, Lisp_Object);
+      Lisp_Object (**get_func) (Lisp_Object, unsigned char *, int);
+ {
+   *put_func = xpm_put_color_table_v;
+   *get_func = xpm_get_color_table_v;
+   return Fmake_vector (make_number (256), Qnil);
+ }
+ 
+ static void
+ xpm_put_color_table_v (color_table, chars_start, chars_len, color)
+      Lisp_Object color_table;
+      unsigned char *chars_start;
+      int chars_len;
+      Lisp_Object color;
+ {
+   XVECTOR (color_table)->contents[*chars_start] = color;
+ }
+ 
+ static Lisp_Object
+ xpm_get_color_table_v (color_table, chars_start, chars_len)
+      Lisp_Object color_table;
+      unsigned char *chars_start;
+      int chars_len;
+ {
+   return XVECTOR (color_table)->contents[*chars_start];
+ }
+ 
+ static Lisp_Object
+ xpm_make_color_table_h (put_func, get_func)
+      void (**put_func) (Lisp_Object, unsigned char *, int, Lisp_Object);
+      Lisp_Object (**get_func) (Lisp_Object, unsigned char *, int);
+ {
+   *put_func = xpm_put_color_table_h;
+   *get_func = xpm_get_color_table_h;
+   return make_hash_table (Qequal, make_number (DEFAULT_HASH_SIZE),
+ 			  make_float (DEFAULT_REHASH_SIZE),
+ 			  make_float (DEFAULT_REHASH_THRESHOLD),
+ 			  Qnil, Qnil, Qnil);
+ }
+ 
+ static void
+ xpm_put_color_table_h (color_table, chars_start, chars_len, color)
+      Lisp_Object color_table;
+      unsigned char *chars_start;
+      int chars_len;
+      Lisp_Object color;
+ {
+   struct Lisp_Hash_Table *table = XHASH_TABLE (color_table);
+   unsigned hash_code;
+   Lisp_Object chars = make_unibyte_string (chars_start, chars_len);
+ 
+   hash_lookup (table, chars, &hash_code);
+   hash_put (table, chars, color, hash_code);
+ }
+ 
+ static Lisp_Object
+ xpm_get_color_table_h (color_table, chars_start, chars_len)
+      Lisp_Object color_table;
+      unsigned char *chars_start;
+      int chars_len;
+ {
+   struct Lisp_Hash_Table *table = XHASH_TABLE (color_table);
+   int i = hash_lookup (table, make_unibyte_string (chars_start, chars_len),
+ 		       NULL);
+ 
+   return i >= 0 ? HASH_VALUE (table, i) : Qnil;
+ }
+ 
+ enum xpm_color_key {
+   XPM_COLOR_KEY_S,
+   XPM_COLOR_KEY_M,
+   XPM_COLOR_KEY_G4,
+   XPM_COLOR_KEY_G,
+   XPM_COLOR_KEY_C
+ };
+ 
+ static char xpm_color_key_strings[][4] = {"s", "m", "g4", "g", "c"};
+ 
+ static int
+ xpm_str_to_color_key (s)
+      char *s;
+ {
+   int i;
+ 
+   for (i = 0;
+        i < sizeof xpm_color_key_strings / sizeof xpm_color_key_strings[0];
+        i++)
+     if (strcmp (xpm_color_key_strings[i], s) == 0)
+       return i;
+   return -1;
+ }
+ 
+ static int
+ xpm_load_image (f, img, contents, end)
+      struct frame *f;
+      struct image *img;
+      unsigned char *contents, *end;
+ {
+   unsigned char *s = contents, *beg, *str;
+   unsigned char buffer[BUFSIZ];
+   int width, height, x, y;
+   int num_colors, chars_per_pixel;
+   int len, LA1;
+   void (*put_color_table) (Lisp_Object, unsigned char *, int, Lisp_Object);
+   Lisp_Object (*get_color_table) (Lisp_Object, unsigned char *, int);
+   Lisp_Object frame, color_symbols, color_table;
+   int best_key, have_mask = 0;
+   XImagePtr ximg = NULL, mask_img = NULL;
+ 
+ #define match() \
+      LA1 = xpm_scan (&s, end, &beg, &len)
+ 
+ #define expect(TOKEN)		\
+      if (LA1 != (TOKEN)) 	\
+        goto failure;		\
+      else			\
+        match ()
+ 
+ #define expect_ident(IDENT)					\
+      if (LA1 == XPM_TK_IDENT \
+          && strlen ((IDENT)) == len && memcmp ((IDENT), beg, len) == 0)	\
+        match ();						\
+      else							\
+        goto failure
+ 
+   if (!(end - s >= 9 && memcmp (s, "/* XPM */", 9) == 0))
+     goto failure;
+   s += 9;
+   match();
+   expect_ident ("static");
+   expect_ident ("char");
+   expect ('*');
+   expect (XPM_TK_IDENT);
+   expect ('[');
+   expect (']');
+   expect ('=');
+   expect ('{');
+   expect (XPM_TK_STRING);
+   if (len >= BUFSIZ)
+     goto failure;
+   memcpy (buffer, beg, len);
+   buffer[len] = '\0';
+   if (sscanf (buffer, "%d %d %d %d", &width, &height,
+ 	      &num_colors, &chars_per_pixel) != 4
+       || width <= 0 || height <= 0
+       || num_colors <= 0 || chars_per_pixel <= 0)
+     goto failure;
+   expect (',');
+ 
+   XSETFRAME (frame, f);
+   if (!NILP (Fxw_display_color_p (frame)))
+     best_key = XPM_COLOR_KEY_C;
+   else if (!NILP (Fx_display_grayscale_p (frame)))
+     best_key = (XFASTINT (Fx_display_planes (frame)) > 2
+ 		? XPM_COLOR_KEY_G : XPM_COLOR_KEY_G4);
+   else
+     best_key = XPM_COLOR_KEY_M;
+ 
+   color_symbols = image_spec_value (img->spec, QCcolor_symbols, NULL);
+   if (chars_per_pixel == 1)
+     color_table = xpm_make_color_table_v (&put_color_table,
+ 					  &get_color_table);
+   else
+     color_table = xpm_make_color_table_h (&put_color_table,
+ 					  &get_color_table);
+ 
+   while (num_colors-- > 0)
+     {
+       unsigned char *color, *max_color;
+       int key, next_key, max_key = 0;
+       Lisp_Object symbol_color = Qnil, color_val;
+       XColor cdef;
+ 
+       expect (XPM_TK_STRING);
+       if (len <= chars_per_pixel || len >= BUFSIZ + chars_per_pixel)
+ 	goto failure;
+       memcpy (buffer, beg + chars_per_pixel, len - chars_per_pixel);
+       buffer[len - chars_per_pixel] = '\0';
+ 
+       str = strtok (buffer, " \t");
+       if (str == NULL)
+ 	goto failure;
+       key = xpm_str_to_color_key (str);
+       if (key < 0)
+ 	goto failure;
+       do
+ 	{
+ 	  color = strtok (NULL, " \t");
+ 	  if (color == NULL)
+ 	    goto failure;
+ 
+ 	  while (str = strtok (NULL, " \t"))
+ 	    {
+ 	      next_key = xpm_str_to_color_key (str);
+ 	      if (next_key >= 0)
+ 		break;
+ 	      color[strlen (color)] = ' ';
+ 	    }
+ 
+ 	  if (key == XPM_COLOR_KEY_S)
+ 	    {
+ 	      if (NILP (symbol_color))
+ 		symbol_color = build_string (color);
+ 	    }
+ 	  else if (max_key < key && key <= best_key)
+ 	    {
+ 	      max_key = key;
+ 	      max_color = color;
+ 	    }
+ 	  key = next_key;
+ 	}
+       while (str);
+ 
+       color_val = Qnil;
+       if (!NILP (color_symbols) && !NILP (symbol_color))
+ 	{
+ 	  Lisp_Object specified_color = Fassoc (symbol_color, color_symbols);
+ 
+ 	  if (CONSP (specified_color) && STRINGP (XCDR (specified_color)))
+ 	    if (xstricmp (SDATA (XCDR (specified_color)), "None") == 0)
+ 	      color_val = Qt;
+ 	    else if (x_defined_color (f, SDATA (XCDR (specified_color)),
+ 				      &cdef, 0))
+ 	      color_val = make_number (cdef.pixel);
+ 	}
+       if (NILP (color_val) && max_key > 0)
+ 	if (xstricmp (max_color, "None") == 0)
+ 	  color_val = Qt;
+ 	else if (x_defined_color (f, max_color, &cdef, 0))
+ 	  color_val = make_number (cdef.pixel);
+       if (!NILP (color_val))
+ 	(*put_color_table) (color_table, beg, chars_per_pixel, color_val);
+ 
+       expect (',');
+     }
+ 
+   if (!x_create_x_image_and_pixmap (f, width, height, 0,
+ 				    &ximg, &img->pixmap)
+       || !x_create_x_image_and_pixmap (f, width, height, 1,
+ 				       &mask_img, &img->mask))
+     {
+       image_error ("Out of memory (%s)", img->spec, Qnil);
+       goto error;
+     }
+ 
+   for (y = 0; y < height; y++)
+     {
+       expect (XPM_TK_STRING);
+       str = beg;
+       if (len < width * chars_per_pixel)
+ 	goto failure;
+       for (x = 0; x < width; x++, str += chars_per_pixel)
+ 	{
+ 	  Lisp_Object color_val =
+ 	    (*get_color_table) (color_table, str, chars_per_pixel);
+ 
+ 	  XPutPixel (ximg, x, y,
+ 		     (INTEGERP (color_val) ? XINT (color_val)
+ 		      : FRAME_FOREGROUND_PIXEL (f)));
+ 	  XPutPixel (mask_img, x, y,
+ 		     (!EQ (color_val, Qt) ? PIX_MASK_DRAW (f)
+ 		      : (have_mask = 1, PIX_MASK_RETAIN (f))));
+ 	}
+       if (y + 1 < height)
+ 	expect (',');
+     }
+ 
+   img->width = width;
+   img->height = height;
+ 
+   x_put_x_image (f, ximg, img->pixmap, width, height);
+   x_destroy_x_image (ximg);
+   if (have_mask)
+     {
+       x_put_x_image (f, mask_img, img->mask, width, height);
+       x_destroy_x_image (mask_img);
+     }
+   else
+     {
+       x_destroy_x_image (mask_img);
+       Free_Pixmap (FRAME_X_DISPLAY (f), img->mask);
+       img->mask = NO_PIXMAP;
+     }
+ 
+   return 1;
+ 
+  failure:
+   image_error ("Invalid XPM file (%s)", img->spec, Qnil);
+  error:
+   x_destroy_x_image (ximg);
+   x_destroy_x_image (mask_img);
+   x_clear_image (f, img);
+   return 0;
+ 
+ #undef match
+ #undef expect
+ #undef expect_ident
+ }
+ 
+ static int
+ xpm_load (f, img)
+      struct frame *f;
+      struct image *img;
+ {
+   int success_p = 0;
+   Lisp_Object file_name;
+ 
+   /* If IMG->spec specifies a file name, create a non-file spec from it.  */
+   file_name = image_spec_value (img->spec, QCfile, NULL);
+   if (STRINGP (file_name))
+     {
+       Lisp_Object file;
+       unsigned char *contents;
+       int size;
+       struct gcpro gcpro1;
+ 
+       file = x_find_image_file (file_name);
+       GCPRO1 (file);
+       if (!STRINGP (file))
+ 	{
+ 	  image_error ("Cannot find image file `%s'", file_name, Qnil);
+ 	  UNGCPRO;
+ 	  return 0;
+ 	}
+ 
+       contents = slurp_file (SDATA (file), &size);
+       if (contents == NULL)
+ 	{
+ 	  image_error ("Error loading XPM image `%s'", img->spec, Qnil);
+ 	  UNGCPRO;
+ 	  return 0;
+ 	}
+ 
+       success_p = xpm_load_image (f, img, contents, contents + size);
+       xfree (contents);
+       UNGCPRO;
+     }
+   else
+     {
+       Lisp_Object data;
+ 
+       data = image_spec_value (img->spec, QCdata, NULL);
+       success_p = xpm_load_image (f, img, SDATA (data),
+ 				  SDATA (data) + SBYTES (data));
+     }
+ 
+   return success_p;
+ }
+ 
+ #endif /* MAC_OS */
+ 
  \f
  /***********************************************************************
  			     Color table
***************
*** 7417,7423 ****
    Qxbm = intern ("xbm");
    staticpro (&Qxbm);
  
! #ifdef HAVE_XPM
    Qxpm = intern ("xpm");
    staticpro (&Qxpm);
  #endif
--- 7885,7891 ----
    Qxbm = intern ("xbm");
    staticpro (&Qxbm);
  
! #if defined (HAVE_XPM) || defined (MAC_OS)
    Qxpm = intern ("xpm");
    staticpro (&Qxpm);
  #endif
***************
*** 7487,7493 ****
    define_image_type (&xbm_type);
    define_image_type (&pbm_type);
  
! #ifdef HAVE_XPM
    IF_LIB_AVAILABLE(init_xpm_functions)
      define_image_type (&xpm_type);
  #endif
--- 7955,7961 ----
    define_image_type (&xbm_type);
    define_image_type (&pbm_type);
  
! #if defined (HAVE_XPM) || defined (MAC_OS)
    IF_LIB_AVAILABLE(init_xpm_functions)
      define_image_type (&xpm_type);
  #endif

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[Miles Bader]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> Below is an XPM support patch for Carbon Emacs.  It does not depend on
> libXpm, but only supports XPM version 3 without extensions.

Is this code macos-specific?  In a brief scan, it looked pretty generic.

If it is generic, could it be used always when HAVE_XPM is not defined
(instead of only on MAC_OS)?

Thanks,

-miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[YAMAMOTO Mitsuharu]

>>>>> On 20 Apr 2004 18:03:20 +0900, Miles Bader <miles@lsi.nec.co.jp> said:

> If it is generic, could it be used always when HAVE_XPM is not
> defined (instead of only on MAC_OS)?

I think so.  But for X11, there's no optimization as libXpm does, no
colormap support, and I cannot imagine any (working) X11 environments
without libXpm :-)

I'm not familiar with W32 environment, but it would be useful if
libXpm on W32 is not so standard.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[David Kastrup]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> >>>>> On Tue, 13 Jan 2004 21:10:33 +0900 (JST), YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:
> 
> >   Current status:
> >   - Unsupported image types: XPM and PostScript.
> 
> Below is an XPM support patch for Carbon Emacs.  It does not depend on
> libXpm, but only supports XPM version 3 without extensions.

Let me just pipe in to say that whoever thinks of putting in any work
to make "PostScript" a supported image type in the same manner as it
is in other platforms, should not bother.

PostScript image support is close to unusable under X, anyway.
preview-latex <URL:http://preview-latex.sourceforge.net>, while being
inspired by the availability of PostScript support, had to abandon
using it before the first release.  It is far too feeble and
inefficient to be of practical use for more than trivial tasks.  I
don't think it can be fixed reasonably, given its approach and
implementation.  And I doubt that there would be much of an
application for it, anyhow.

XPM is different, though: lots of icons are available in that format.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[Stefan Monnier]

> Below is an XPM support patch for Carbon Emacs.  It does not depend on
> libXpm, but only supports XPM version 3 without extensions.

libXpm is very easy to get on Mac OS X, so maybe it'd be better to
try and support libXpm in Carbon Emacs (tho it may depend much too much on
the rest of the X11 libraries).


        Stefan

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[YAMAMOTO Mitsuharu]

>>>>> On 20 Apr 2004 10:28:44 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

> libXpm is very easy to get on Mac OS X, so maybe it'd be better to
> try and support libXpm in Carbon Emacs (tho it may depend much too
> much on the rest of the X11 libraries).

That's why I didn't use libXpm.  Unlike other image libraries, it is
heavily dependent on X11 functions and data structures.  Linking X11
libraries is definitely not an option.  I thought implementing
emulation of X11 functions and data structures was overkill for our
purpose, and it actually conflicts with the existing ones in Carbon
Emacs.

XPM itself is not difficult to implement if we restrict ourselves to
version 3.  For example, ImageMagick also uses its own implementation
of XPM functions rather than libXpm.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[Stefan Monnier]

> XPM itself is not difficult to implement if we restrict ourselves to
> version 3.  For example, ImageMagick also uses its own implementation
> of XPM functions rather than libXpm.

Could it even be packaged up separately as "libnoXpm" ?


        Stefan

Re: Image support for Carbon Emacs (Re: Consolidation of image support)

[YAMAMOTO Mitsuharu]

>>>>> On 21 Apr 2004 11:58:08 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> XPM itself is not difficult to implement if we restrict ourselves
>> to version 3.  For example, ImageMagick also uses its own
>> implementation of XPM functions rather than libXpm.

> Could it even be packaged up separately as "libnoXpm" ?

It could be.  But I doubt whether it's worth doing.  For a portable
image library, there already exists ImageMagick.  Hmm, it might be
useful when supporting scaling, rotation, etc. in the future version
of Emacs.

Anyway, because other supported image types require no extra
libraries, including XPM functionality in Emacs (as in XBM and PBM)
is handy for Mac at the moment.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Emacs on MAC OS X 10.3

[Dusan Turk]

Dear Emacs developers,

I've downloaded the latest emacs 21.3.50.1 binary for MAC OS X 10.3. And 
almost none of the font changes works.  I am used to work with emacs 
invoking it by the following command on a variety of X11 based platforms:

emacs -ms yellow -cr yellow -bg black -fg green -fn 
-misc-fixed-medium-r-normal--20-140-100-100-c-100-iso8859-1

By buying a Powerbook I would like to do the same.  The problem is that 
whatever font I try to set via the menu I get "Font not found".  With 
M-x set-frame-font - the lucida type seems to work and some other 
unuseful onse as well.

The font I want to use does exist (xfontsel, xlsfonts) find it.  Also 
xterm does recognize it and applies it.  So I assume that it is a bug in 
the Emacs distribution.  Would be great if it worked.

best regards,

dusan turk


-- 
********************************************************************
Dusan Turk                           e-mail: dusan.turk@ijs.si
Dept. of Biochem. and Mol. Biol.     phone: +386 1 477 3857 
Jozef Stefan Institute               fax: +386 1 257 3594
Jamova 39, 1 000 Ljubljana
Slovenia, (EUROPE)
********************************************************************

Re: Emacs on MAC OS X 10.3

[Benjamin Riefenstahl]

Hi Dusan,


Dusan Turk <Dusan.Turk@siol.net> writes:
> I've downloaded the latest emacs 21.3.50.1 binary for MAC OS X
> 10.3. [...] 
>
> [...] The problem is that whatever font I try to set via the menu I
> get "Font not found".  [...] 

> The font I want to use does exist (xfontsel, xlsfonts) find it.

These are X11 utilities.  They report information about the separate
X11 environment, which will does things differently from the rest of
the system and from non-X11 programs.

As you are already using X11, you may have more success with using an
X11 Emacs instead of an Aqua Emacs.  There is a Fink package for that
<http://fink.sourceforge.net/pdb/package.php/emacs>. 

> Also xterm does recognize it and applies it.  So I assume that it is
> a bug in the Emacs distribution.  Would be great if it worked.

Sadly, there is no maintainer for the Aqua Emacs at the moment. 


benny

Re: Emacs on MAC OS X 10.3

[Ted Lemon]

On Dec 17, 2003, at 4:56 AM, Benjamin Riefenstahl wrote:
> Sadly, there is no maintainer for the Aqua Emacs at the moment.

I volunteered to do it, but what with all the savannah hassles, I think 
that's fallen into a black hole.   However, it's not really Aqua emacs 
- it's Carbon emacs.   There are a lot of stubs in the carbon module 
(macterm.c) that need to be filled in, and that might help out a bit, 
but it would be quite a challenge to make it work with X-style font 
names, because the font names in Carbon are the Mac font names, not the 
X font names.

I'd actually like to add an experimental set of Aqua stubs, although 
given that the Carbon code is quite stable now and also works on MacOS 
9, I don't think it's time to switch to Aqua yet.

Consolidation of image support (was Re: Emacs on MAC OS X 10.3)

[Kim F. Storm]

Ted Lemon <mellon@fugue.com> writes:

> On Dec 17, 2003, at 4:56 AM, Benjamin Riefenstahl wrote:
> > Sadly, there is no maintainer for the Aqua Emacs at the moment.
> 
> I volunteered to do it, but what with all the savannah hassles, I
> think that's fallen into a black hole.   However, it's not really Aqua
> emacs - it's Carbon emacs.   There are a lot of stubs in the carbon
> module (macterm.c) that need to be filled in, and that might help out
> a bit, but it would be quite a challenge to make it work with X-style
> font names, because the font names in Carbon are the Mac font names,
> not the X font names.
> 
> I'd actually like to add an experimental set of Aqua stubs, although
> given that the Carbon code is quite stable now and also works on MacOS
> 9, I don't think it's time to switch to Aqua yet.
 
Be aware that I plan (in the near future) to take out the image
support code from xfns.c, w32fns.c and macfns.c and consolidate it in
a new image.c file.  

That should reduce 15000 lines of code to approx 5500 lines.

It seems that most of the image code in macfns.c isn't actually
used/ported yet, so it would be a good thing to consolidate the code
before finishing the image support for MAC.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk