> I can't understand why you wrote "it is best done outside of Lynx".
It's the "Lynx way," as I see it. A lynx, as you know, is a small
wild cat. We tend to associate the characteristics of lighting speed
and elusiveness with that animal. As we continue to load up Lynx
with functions peripheral to a client's access and use of Web resources,
such as proxying and word processing, it begins to look more and more
like an over-fed tabby.
Also, I personally feel very indebted to the Lynx community for allowing
us to have language-specific CJK code completely integrated into Lynx.
I am very hesitant to expand on what has been offered to us if at all
possible, especially if it is *not essential*.
> And I think if NKF handles 1-byte kana well,
> it means there is a room to improve Lynx to handle them well.
That is exactly what I am saying (have been saying for some time).
Just one person's opinion, but I also think the guessing routines in
"qkc" are better than Lynx's and could perhaps be adopted.
> > either by the server or a META in the document. What would it take to
> > use that "x-sjis" to trigger better performance of the code-conversion
> > routines, and leave as a last resort manual override (or proxy/gateway)
> > handling?
>
> I agree.
At least a goal to work toward.
__Henry
