Non-ASCII in Lucid menus

Non-ASCII in Lucid menus

[Stefan Monnier]

The patch below makes the Lucid menu use fontsets to draw its text, so that
it's able to write non-ASCII (the set of chars supported is dependent on the
locale, and of course on the fonts).

I'm very much an idiot when it comes to X11 programming, xfaces.c, and
lwlib, so this might be riddled with bugs and misunderstandings, but after
some trial-and-error this not only works for me, but it even looks sensible
to me.

Any objection?


        Stefan


PS: The use of XrmPutLineResource in xfaces.c seems amazingly brittle and
    hackish, but that's what the rest of the code uses.


Index: src/xfaces.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xfaces.c,v
retrieving revision 1.314
diff -u -r1.314 xfaces.c
--- src/xfaces.c	18 Feb 2005 22:55:53 -0000	1.314
+++ src/xfaces.c	12 Mar 2005 23:40:23 -0000
@@ -4695,6 +4695,17 @@
 #else
 	  const char *suffix = "";
 #endif
+#ifdef HAVE_X_I18N
+	  extern char *xic_create_fontsetname P_ ((char *base_fontname));
+	  const char *fontsetname = xic_create_fontsetname (face->font_name);
+	  sprintf (line, "%s.pane.menubar*fontSet: %s",
+		   myname, fontsetname);
+	  XrmPutLineResource (&rdb, line);
+	  sprintf (line, "%s.%s*fontSet: %s",
+		   myname, popup_path, fontsetname);
+	  XrmPutLineResource (&rdb, line);
+	  xfree (fontsetname);
+#endif
 	  sprintf (line, "%s.pane.menubar*font%s: %s",
 		   myname, suffix, face->font_name);
 	  XrmPutLineResource (&rdb, line);
Index: src/coding.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/coding.h,v
retrieving revision 1.70
diff -u -r1.70 coding.h
--- src/coding.h	30 Nov 2004 08:01:45 -0000	1.70
+++ src/coding.h	12 Mar 2005 23:40:23 -0000
@@ -591,9 +591,8 @@
       ? code_convert_string_norecord (name, Vdefault_file_name_coding_system, 0) \
       : name))
 
-#ifdef WINDOWSNT
 /* Encode the string STR using the specified coding system
-   for w32 system functions, if any.  */
+   for system functions, if any.  */
 #define ENCODE_SYSTEM(str)						   \
   (! NILP (Vlocale_coding_system)					   \
    && !EQ (Vlocale_coding_system, make_number (0))			   \
@@ -601,20 +600,13 @@
    : str)
 
 /* Decode the string STR using the specified coding system
-   for w32 system functions, if any.  */
+   for system functions, if any.  */
 #define DECODE_SYSTEM(name)						   \
   (! NILP (Vlocale_coding_system)					   \
    && !EQ (Vlocale_coding_system, make_number (0))			   \
    ? code_convert_string_norecord (str, Vlocale_coding_system, 0)	   \
    : str)
 
-#else /* WINDOWSNT */
-
-#define ENCODE_SYSTEM(str) string_make_unibyte(str)
-#define DECODE_SYSTEM(name) name
-
-#endif /* !WINDOWSNT */
-
 #define ENCODE_UTF_8(str) code_convert_string_norecord (str, Qutf_8, 1)
 
 /* Extern declarations.  */
