Persian joining and Pango.

[Jeff Sparkes]

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

>
>  Ar an t-ochtú lá déag de mí na Samhain, scríobh Jeff Sparkes:
>
>  > Aidan Kehoe <kehoea at 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 at gmail.com