On Fri, Jan 04, 2008 at 12:48:54AM +0200, Khaled Hosny wrote: > On Fri, Jan 04, 2008 at 12:00:00AM +0200, Mohammed Sameer wrote: > > On Thu, Jan 03, 2008 at 03:35:42PM +0200, Khaled Hosny wrote: > > > On Thu, Jan 03, 2008 at 01:32:55PM +0200, Mohammed Sameer wrote: > > > > On Wed, Jan 02, 2008 at 04:58:02PM +0200, Khaled Hosny wrote: > > > > > I just submitted a patch[1] that removes the various Lam-Alef presentation > > > > > forms from Arabic keyboard layout, this should temporally fix the > > > > > well-known lam-alef problem[2]. To avoid confusing the user, the b, > > > > > shoft-b, shitf-g and shift-t keys in the Arabic keyboard (should produce > > > > > لا, لآ, لأ and لإ respectively) will now produce nothing. > > > > > > > > > > 1. https://bugs.freedesktop.org/show_bug.cgi?id=13894 > > > > > 2. https://bugs.freedesktop.org/show_bug.cgi?id=8195 > > > > > > > > > > > > > No. I'm sure they are there for a reason even if we don't know what it is. > > > > Isam Baiazidi was the one who added them. I'd rather ask him about the consequences > > > > first before removing them. I know they are causing problems and I'm always implementing > > > > workarounds for them but we need to know why were they added. > > > > > > > For whatever the reason, this shouldn't ever happened, presentation > > > forms are here for computability with legacy systems and shouldn't be > > > used to encode text, this is even discouraged[1] by Unicode standard. > > > > > > Even if we agreed on necessity of using them, then we will need 12 keys > > > for them; 4 letters × 3 contextual forms, cause we are now just using > > > one contextual form (isolated) for all cases, with is IMHO non-sense and > > > is the source of the rendering problem. > > > > > > Having a separate key for Lam-Alef belongs to metal typesetting era and, > > > for no good reason, it survived in the digital era. > > > > > > I can't see any good use for them, however, I had no idea who added them > > > to ask. > > > > > > 1. http://unicode.org/faq/middleeast.html#0 > > > > It'll still be a regression. The proper fix is to fix xkb itself. > > Regression from what? I agree it is a regression from the expected > behaviour, but not from the current, definitely broken, behaviour. A > proper fix should involve xkb for sure, but I don't have the knowledge > to do that myself and no body is welling to fix it. Regression from both the current and the expected. Daniel Stone is taking over. Check their bugzilla. -- GPG-Key: 0xA3FD0DF7 - 9F73 032E EAC9 F7AD 951F 280E CB66 8E29 A3FD 0DF7 Debian User and Developer. Homepage: www.foolab.org
Attachment:
signature.asc
Description: Digital signature