[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bidi and shaping problems in describe-input-method

From: Kenichi Handa
Subject: Re: bidi and shaping problems in describe-input-method
Date: Fri, 09 Mar 2012 00:30:25 +0900

In article <address@hidden>, Mohsen BANAN <address@hidden> writes:

  Mohsen> The second problem is shaping related:
  Mohsen> Inside of a cell on the keyboard layout, when
  Mohsen> there are two characters that can be joined, they
  Mohsen> are joined -- be default. They should not be.

  Eli> How can one know when they should be joined and when not?

> I think the simple answer is: always isolated -- never joined.

> For Persian and Arabic I am sure that they should
> never be joined -- always isolated. 


> For other shaped languages, it is hard to imagine
> an input method designer would ever want them joined.

I agree.

> For non-shaped languages (e.g., latin keyboards)
> the insertion of an zero width non-joiner between
> lower and upper case is harmless and invisible.

> So, the simplest fix (and perhaps
> the-right-thing-to-do) is to ALWAYS insert a
> (ucs-insert 8204)‌ -- zero width non-joiner --
> between the two characters in each and every
> keyboard cell.

If we insert something unconditionally, I think inserting
(propertize " " 'invisible t) is safer.  It should work on
tty terminal too.

By the way, for this bug:

  Mohsen> In the case of 'arabic note how the entire
  Mohsen> keyboard is flipped to the right.

just setting bidi-paragraph-direction to 'left-to-right is
not enough, because keyboard cells in a row are still
re-ordered.  For this, the easiest fix is to set
bidi-display-reordering to nil.  But, then we can't use
actual Arabic and Hebrew words in the docstrings of those
input methods.  What we want is to display bidi reordering
only for the keyboard layout part.  Eli, don't you have any
good idea?

Kenichi Handa

reply via email to

[Prev in Thread] Current Thread [Next in Thread]