headers
mhibti | 7 Sep 2010 17:08
Picon
Favicon

Re: Re: Arabic support

You are right !

After invoking emacs -q I could do the following :

- copy from emacs to another application (it worked).
- copy arabic text from two different applications to emacs 
it works correctly exepted that tashkeel seems lost when the source include it.
But after verification if I try to mark the region in question the tashkeel appears :)

In my dot emacs i found what may be the cause of my problem.

 '(selection-coding-system (quote utf-8-dos))
 '(unify-8859-on-decoding-mode t)
 '(unify-8859-on-encoding-mode t)

Thanks

----- Mail Original -----
De: "Eli Zaretskii" <eliz <at> gnu.org>
À: mhibti <at> free.fr
Cc: emacs-bidi <at> gnu.org, emacs-devel <at> gnu.org
Envoyé: Mardi 7 Septembre 2010 06h39:53 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: Re: [emacs-bidi] Re: Arabic support

> Date: Tue, 7 Sep 2010 05:34:04 +0200 (CEST)
> From: mhibti <at> free.fr
> Cc: emacs-bidi <at> gnu.org, emacs-devel <at> gnu.org
> 
> It is simple. When copying a text in arabic (see pictures) and
> pasting in the emacs buffer, the result is a series of "?"
(Continue reading)

Permalink | Reply |
headers
Eli Zaretskii | 13 Sep 2010 08:40
Picon

Re: Re: Arabic support

> Date: Tue, 7 Sep 2010 17:08:01 +0200 (CEST)
> From: mhibti <at> free.fr
> Cc: emacs-bidi <at> gnu.org, emacs-devel <at> gnu.org
> 
> - copy arabic text from two different applications to emacs 
> it works correctly exepted that tashkeel seems lost when the source include it.
> But after verification if I try to mark the region in question the tashkeel appears :)

It's probably some bad interaction between compositions and the
handling of faces in the bidirectional display.  Perhaps Handa-san
could take a look at xdisp.c:handle_stop_backwards and how it is
called inside next_element_from_buffer -- there might be some bugs
there whereby only part of the composed sequence is redrawn when the
region is extended or contracted.

> In my dot emacs i found what may be the cause of my problem.
> 
> 
>  '(selection-coding-system (quote utf-8-dos))

This one is your problem: you should never do that on MS-Windows.

>  '(unify-8859-on-decoding-mode t)
>  '(unify-8859-on-encoding-mode t)

These are obsolete, as everything is always unified in Emacs 24.
Permalink | Reply |
headers
Kenichi Handa | 16 Sep 2010 04:07

Re: Re: Arabic support

In article <83eicy5epd.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:

> It's probably some bad interaction between compositions and the
> handling of faces in the bidirectional display.

I found that the problem is that the current composition for
Arabic requires that a whole word must be composed.  So, if
there's a face change within a word, Arabic composition
function is given just a partial word, and that results in
the incorrect Arabic shaping.  This is a difficult problem,
and I need a time to find a solution.

---
Kenichi Handa
handa <at> m17n.org
Permalink | Reply |
headers
Kenichi Handa | 22 Sep 2010 05:54

Re: Re: Arabic support

In article <tl77himmofd.fsf <at> m17n.org>, Kenichi Handa <handa <at> m17n.org> writes:

> In article <83eicy5epd.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:
> > It's probably some bad interaction between compositions and the
> > handling of faces in the bidirectional display.

> I found that the problem is that the current composition for
> Arabic requires that a whole word must be composed.  So, if
> there's a face change within a word, Arabic composition
> function is given just a partial word, and that results in
> the incorrect Arabic shaping.  This is a difficult problem,
> and I need a time to find a solution.

I've just installed a fix to trunk.

---
Kenichi Handa
handa <at> m17n.org
Permalink | Reply |
headers
Eli Zaretskii | 22 Sep 2010 09:33
Picon

Re: Re: Arabic support

> From: Kenichi Handa <handa <at> m17n.org>
> Cc: eliz <at> gnu.org, emacs-bidi <at> gnu.org, mhibti <at> free.fr, emacs-devel <at> gnu.org
> Date: Wed, 22 Sep 2010 12:54:26 +0900
> 
> In article <tl77himmofd.fsf <at> m17n.org>, Kenichi Handa <handa <at> m17n.org> writes:
> 
> > In article <83eicy5epd.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:
> > > It's probably some bad interaction between compositions and the
> > > handling of faces in the bidirectional display.
> 
> > I found that the problem is that the current composition for
> > Arabic requires that a whole word must be composed.  So, if
> > there's a face change within a word, Arabic composition
> > function is given just a partial word, and that results in
> > the incorrect Arabic shaping.  This is a difficult problem,
> > and I need a time to find a solution.
> 
> I've just installed a fix to trunk.

Thanks.
Permalink | Reply |
headers
Thamer Mahmoud | 22 Sep 2010 14:27
Picon

Re: Arabic support

Kenichi Handa <handa <at> m17n.org> writes:
>> I found that the problem is that the current composition for
>> Arabic requires that a whole word must be composed.  So, if
>> there's a face change within a word, Arabic composition
>> function is given just a partial word, and that results in
>> the incorrect Arabic shaping.  This is a difficult problem,
>> and I need a time to find a solution.
>
> I've just installed a fix to trunk.

I can confirm that the issue with unshaped glyphs while highlighting
words is now fixed.  Thanks.

However, long Arabic strings still have unshaped middle parts and bad
margin.  See the attached screenshot which is the output of M-30-≤BAA>
in an empty buffer.

Also the following code produces duplicate strings, compared to when
auto-composition-mode is off.

(let ()
  (setq bidi-display-reordering t)
  (insert "\n\n")
  (insert "كمنت")
  (insert "ببببببببببببببببببب"))
(Continue reading)

Permalink | Reply |
headers
Kenichi Handa | 27 Sep 2010 07:56

Re: Re: Arabic support

In article <87aananet1.fsf <at> zemblan.newkuwait.org>, Thamer Mahmoud <thamer.mahmoud <at> gmail.com> writes:

> However, long Arabic strings still have unshaped middle parts and bad
> margin.  See the attached screenshot which is the output of M-30-≤BAA>
> in an empty buffer.

Ah, I found what is wrong.  In "struct glyph", we now have
only 4 bits to store indices into an LGSTRING.

    struct
    {
      /* Flag to tell if the composition is automatic or not.  */
      unsigned automatic : 1;
      /* ID of the composition.  */
      unsigned id    : 23;
      /* Start and end indices of glyphs of the composition.  */
      unsigned from : 4;
      unsigned to : 4;
    } cmp;

So, we could handle at most 16 glyphs in one composition.
I've just installed a fix to remove that restriction
(theoretically we still have a restriction of at most
0x7FFFFFFF glyphs in one composition).

---
Kenichi Handa
handa <at> m17n.org
Permalink | Reply |

Gmane