Index: lwlib/xlwmenuP.h
===================================================================
RCS file: /cvsroot/emacs/emacs/lwlib/xlwmenuP.h,v
retrieving revision 1.9
diff -u -r1.9 xlwmenuP.h
--- lwlib/xlwmenuP.h	12 Mar 2005 23:38:43 -0000	1.9
+++ lwlib/xlwmenuP.h	12 Mar 2005 23:40:23 -0000
@@ -44,6 +44,9 @@
 {
   /* slots set by the resources */
   XFontStruct*	font;
+#ifdef HAVE_X_I18N
+  XFontSet	fontset;
+#endif
   Pixel		foreground;
   Pixel		disabled_foreground;
   Pixel		button_foreground;
Index: lwlib/xlwmenu.c
===================================================================
RCS file: /cvsroot/emacs/emacs/lwlib/xlwmenu.c,v
retrieving revision 1.61
diff -u -r1.61 xlwmenu.c
--- lwlib/xlwmenu.c	27 Dec 2004 15:22:36 -0000	1.61
+++ lwlib/xlwmenu.c	12 Mar 2005 23:40:23 -0000
@@ -137,6 +137,10 @@
 {
   {XtNfont,  XtCFont, XtRFontStruct, sizeof(XFontStruct *),
      offset(menu.font),XtRString, "XtDefaultFont"},
+#ifdef HAVE_X_I18N
+  {XtNfontSet,  XtCFontSet, XtRFontSet, sizeof(XFontSet),
+     offset(menu.fontset), XtRString, "XtDefaultFontSet"},
+#endif
   {XtNforeground, XtCForeground, XtRPixel, sizeof(Pixel),
      offset(menu.foreground), XtRString, "XtDefaultForeground"},
   {XtNdisabledForeground, XtCDisabledForeground, XtRPixel, sizeof(Pixel),
@@ -353,11 +357,17 @@
      XlwMenuWidget mw;
      char *s;
 {
+#ifdef HAVE_X_I18N
+  XRectangle ink, logical;
+  XmbTextExtents (mw->menu.fontset, s, strlen (s), &ink, &logical);
+  return logical.width;
+#else
   XCharStruct xcs;
   int drop;
 
   XTextExtents (mw->menu.font, s, strlen (s), &drop, &drop, &drop, &xcs);
   return xcs.width;
+#endif
 }
 
 static int
@@ -1028,7 +1038,12 @@
 	    x_offset += ws->button_width;
 
 
-          XDrawString (XtDisplay (mw), ws->window, text_gc, x_offset,
+#ifdef HAVE_X_I18N
+          XmbDrawString (XtDisplay (mw), ws->window, mw->menu.fontset,
+#else
+          XDrawString (XtDisplay (mw), ws->window,
+#endif
+		       text_gc, x_offset,
 		       y + v_spacing + shadow + font_ascent,
 		       display_string, strlen (display_string));
 
@@ -1053,7 +1068,12 @@
 		}
 	      else if (val->key)
 		{
-		  XDrawString (XtDisplay (mw), ws->window, text_gc,
+#ifdef HAVE_X_I18N
+		  XmbDrawString (XtDisplay (mw), ws->window, mw->menu.fontset,
+#else
+		  XDrawString (XtDisplay (mw), ws->window,
+#endif
+			       text_gc,
 			       x + label_width + mw->menu.arrow_spacing,
 			       y + v_spacing + shadow + font_ascent,
 			       val->key, strlen (val->key));

Re: Non-ASCII in Lucid menus

[Jan D.]

Stefan Monnier wrote:

>The patch below makes the Lucid menu use fontsets to draw its text, so that
>it's able to write non-ASCII (the set of chars supported is dependent on the
>locale, and of course on the fonts).
>
>I'm very much an idiot when it comes to X11 programming, xfaces.c, and
>lwlib, so this might be riddled with bugs and misunderstandings, but after
>some trial-and-error this not only works for me, but it even looks sensible
>to me.
>
>Any objection?
>

It is incompatible in the sense that settings in .Xresources that 
previously used
...*menu*font: ...

now must use
...*menu*fontSet:

for the lucid menus.  This should be mentioned in NEWS.  Also, the 
default font used for lucid menus will most certainly be different now.

>PS: The use of XrmPutLineResource in xfaces.c seems amazingly brittle and
>    hackish, but that's what the rest of the code uses.
>  
>

It basically sets a default value.  If the user overrides it (with an X 
resource or -xrm on the command line) the user setting takes 
precedence.  Yes, it is a bit hackish.

    Jan D.

Re: Non-ASCII in Lucid menus

[Stefan Monnier]

>> The patch below makes the Lucid menu use fontsets to draw its text, so that
>> it's able to write non-ASCII (the set of chars supported is dependent on the
>> locale, and of course on the fonts).
>> 
>> I'm very much an idiot when it comes to X11 programming, xfaces.c, and
>> lwlib, so this might be riddled with bugs and misunderstandings, but after
>> some trial-and-error this not only works for me, but it even looks sensible
>> to me.
>> 
>> Any objection?

> It is incompatible in the sense that settings in .Xresources that previously
> used
> ...*menu*font: ...

> now must use
> ...*menu*fontSet:

> for the lucid menus.  This should be mentioned in NEWS.

Hmm... good point.  Do you happen to know how I could get the expected
behavior that "if `font' is set but `fontSet' isn't, use `font'"?

> Also, the default font used for lucid menus will most certainly be
> different now.

Why?  What can I do about it?

>> PS: The use of XrmPutLineResource in xfaces.c seems amazingly brittle and
>> hackish, but that's what the rest of the code uses.

> It basically sets a default value.  If the user overrides it (with an
> X resource or -xrm on the command line) the user setting takes precedence.
> Yes, it is a bit hackish.

It also seems wrong: user settings on the `menu' face should take
precedence, shouldn't they?


        Stefan


PS: A part of the patch I sent was missing:

--- src/xmenu.c	12 Mar 2005 23:29:04 -0000	1.281
+++ src/xmenu.c	13 Mar 2005 13:42:40 -0000
@@ -137,6 +137,8 @@
 #ifdef USE_GTK
 /* gtk just uses utf-8.  */
 # define ENCODE_MENU_STRING(str) ENCODE_UTF_8 (str)
+#elif defined HAVE_X_I18N
+# define ENCODE_MENU_STRING(str) ENCODE_SYSTEM (str)
 #else
 # define ENCODE_MENU_STRING(str) string_make_unibyte (str)
 #endif

Re: Non-ASCII in Lucid menus

[Jan D.]

>> It is incompatible in the sense that settings in .Xresources that 
>> previously
>> used
>> ...*menu*font: ...
>
>> now must use
>> ...*menu*fontSet:
>
>> for the lucid menus.  This should be mentioned in NEWS.
>
> Hmm... good point.  Do you happen to know how I could get the expected
> behavior that "if `font' is set but `fontSet' isn't, use `font'"?

Basically you have to set the default to something else than the 
XtDdefaultFont(Set), and then check if either has been changed.  But 
better would be to just have one, as Motif has FontList.

>
>> Also, the default font used for lucid menus will most certainly be
>> different now.
>
> Why?  What can I do about it?

It is just that the default for font and fontset in Xt differs.  It 
should perhaps be noted in NEWS, or we should perhaps just be prepared 
for "why have you changed the menu font" questions :-).  I don't think 
that this is a problem, it is just different.

	Jan D.

Re: Non-ASCII in Lucid menus

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The patch below makes the Lucid menu use fontsets to draw its text,
> so that it's able to write non-ASCII (the set of chars supported is
> dependent on the locale, and of course on the fonts).

Hmm.  Is the dependency on the locale necessary?

> I'm very much an idiot when it comes to X11 programming, xfaces.c,
> and lwlib, so this might be riddled with bugs and misunderstandings,
> but after some trial-and-error this not only works for me, but it
> even looks sensible to me.
>
> Any objection?

Well, I have a Latin-1 locale, and the Unicode menus from AUCTeX math
input mode don't look well in there.  GTK+, in contrast, has no
problems with showing them.

Is there a possibility for Emacs to figure out just what locales would
be supported for fonts, and use utf-8 if possible?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Non-ASCII in Lucid menus

[Richard Stallman]

    The patch below makes the Lucid menu use fontsets to draw its text, so that
    it's able to write non-ASCII (the set of chars supported is dependent on the
    locale, and of course on the fonts).

Thanks very much.

    I'm very much an idiot when it comes to X11 programming, xfaces.c, and
    lwlib, so this might be riddled with bugs and misunderstandings, but after
    some trial-and-error this not only works for me, but it even looks sensible
    to me.

I am no expert either, so I hope that some who know better than I do
will check it.

Re: Non-ASCII in Lucid menus

[Stefan Monnier]

>>> It is incompatible in the sense that settings in .Xresources that
>>> previously
>>> used
>>> ...*menu*font: ...
>> 
>>> now must use
>>> ...*menu*fontSet:
>> 
>>> for the lucid menus.  This should be mentioned in NEWS.
>> 
>> Hmm... good point.  Do you happen to know how I could get the expected
>> behavior that "if `font' is set but `fontSet' isn't, use `font'"?

> Basically you have to set the default to something else than the
> XtDdefaultFont(Set), and then check if either has been changed.

But the default is specified as a string (the name of the default font),
whereas in the code I only have access to mw->menu.font which is
an XFontStruct*.  How can I tell if this XFontStruct* corresponds to the
default or not?

> But better would be to just have one, as Motif has FontList.

You mean I could just use ".font" instead of ".fontSet", ... Hmm ... that's
an idea.  I'll have to change the rest of the code that uses
font->max_bounds.asent and things like that, tho.

BTW, is the HAVE_X_I18N test still necessary?  It'd help if we could just
assume that X_I18N is available.

>>> Also, the default font used for lucid menus will most certainly be
>>> different now.
>> Why?  What can I do about it?
> It is just that the default for font and fontset in Xt differs.

How?  It seems to be helvetica in both cases.


        Stefan

Re: Non-ASCII in Lucid menus

[Jan D.]

>
>> Basically you have to set the default to something else than the
>> XtDdefaultFont(Set), and then check if either has been changed.
>
> But the default is specified as a string (the name of the default 
> font),
> whereas in the code I only have access to mw->menu.font which is
> an XFontStruct*.  How can I tell if this XFontStruct* corresponds to 
> the
> default or not?

You can specify any default you wan't, including another type.  So you 
can say that the default is a XtRFontStruct intead of a XtRString.  
Then you can set the default to NULL and check against that.  When the 
code sees NULL, you extract the default font with XtConvert by giving 
it "XtDefaultFont"/"XtDefaultFontSet".

>
>> But better would be to just have one, as Motif has FontList.
>
> You mean I could just use ".font" instead of ".fontSet", ... Hmm ... 
> that's
> an idea.  I'll have to change the rest of the code that uses
> font->max_bounds.asent and things like that, tho.
>
> BTW, is the HAVE_X_I18N test still necessary?  It'd help if we could 
> just
> assume that X_I18N is available.

I'm not sure.  It is possible some older VMS or other systems still 
have X11R3 or X11R4 (not exactly sure when I18N became available).  
X11R5 and X11R6 do have it, which probably accounts for the majority of 
system nowdays (for example all versions of XFree86 and xorg, and 
Solaris back to 2.5 at least).

>
>>>> Also, the default font used for lucid menus will most certainly be
>>>> different now.
>>> Why?  What can I do about it?
>> It is just that the default for font and fontset in Xt differs.
>
> How?  It seems to be helvetica in both cases.

It depends on your font path.  XtDefaultFont, if no font is specified 
in .Xdefaults or any app-defaults file, is:
     f = XLoadFont(display, "-*-*-*-R-*-*-*-120-*-*-*-*-ISO8859-*");
but XtDefaultFontSet is
     f = XCreateFontSet(display, "-*-*-*-R-*-*-*-120-*-*-*-*,*",

(note no ISO8859 in the latter case).  For me that gives different 
matches, for you it may give the same font.  Since more locales specify 
UTF-8 nowdays I think a difference will not be uncommon.

	Jan D.

Re: Non-ASCII in Lucid menus

[Miles Bader]

On Mon, 14 Mar 2005 21:56:35 +0100, Jan D. <jan.h.d@swipnet.se> wrote:
> > BTW, is the HAVE_X_I18N test still necessary?  It'd help if we could just
> > assume that X_I18N is available.
> 
> I'm not sure.  It is possible some older VMS or other systems still
> have X11R3 or X11R4 (not exactly sure when I18N became available).
> X11R5 and X11R6 do have it, which probably accounts for the majority of
> system nowdays (for example all versions of XFree86 and xorg, and
> Solaris back to 2.5 at least).

I think it's good not to underestimate the extreme age of some systems
on which Emacs gets compiled.... :-)  My work still runs SunOS 4.4
systems, and they have X-enabled Emacs on them.

Of course such systems might not benefit from Stefan's patch anyway --
but here should be _some_ way to get Emacs with lucid widgets compiled
on such systems.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Non-ASCII in Lucid menus

[Stefan Monnier]

>>> It is incompatible in the sense that settings in .Xresources that
>>> previously
>>> used
>>> ...*menu*font: ...
>> 
>>> now must use
>>> ...*menu*fontSet:
>> 
>>> for the lucid menus.  This should be mentioned in NEWS.
>> 
>> Hmm... good point.  Do you happen to know how I could get the expected
>> behavior that "if `font' is set but `fontSet' isn't, use `font'"?

> Basically you have to set the default to something else than the
> XtDdefaultFont(Set), and then check if either has been changed.

OK, I now understand how I could do that.

> But better would be to just have one, as Motif has FontList.

But I prefer this option as well.  In the patch below I simply changed the
semantics of the "font" Xresource so that it is now a fontset rather than
a font: you can still specify a font, but you can now also specify a list of
fonts.  So it should be 100% backward compatible with users's
Xresource customizations.

> It is just that the default for font and fontset in Xt differs.  It should
> perhaps be noted in NEWS, or we should perhaps just be prepared for "why
> have you changed the menu font" questions :-).  I don't think that this is
> a problem, it is just different.

Just to make sure I understand your judgment: you think it's not important
because the difference is minor, or because the "new" default (if
different") is also different for other apps and so it's still considered as
a legitimate default, or ...

In any case, here is the new improved patch.  This new patch should also
enable non-ASCII in Motif menus, although I haven't actually checked it.

I'll be happy to keep this patch for post-21.4, but if people feel like this
is important, I can install it as well.

W.r.t the fact that the menus only support chars in the user's locale rather
than always support unicode, that can be changed later with an additional
patch, but AFAICT the current patch would be a prerequisite anyway.


        Stefan


--- orig/lwlib/xlwmenu.c
+++ mod/lwlib/xlwmenu.c
@@ -135,8 +135,13 @@
 static XtResource
 xlwMenuResources[] =
 {
+#ifdef HAVE_X_I18N
+  {XtNfont,  XtCFont, XtRFontSet, sizeof(XFontSet),
+     offset(menu.font), XtRString, "XtDefaultFontSet"},
+#else
   {XtNfont,  XtCFont, XtRFontStruct, sizeof(XFontStruct *),
-     offset(menu.font),XtRString, "XtDefaultFont"},
+     offset(menu.font), XtRString, "XtDefaultFont"},
+#endif
   {XtNforeground, XtCForeground, XtRPixel, sizeof(Pixel),
      offset(menu.foreground), XtRString, "XtDefaultForeground"},
   {XtNdisabledForeground, XtCDisabledForeground, XtRPixel, sizeof(Pixel),
@@ -235,7 +240,7 @@
     XtNumber(xlwMenuResources),		/* resource_count	  */
     NULLQUARK,				/* xrm_class		  */
     TRUE,				/* compress_motion	  */
-    TRUE,				/* compress_exposure	  */
+    XtExposeCompressMaximal,		/* compress_exposure	  */
     TRUE,				/* compress_enterleave    */
     FALSE,				/* visible_interest	  */
     XlwMenuDestroy,			/* destroy		  */
@@ -353,18 +358,30 @@
      XlwMenuWidget mw;
      char *s;
 {
+#ifdef HAVE_X_I18N
+  XRectangle ink, logical;
+  XmbTextExtents (mw->menu.font, s, strlen (s), &ink, &logical);
+  return logical.width;
+#else
   XCharStruct xcs;
   int drop;
 
   XTextExtents (mw->menu.font, s, strlen (s), &drop, &drop, &drop, &xcs);
   return xcs.width;
+#endif
 }
 
 static int
 arrow_width (mw)
      XlwMenuWidget mw;
 {
-  return (mw->menu.font->ascent * 3/4) | 1;
+  return (
+#ifdef HAVE_X_I18N
+	  mw->menu.font_extents->max_logical_extent.height * 9 / 10
+#else
+	  mw->menu.font->ascent
+#endif
+	  * 3/4) | 1;
 }
 
 /* Return the width of toggle buttons of widget MW.  */
@@ -373,7 +390,13 @@
 toggle_button_width (mw)
      XlwMenuWidget mw;
 {
-  return ((mw->menu.font->ascent + mw->menu.font->descent) * 2 / 3) | 1;
+  return ((
+#ifdef HAVE_X_I18N
+	   mw->menu.font_extents->max_logical_extent.height
+#else
+	   mw->menu.font->ascent + mw->menu.font->descent
+#endif
+	   ) * 2 / 3) | 1;
 }
 
 
@@ -455,7 +478,11 @@
   else
     {
       *height =
-	mw->menu.font->ascent + mw->menu.font->descent
+#ifdef HAVE_X_I18N
+	   mw->menu.font_extents->max_logical_extent.height
+#else
+	   mw->menu.font->ascent + mw->menu.font->descent
+#endif
 	  + 2 * mw->menu.vertical_spacing + 2 * mw->menu.shadow_thickness;
 
       *label_width =
@@ -571,7 +598,13 @@
   double factor = 1.62;
   int thickness2 = thickness * factor;
 
-  y += (mw->menu.font->ascent + mw->menu.font->descent - height) / 2;
+  y += (
+#ifdef HAVE_X_I18N
+	mw->menu.font_extents->max_logical_extent.height
+#else
+	mw->menu.font->ascent + mw->menu.font->descent
+#endif
+	- height) / 2;
 
   if (down_p)
     {
@@ -757,7 +790,13 @@
   width = toggle_button_width (mw);
   height = width;
   x += mw->menu.horizontal_spacing;
-  y += (mw->menu.font->ascent - height) / 2;
+  y += (
+#ifdef HAVE_X_I18N
+	  mw->menu.font_extents->max_logical_extent.height * 9 / 10
+#else
+	  mw->menu.font->ascent
+#endif
+	- height) / 2;
   draw_shadow_rectangle (mw, window, x, y, width, height, False, selected_p);
 }
 
@@ -777,7 +816,13 @@
   width = radio_button_width (mw);
   height = width;
   x += mw->menu.horizontal_spacing;
-  y += (mw->menu.font->ascent - height) / 2;
+  y += (
+#ifdef HAVE_X_I18N
+	  mw->menu.font_extents->max_logical_extent.height * 9 / 10
+#else
+	  mw->menu.font->ascent
+#endif
+	- height) / 2;
   draw_shadow_rhombus (mw, window, x, y, width, height, False, selected_p);
 }
 
@@ -954,8 +999,18 @@
 {
   GC deco_gc;
   GC text_gc;
-  int font_ascent = mw->menu.font->ascent;
-  int font_descent = mw->menu.font->descent;
+  int font_height =
+#ifdef HAVE_X_I18N
+    mw->menu.font_extents->max_logical_extent.height;
+#else
+    mw->menu.font->ascent + mw->menu.font->descent;
+#endif
+  int font_ascent =
+#ifdef HAVE_X_I18N
+	  mw->menu.font_extents->max_logical_extent.height * 9 / 10;
+#else
+	  mw->menu.font->ascent;
+#endif
   int shadow = mw->menu.shadow_thickness;
   int margin = mw->menu.margin;
   int h_spacing = mw->menu.horizontal_spacing;
@@ -1028,7 +1083,12 @@
 	    x_offset += ws->button_width;
 
 
-          XDrawString (XtDisplay (mw), ws->window, text_gc, x_offset,
+#ifdef HAVE_X_I18N
+          XmbDrawString (XtDisplay (mw), ws->window, mw->menu.font,
+#else
+          XDrawString (XtDisplay (mw), ws->window,
+#endif
+		       text_gc, x_offset,
 		       y + v_spacing + shadow + font_ascent,
 		       display_string, strlen (display_string));
 
@@ -1053,7 +1113,12 @@
 		}
 	      else if (val->key)
 		{
-		  XDrawString (XtDisplay (mw), ws->window, text_gc,
+#ifdef HAVE_X_I18N
+		  XmbDrawString (XtDisplay (mw), ws->window, mw->menu.font,
+#else
+		  XDrawString (XtDisplay (mw), ws->window,
+#endif
+			       text_gc,
 			       x + label_width + mw->menu.arrow_spacing,
 			       y + v_spacing + shadow + font_ascent,
 			       val->key, strlen (val->key));
@@ -1065,7 +1130,7 @@
 			      mw->menu.background_gc,
 			      x + shadow, y + shadow,
 			      label_width + h_spacing - 1,
-			      font_ascent + font_descent + 2 * v_spacing - 1);
+			      font_height + 2 * v_spacing - 1);
 	      draw_shadow_rectangle (mw, ws->window, x, y, width, height,
 				     True, False);
 	    }
@@ -1460,21 +1525,33 @@
   XGCValues xgcv;
   float scale;
 
+#ifndef HAVE_X_I18N
   xgcv.font = mw->menu.font->fid;
+#endif
   xgcv.foreground = mw->menu.foreground;
   xgcv.background = mw->core.background_pixel;
   mw->menu.foreground_gc = XtGetGC ((Widget)mw,
-				    GCFont | GCForeground | GCBackground,
+#ifndef HAVE_X_I18N
+				    GCFont |
+#endif
+				    GCForeground | GCBackground,
 				    &xgcv);
 
+#ifndef HAVE_X_I18N
   xgcv.font = mw->menu.font->fid;
+#endif
   xgcv.foreground = mw->menu.button_foreground;
   xgcv.background = mw->core.background_pixel;
   mw->menu.button_gc = XtGetGC ((Widget)mw,
-				GCFont | GCForeground | GCBackground,
+#ifndef HAVE_X_I18N
+				GCFont |
+#endif
+				GCForeground | GCBackground,
 				&xgcv);
 
+#ifndef HAVE_X_I18N
   xgcv.font = mw->menu.font->fid;
+#endif
   xgcv.background = mw->core.background_pixel;
 
 #define BRIGHTNESS(color) (((color) & 0xff) + (((color) >> 8) & 0xff) + (((color) >> 16) & 0xff))
@@ -1500,31 +1577,47 @@
       xgcv.fill_style = FillStippled;
       xgcv.stipple = mw->menu.gray_pixmap;
       mw->menu.disabled_gc = XtGetGC ((Widget)mw,
-				      (GCFont | GCForeground | GCBackground
-				       | GCFillStyle | GCStipple), &xgcv);
+#ifndef HAVE_X_I18N
+				      GCFont |
+#endif
+				      GCForeground | GCBackground
+				      | GCFillStyle | GCStipple, &xgcv);
     }
   else
     {
       /* Many colors available, use disabled pixel.  */
       xgcv.foreground = mw->menu.disabled_foreground;
       mw->menu.disabled_gc = XtGetGC ((Widget)mw,
-				      (GCFont | GCForeground | GCBackground), &xgcv);
+#ifndef HAVE_X_I18N
+				      GCFont |
+#endif
+				      GCForeground | GCBackground, &xgcv);
     }
 
+#ifndef HAVE_X_I18N
   xgcv.font = mw->menu.font->fid;
+#endif
   xgcv.foreground = mw->menu.button_foreground;
   xgcv.background = mw->core.background_pixel;
   xgcv.fill_style = FillStippled;
   xgcv.stipple = mw->menu.gray_pixmap;
   mw->menu.inactive_button_gc = XtGetGC ((Widget)mw,
-				  (GCFont | GCForeground | GCBackground
-				   | GCFillStyle | GCStipple), &xgcv);
+#ifndef HAVE_X_I18N
+					 GCFont |
+#endif
+					 GCForeground | GCBackground
+					 | GCFillStyle | GCStipple, &xgcv);
 
+#ifndef HAVE_X_I18N
   xgcv.font = mw->menu.font->fid;
+#endif
   xgcv.foreground = mw->core.background_pixel;
   xgcv.background = mw->menu.foreground;
   mw->menu.background_gc = XtGetGC ((Widget)mw,
-				    GCFont | GCForeground | GCBackground,
+#ifndef HAVE_X_I18N
+				    GCFont |
+#endif
+				    GCForeground | GCBackground,
 				    &xgcv);
 }
 
@@ -1731,12 +1824,16 @@
 				   gray_bitmap_width, gray_bitmap_height,
 				   (unsigned long)1, (unsigned long)0, 1);
 
