[lkml]   [2007]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-04-10 20:55    [W:0.020 / U:45.692 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site