Re: Persian joining and Pango.

[Jeff Sparkes <jsparkes gmail com>]

On Sat, Nov 19, 2011 at 3:30 AM, Aidan Kehoe <kehoea parhasard net> wrote:

 Ar an t-ochtú lá déag de mí na Samhain, scríobh Jeff Sparkes:

 > Aidan Kehoe <kehoea parhasard net> writes:
 >
 > >  > > I am one of the three people most familiar with the XEmacs
 > >  > > codebase in the world, and I was asking where to start :-)
 > >  > > . Thanks for having looked.
 > >  >
 > >  > Well, start by checking what exactly is passed to
 > >  > pango_layout_set_text(), and also what font is used (you can pmap
 > >  > the process and grep for fonts).
 > >

 > > Thanks, that’s very helpful.

 >
 > Sorry I disappeared for a few months, but I'm back working on Gtk.
 > I just updated the code to use pango_itemize, which should handle RTL
 > languages better.  The characters seem to be in the right order but
 > the words are not.  XEmacs-gtk display now matches gedit for Arabic
 > and Persian.  They don't match FSF emacs display, but I think the
 > pango is correct.  (Firefox and IE agree with pango)

To get the Persian-specific characters to join (n.b. these are characters
that are not in iso-88859-6) I need the below patch; basically we should
have taken the decision years ago to leave whether splitting character runs
based on Mule charsets is appropriate, to the platform-specific code.

 > Editing RTL is wrong, just moving the cursor through the string makes
 > the characters dance.

Right, I see that too.

I should have put a smiley there.  RTL is a lot of work, all I know about it is from postings by Eli Zaretskii on emacs-devel list.   I think the dancing characters are caused by having a separate textual_run containing only the character covered by the cursor. I'd just like to get display working well, e.g. for reading email.

As I understand it, this patch makes the input text be split into chunks, each one containing either all ascii or all non-ascii chars.  I think even that is unnecessary, but avoiding it would require changing the code flow, right?

I  just checked my current gtk_output_string(), which doesn't call separate_textual_runs at all.   This xlike file patches shouldn't be needed at all.

WIll the redisplay.c changes break tty display when compiled with gtk?

diff -r 2770fc9ad918 src/console-xlike-inc.h
--- a/src/console-xlike-inc.h   Fri Nov 04 11:22:51 2011 -0400
+++ b/src/console-xlike-inc.h   Fri Nov 18 19:32:00 2011 +0000
@@ -219,6 +219,7 @@
 #define XLIKE_SET_GC_COLOR(lval, rval) ((lval) = (rval).pixel)
 #define XLIKE_SET_GC_PIXEL(lval, rval) ((lval) = (rval))
 #define XLIKE_FONT_NUM(val) ((val)->fid)
+#define XLIKE_ICHAR_CHARSET(c) ichar_charset (c)

 /************ End X flavor of XLIKE **********/

@@ -331,6 +332,7 @@
 #define XLIKE_SET_GC_COLOR(lval, rval) ((lval) = (rval))
 #define XLIKE_SET_GC_PIXEL(lval, rval) ((lval).pixel = (rval))
 #define XLIKE_FONT_NUM(val) (val)
+#define XLIKE_ICHAR_CHARSET(c) Vcharset_ascii

 /************ End GTK flavor of XLIKE **********/

diff -r 2770fc9ad918 src/redisplay-xlike-inc.c
--- a/src/redisplay-xlike-inc.c Fri Nov 04 11:22:51 2011 -0400
+++ b/src/redisplay-xlike-inc.c Fri Nov 18 19:32:00 2011 +0000
@@ -683,7 +195,9 @@
  findex = rb->findex;
  xpos = rb->xpos;
  if (rb->type == RUNE_CHAR)
-    charset = ichar_charset (rb->object.chr.ch);
+    {
+      charset = XLIKE_ICHAR_CHARSET (rb->object.chr.ch);
+    }

  if (end < 0)
    end = Dynarr_length (rba);
@@ -695,7 +209,7 @@

      if (rb->findex == findex && rb->type == RUNE_CHAR
         && rb->object.chr.ch != '\n' && rb->cursor_type != CURSOR_ON
-         && EQ (charset, ichar_charset (rb->object.chr.ch)))
+         && EQ (charset, XLIKE_ICHAR_CHARSET (rb->object.chr.ch)))
       {
         Dynarr_add (buf, rb->object.chr.ch);
         width += rb->width;
@@ -718,7 +232,7 @@
           {
             findex = rb->findex;
             xpos = rb->xpos;
-             charset = ichar_charset (rb->object.chr.ch);
+             charset = XLIKE_ICHAR_CHARSET (rb->object.chr.ch);

             if (rb->cursor_type == CURSOR_ON)
               {
diff -r 2770fc9ad918 src/redisplay.c
--- a/src/redisplay.c   Fri Nov 04 11:22:51 2011 -0400
+++ b/src/redisplay.c   Fri Nov 18 19:32:00 2011 +0000
@@ -631,11 +631,16 @@
 redisplay_window_text_width_ichar_string (struct window *w, int findex,
                                         Ichar *str, Charcount len)
 {
+  Lisp_Object window = wrap_window (w);
  unsigned char charsets[NUM_LEADING_BYTES];
-  Lisp_Object window;
-
+
+#ifdef HAVE_GTK
+  memset (charsets, 0, NUM_LEADING_BYTES);
+  charsets[0] = 1;
+#else
  find_charsets_in_ichar_string (charsets, str, len);
-  window = wrap_window (w);
+#endif
+
  ensure_face_cachel_complete (WINDOW_FACE_CACHEL (w, findex), window,
                              charsets);
  return DEVMETH (WINDOW_XDEVICE (w),
@@ -681,7 +686,12 @@
  if (STRINGP (reloc))
    nonreloc = XSTRING_DATA (reloc);
  convert_ibyte_string_into_ichar_dynarr (nonreloc, len, rtw_ichar_dynarr);
+#ifdef HAVE_GTK
+  memset (charsets, 0, NUM_LEADING_BYTES);
+  charsets[0] = 1;
+#else
  find_charsets_in_ibyte_string (charsets, nonreloc, len);
+#endif
  reset_face_cachel (&cachel);
  cachel.face = face;
  ensure_face_cachel_complete (&cachel,
@@ -1108,7 +1118,7 @@
    }
  else
    {
-      Lisp_Object charset = ichar_charset (data->ch);
+      Lisp_Object charset = Vcharset_ascii;
      if (!EQ (charset, data->last_charset) ||
         data->findex != data->last_findex)

       {


--
‘Iodine deficiency was endemic in parts of the UK until, through what has been
described as “an unplanned and accidental public health triumph”, iodine was
added to cattle feed to improve milk production in the 1930s.’
(EN Pearce, Lancet, June 2011)

-- 
Jeff Sparkes
jsparkes gmail com