+#ifndef HAVE_X_I18N
   /* I don't understand why this ends up 0 sometimes,
      but it does.  This kludge works around it.
      Can anyone find a real fix?   -- rms.  */
   if (mw->menu.font == 0)
     mw->menu.font = xlwmenu_default_font;
-
+#else
+  mw->menu.font_extents = XExtentsOfFontSet (mw->menu.font);
+#endif
+      
   make_drawing_gcs (mw);
   make_shadow_gcs (mw);
 
@@ -1903,7 +2000,10 @@
 
   if (newmw->core.background_pixel != oldmw->core.background_pixel
       || newmw->menu.foreground != oldmw->menu.foreground
-      || newmw->menu.font != oldmw->menu.font)
+#ifndef HAVE_X_I18N
+      || newmw->menu.font != oldmw->menu.font
+#endif
+      )
     {
       release_drawing_gcs (newmw);
       make_drawing_gcs (newmw);
@@ -1929,6 +2029,14 @@
 	  }
     }
 
+#ifdef HAVE_X_I18N
+  if (newmw->menu.font != oldmw->menu.font)
+    {
+      redisplay = True;
+      newmw->menu.font_extents = XExtentsOfFontSet (newmw->menu.font);
+    }
+#endif
+
   return redisplay;
 }
 

