lkml.org 
[lkml]   [2007]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] console UTF-8 fixes
On Tue, Apr 10, 2007 at 10:30:07AM -0700, H. Peter Anvin wrote:

> Really? Why is CJK so much more fundamental than, say, Arabic?

Not more fundamental at all. It's just perhaps easier to "support" (I mean
keep track of the cursor, not to really support them of course).

I can't see any reason why these two scripts should be handled identically:
either support both or none. If it's technically easier to support one and
harder to support the other, why not implement the first now? Maybe someone
will implement the other one later.

Oh! Wait a moment! I haven't yet looked at bidi in Unicode, but taking the
first glimpse it seems to me that U+200E and U+200F control the writing
direction. Currently the kernel already skips 200E and 200F, doesn't print
anything, not even a replacement character (see char/consolemap.c). This
means that RTL is already "supported" at this level: eventually (when RTL
mode is turned off) the cursor stands where it is expected to stand. In
between, you either see the right number of replacement symbols, or (if your
font supports Arabic) you may see the symbols in reverse order. So, after
all, it's not worse at all than what I want to reach with CJK.



--
Egmont
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-04-10 20:55    [from the cache]
©2003-2011 Jasper Spaans