Re: lynx-dev Japanese & spaces in forms-options menu

[Nelson Henry Eric]

> This generally right but 7 bit us-ascii is the special case
> which should be recognized automatically.

Very true.  Unfortunately it's beyond what I could do.

> A simplest way - check whether the previous character is from 20-7E or not.
> But EUC-JP seems use "ISO 2022 rules" to select whether 20-7E byte is us-ascii
> depending on SS2 and SS3 flags...
[...]
> Name: Extended_UNIX_Code_Packed_Format_for_Japanese
[...]
>                code set 2: Half Width Katakana (a single 7-bit byte set)
>                            requiring SS2 as the character prefix
[...]
> Alias: EUC-JP  (preferred MIME name)

AFAIK, Lynx doesn't handle 7-bit katakana very well; they really
will throw Lynx off.  Anyway, if you're willing and have the time
and interest, you would have at least one very appreciative Lynx
user if you could fix Lynx to not put spaces in multibyte C or J,
AND put in spaces for us-ascii.

When I was looking around for a solution to _my_ problem, this
comment in GridText.c caught my attention:
                    /*
                     *  For now, load 'M' into LastDisplayChar,
                     *  but we should check whether it's white
                     *  and if so, use ' '.  I don't know if
                     *  there actually are white CJK characters,
                     *  and we're loading ' ' for multibyte
                     *  spacing characters in this code set,
                     *  but this will become an issue when
                     *  the development code set's multibyte
                     *  character handling is used. - FM
                     */
JFTR, there is a multibyte space character in Japanese: "$B!!(J".

__Henry