> >Now imagine how "intuitive" it would be for the display to present
> > '('
> >While the keycap on the keyboard is marked (on the plastic) with:
> > ')'
>
> It won't be. But in order for it to come out right, and behave according
> to the "logical" Hebrew standard, two things must happen. The first is
> that the keyboard send out the "wrong" key, i.e. - I press the thing
> marked ")", and the keyboard sends ASCII, or rather, UNICODE 0x0028
> (also known as "(", or "open paranthesis). The reason being that open
> paranthesis is what you meant. When in Hebrew, the open paranthesis are
> on the right.
>
> Now, in order for the display to display it properly, and open
> paranthesis must be rendered as ")" rather than "(", as it normally
> does. Guess what, the Unicode standard does, in fact, dictate that
> character 0x0028, when in right to left context, should be displayed as
> the glyph that belongs to 0x0029.
>
> After this long explanation, what do we have? We now know that we want a
> keyboard that does things "backwards", and a display engine that
> reverses this back. Believe me, there are good reasons (which I have
> tried to explain in my previous mail) why this is preferable to doing
> things as they have been done up until now.
That is exactly the point. Unicode defines 0x0028 as "open paranthesis" and
_not_ as "left paranthesis". So in right to left context, 0x0028 will be
displayed as ")". To still have what you type and what yu see agree, the key
that looks like ")" has to be mapped to 0x0028.
The reason you're gettting problems is that older XFree versions had this
wrong, and in order to still be able to conform to the Unicode standard (and
do logical hebrew), Qt had to introduce a rather ugly hack that reverses the
braces if in right to left context (when we get them from the input). This
was known to be wrong but a workaround to make your life easier as long as
the xfree keyboard wasn't fixed. Maybe I should have never introduced this
hack.
> So, if everything is so cool how come things break, you ask? Because,
> while the keyboard was corrected, the display engine was not yet. As a
> result, things turn out backwards on screen, even though they are
> correctly represented in memory. This will also hold true to files
> imported from other platforms.
Well, at least for Qt, the display engine is actually correct, we do the hack
only on the key presses we get when in right to left context. See one of my
earlier mails on how to remove that hack in Qt and getting working as it
should.
> So, instead of complaining about the change to the input method,
> complain that the output method is not yet up to date. This will make
> things much more productive all around.
>
> >Now that people started reversing keys, I can only extrapolate...
> > - Let's map F1 <-> F12, F2 <-> F11, (RTL Function-key order)
> > - Let's change '/' into '\' (RTL pathnames are great)
> > - Let's change '+' into '-' (my brain has melted)
>
> No, but it should change "<" to ">", and "[" to "]" for similar reasons.
>
> >Seriously, let's keep one simple principle:
> > A key produce the character painted on its keycap.
This is _not_ generally possible with the way unicode works (and I hope you
agree that having Unicode as a common standard is a good thing, whether you
like some implementation details or not).
It will produce the character painted on the keycap if your writing direction
and the direction implied by your keyboard layout agrees. That measn it will
work correctly if you write english on an english keyboard or hebrew on a
hrebrew keyboard. If you however edit an english paragraph using a hebrew
keyboard and all you insert are two braces, then they will be reversed from
what you see on your keycap.
Cheers,
Lars
> Agreed, but that does not necessarily means it is not converted back and
> forth on it's way.
>
> Sh.
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