--- orig/lwlib/xlwmenuP.h
+++ mod/lwlib/xlwmenuP.h
@@ -43,7 +43,12 @@
 typedef struct _XlwMenu_part
 {
   /* slots set by the resources */
+#ifdef HAVE_X_I18N
+  XFontSet	font;
+  XFontSetExtents *font_extents;
+#else
   XFontStruct*	font;
+#endif
   Pixel		foreground;
   Pixel		disabled_foreground;
   Pixel		button_foreground;

--- orig/src/xmenu.c
+++ mod/src/xmenu.c
@@ -137,6 +137,8 @@
 #ifdef USE_GTK
 /* gtk just uses utf-8.  */
 # define ENCODE_MENU_STRING(str) ENCODE_UTF_8 (str)
+#elif defined HAVE_X_I18N
+# define ENCODE_MENU_STRING(str) ENCODE_SYSTEM (str)
 #else
 # define ENCODE_MENU_STRING(str) string_make_unibyte (str)
 #endif

--- orig/src/xfaces.c
+++ mod/src/xfaces.c
@@ -4695,13 +4695,25 @@
 #else
 	  const char *suffix = "";
 #endif
+#ifdef HAVE_X_I18N
+	  /* Let's build an Xt fontset corresponding to a face.
+	     Maybe we should try and use Mule fontsets more directly, but
+	     for now, we'll stick to this simple solution.  --Stef  */
+	  extern char * xic_create_fontsetname P_ ((char *base_fontname));
+	  char *fontname = xic_create_fontsetname (face->font_name);
+#else
+	  char *fontname = face->font_name;
+#endif
+	  fprintf (stderr, "Setting menu's font : %s\n", fontname);
 	  sprintf (line, "%s.pane.menubar*font%s: %s",
-		   myname, suffix, face->font_name);
+		   myname, suffix, fontname);
 	  XrmPutLineResource (&rdb, line);
 	  sprintf (line, "%s.%s*font%s: %s",
-		   myname, popup_path, suffix, face->font_name);
+		   myname, popup_path, suffix, fontname);
 	  XrmPutLineResource (&rdb, line);
 	  changed_p = 1;
