[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: |
Sat, 10 Mar 2012 11:55:54 +0900 |
In article <address@hidden>, Eli Zaretskii <address@hidden> writes:
> > In general, it's smarter to use LRM only where necessary.
> Testing whether they are necessary is a problem in itself. You can
> easily avoid inserting the marks for strong L2R characters, but they
> are the minority. Most of the characters are not in that category.
> And of course keyboard layouts include such characters.
> > > > (defun quail-help-require-LRM (char)
> > > > (or (eq (get-char-code-property char 'bidi-class) 'L)
> > > > ...))
> >
> > > It's possible, but why bother? And with this function you will insert
> > > the LRM for many characters that don't need that, like punctuation,
> > > numbers, etc.
> >
> > ??? I want a function that returns t only for a character
> > that require preceding LRM in the keyboard layout.
> Yes, I understand that. But the test you are suggesting, i.e. avoid
> the LRM only for characters whose bidi-class is L, will not catch
> numbers, punctuation, and other non-L characters.
The function body I wrote is just an idea, not a complete
solution, and of cource checking against L is apparently
a bug. At least we must check against R (and AL).
> > > Also, `lower' and `upper' could be strings, in which case you need a
> > > more complex test.
> >
> > We can give (if (string lower) (aref lower 0) lower) to that
> > function.
> But that doesn't DTRT. Here's an example where it will fail: ".A".
Why? Keyboard cells in the keyboard layout has typically
this form: (L is for lower key, U is for upper (shifted) key)
... | LU | LU | ...
What we want is to display the left LU to the left of the
right LU, and display each L (character or string) to the
right of the corresponding U.
Even if the L (of the left LU) is ".A", we don't need LRM
for it. We have to insert LRM only before a character that
may reorder the previous characters, and after a character that
may reorder the following character. Isn't it right?
> AFAIK, the only reliable way of telling whether a given string will be
> reordered is to actually reorder it, and then compare with the
> logical-order original. That's a nuisance, and also the results may
> well depend on the characters before and after the string in the
> buffer, so you need to know the context in advance, which you normally
> don't.
> I tried also a different solution: enclose each row of the keyboard
> layout in an L2R override embedding, LRO..PDF. This inserts only 2
> control characters per row, and doesn't insert them inside the
> keyboard cells, so it is cleaner, I think. But using this means that
> no key description in the layout can be a string that requires
> reordering individually. (By contrast, inserting an LRM between the
> lower and the upper key still allows each description to be
> reordered.) Can we live with such a restriction? I don't know enough
> about Quail to tell.
As it's possible to assign a string to a key, there will be
the case that the characters in the string must be
reordered. In the above case, if L is a hebrew "שלום", it
must be reordered. But, even if we surround that word with
LRE and PDF, the word itself is reordered correctly, right?
---
Kenichi Handa
address@hidden
- bidi and shaping problems in describe-input-method, Mohsen BANAN, 2012/03/06
- Re: bidi and shaping problems in describe-input-method, Eli Zaretskii, 2012/03/06
- Re: bidi and shaping problems in describe-input-method, Eli Zaretskii, 2012/03/07
- Re: bidi and shaping problems in describe-input-method, Mohsen BANAN, 2012/03/07
- Re: bidi and shaping problems in describe-input-method, Kenichi Handa, 2012/03/08
- Re: bidi and shaping problems in describe-input-method, Eli Zaretskii, 2012/03/08
- Re: bidi and shaping problems in describe-input-method, Kenichi Handa, 2012/03/08
- Re: bidi and shaping problems in describe-input-method, Eli Zaretskii, 2012/03/09
- Re: bidi and shaping problems in describe-input-method, Kenichi Handa, 2012/03/09
- Re: bidi and shaping problems in describe-input-method, Eli Zaretskii, 2012/03/09
- Re: bidi and shaping problems in describe-input-method,
Kenichi Handa <=
- Re: bidi and shaping problems in describe-input-method, Eli Zaretskii, 2012/03/10
- Re: bidi and shaping problems in describe-input-method, Kenichi Handa, 2012/03/12
- Re: bidi and shaping problems in describe-input-method, Eli Zaretskii, 2012/03/12
- Re: bidi and shaping problems in describe-input-method, Kenichi Handa, 2012/03/12
- Re: bidi and shaping problems in describe-input-method, Eli Zaretskii, 2012/03/12
- Re: bidi and shaping problems in describe-input-method, Kenichi Handa, 2012/03/22
- Re: bidi and shaping problems in describe-input-method, Eli Zaretskii, 2012/03/22
- Re: bidi and shaping problems in describe-input-method, Kenichi Handa, 2012/03/22
- Re: bidi and shaping problems in describe-input-method, Eli Zaretskii, 2012/03/23
- Re: bidi and shaping problems in describe-input-method, Mohsen BANAN, 2012/03/22