+	  if (fontname != face->font_name)
+	    xfree (fontname);
 	}
 
       if (changed_p && f->output_data.x->menubar_widget)

Re: Non-ASCII in Lucid menus

[Jan D.]

Stefan Monnier wrote:

>Just to make sure I understand your judgment: you think it's not important
>because the difference is minor, or because the "new" default (if
>different") is also different for other apps and so it's still considered as
>a legitimate default, or ...
>  
>

All of the above, but I think applications should be allowed to change 
the defaults as long as it is possible to override it.  Anyway, fonts is 
a matter of taste, you can't please everyone.

>In any case, here is the new improved patch.  This new patch should also
>enable non-ASCII in Motif menus, although I haven't actually checked it.
>

I think you can have that already as long as your menu strings are in 
your locale.  It works for me :-)

    Jan D.

Re: Non-ASCII in Lucid menus

[Stefan Monnier]

>> In any case, here is the new improved patch.  This new patch should also
>> enable non-ASCII in Motif menus, although I haven't actually checked it.

> I think you can have that already as long as your menu strings are in your
> locale.  It works for me :-)

Actually, I doubt this is true because the encoding currently used is
"make_string_unibyte", which can only work for unibyte locales.  This much
also already works with Lucid (no need for my patch here).

Hmmm... in the mean time I actually tried my patch with the Motif toolkit
and my claim fell on its face: At least with the lesstif version in "Debian
testing" the menus do not properly display unicode when the locale is
"fr_CH.UTF-8" (locale with which the Lucid menus do display unicode chars
correctly with my patch).

Actually, the precise behavior of the Motif menus in my test indicated that
the utf-8 decoding wasn't even taking place, and the 8-bit bytes of the ut-8
encoding were basically interpreted as latin-1.  I tried to look at
lwlib-Xm.c to see where was the problem, but I really have even less of
a clue than for xlwmenu.c; maybe the problem is simply due to a limitation
in Lesstif, but I've also tried with OpenMotif-2.2.3 and it doesn't seem to
work any better.  I also tried to fix my "fontList" specs (use semi-colons
to separate entreis, and add a colon terminator), but to no avail.

Actually it seems that Motif always assumes the string passed to it is
latin-1 (e.g. even in a greek locale, the greek chars (encoded by Emacs into
8bit chars before handing them off to Motif) end up displayed as latin-1
accented chars).
So my guess is that we do something wrong (Motif obviously supports more
than just latin-1), but we'd need a programmer familiar with Motif to help
us out.


        Stefan

Re: Non-ASCII in Lucid menus

[Stefan Monnier]

> Actually it seems that Motif always assumes the string passed to it is
> latin-1 (e.g. even in a greek locale, the greek chars (encoded by Emacs

Scratch that.  I finally got it to work (also for utf-8).
OTOH, dynamically changing the font by tweaking the `menu' face
doesn't seem to work on the menu bar.


        Stefan

Re: Non-ASCII in Lucid menus

[Jan D.]

>>> In any case, here is the new improved patch.  This new patch should 
>>> also
>>> enable non-ASCII in Motif menus, although I haven't actually checked 
>>> it.
>
>> I think you can have that already as long as your menu strings are in 
>> your
>> locale.  It works for me :-)
>
> Actually, I doubt this is true because the encoding currently used is
> "make_string_unibyte", which can only work for unibyte locales.  This 
> much
> also already works with Lucid (no need for my patch here).

You are corrent, I only tried the ISO-8859-x charsets.

	Jan D.

Re: Non-ASCII in Lucid menus

[Stefan Monnier]

>>>> In any case, here is the new improved patch.  This new patch should also
>>>> enable non-ASCII in Motif menus, although I haven't actually checked it.
>> 
>>> I think you can have that already as long as your menu strings are in
>>> your
>>> locale.  It works for me :-)
>> 
>> Actually, I doubt this is true because the encoding currently used is
>> "make_string_unibyte", which can only work for unibyte locales.  This much
>> also already works with Lucid (no need for my patch here).

> You are corrent, I only tried the ISO-8859-x charsets.

Actually, with the minor change I installed yesterday, you should be able to
get unicode in Motif menus (provided you run a utf-8 locale and have set
your fontList properly in your .Xresources).


        Stefan

Re: Non-ASCII in Lucid menus

[Richard Stallman]

    In any case, here is the new improved patch.  This new patch should also
    enable non-ASCII in Motif menus, although I haven't actually checked it.

    I'll be happy to keep this patch for post-21.4, but if people feel like this
    is important, I can install it as well.

The failure to support non-ASCII characters in menus is a bug, in my
opinion.  If you've fixed it, and your fix works well, let's install
it now.

Re: Non-ASCII in Lucid menus

[Stefan Monnier]

> The failure to support non-ASCII characters in menus is a bug, in my
> opinion.  If you've fixed it, and your fix works well, let's install
> it now.

Installed,


        Stefan

Re: Non-ASCII in Lucid menus

[Richard Stallman]

Thanks for implementing this.
Is the following TO-DO item now deletable?

** Make the Lucid menu widget display multilingual text.  [This
  probably needs to be done from actual Emacs buffers, either directly
  in the menu or by rendering in an unmapped window and copying the
  pixels.  Note that the relevant Xlib functions assume a specific
  locale; that isn't good enough even if X can render the arbitrary
  text, which it often can't as far as I can tell.  -- fx] [The gtk
  port now displays multilingual text in menus, but only insofar as
  Emacs can encode it as utf-8 and gtk can display the result.]

Please delete it if so.

Re: Non-ASCII in Lucid menus

[Stefan Monnier]

> Thanks for implementing this.
> Is the following TO-DO item now deletable?

> ** Make the Lucid menu widget display multilingual text.  [This
>   probably needs to be done from actual Emacs buffers, either directly
>   in the menu or by rendering in an unmapped window and copying the
>   pixels.  Note that the relevant Xlib functions assume a specific
>   locale; that isn't good enough even if X can render the arbitrary
>   text, which it often can't as far as I can tell.  -- fx] [The gtk
>   port now displays multilingual text in menus, but only insofar as
>   Emacs can encode it as utf-8 and gtk can display the result.]

Well, my patch does not address the issue mentioned by Dave: it can only
display multilingual chars that are part of the user's locale.


        Stefan

Re: Non-ASCII in Lucid menus

[Jan D.]

Stefan Monnier wrote:

>OTOH, dynamically changing the font by tweaking the `menu' face
>doesn't seem to work on the menu bar.
>

It should work now to change the Motif menu bar by changing the menu face.

    Jan D.

Re: Non-ASCII in Lucid menus

[Stefan Monnier]

>> OTOH, dynamically changing the font by tweaking the `menu' face
>> doesn't seem to work on the menu bar.

> It should work now to change the Motif menu bar by changing the menu face.

Yes, it does work.


        Stefan

Re: Non-ASCII in Lucid menus

[Richard Stallman]

    Well, my patch does not address the issue mentioned by Dave: it can only
    display multilingual chars that are part of the user's locale.

Could it select the locale according to the characters to be displayed?

Re: Non-ASCII in Lucid menus

[Stefan Monnier]

>     Well, my patch does not address the issue mentioned by Dave: it can only
>     display multilingual chars that are part of the user's locale.
> Could it select the locale according to the characters to be displayed?

The locale info is embedded somewhere in the Xt widget info (I'm not sure
where, really), so maybe it can be done, but I don't know how.
It's probably easier to temporarily select a utf-8 locale when creating the
widget, so as to get the same behavior as Gtk where the menus always use
utf-8.


        Stefan

Re: Non-ASCII in Lucid menus

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>     Well, my patch does not address the issue mentioned by Dave: it
>>     can only display multilingual chars that are part of the user's
>>     locale.
>> Could it select the locale according to the characters to be displayed?
>
> The locale info is embedded somewhere in the Xt widget info (I'm not sure
> where, really), so maybe it can be done, but I don't know how.
> It's probably easier to temporarily select a utf-8 locale when creating the
> widget, so as to get the same behavior as Gtk where the menus always use
> utf-8.

That sounds very sensible.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Non-ASCII in Lucid menus

[Jan D.]

Stefan Monnier wrote:

>>    Well, my patch does not address the issue mentioned by Dave: it can only
>>    display multilingual chars that are part of the user's locale.
>>Could it select the locale according to the characters to be displayed?
>>    
>>
>
>The locale info is embedded somewhere in the Xt widget info (I'm not sure
>where, really), so maybe it can be done, but I don't know how.
>It's probably easier to temporarily select a utf-8 locale when creating the
>widget, so as to get the same behavior as Gtk where the menus always use
>utf-8.
>

The Xt widget creation code just calls the string to fontset converter 
that in turn XCreateFontSet that in turn calls XCreateOC and then 
finally somewhere there is a call to setlocale(LC_CTYPE, NULL).  So I 
guess the only way to to this is to set LC_ALL or LC_CTYPE in the 
environment prior to widget creation (assuming X does not cache this 
information at startup) as you suggest.

    Jan D.