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

[Nelson Henry Eric]

> > > It turns out that if you choose Japanese dispaly charset 
> > > (or any other from CJK but Korean) - spaces between highlighted fields 
> > > became ommited (corresponds to end-of-line if you look source). 
> > > It is not found before about dev16. 
> > > Just courious. 
> >  
> > Yeah, I'm not sure which is more ugly, Japanese and Chinese WITH 
> > spaces, or English withOUT spaces.  Anyway, if you've got Japanese 
> > (and I assume Chinese) on your display, you don't want spaces just 
> > because someone wrapped a line (why punish people who make their 
> > source readable! :-) 
> But what's the conclusion? - I remember seeing a change that might be the
> one that's producing this effect (but there's a lot to sift through).

Conclusion is that for Chinese and Japanese, interword space is
meaningless.  Therefore introducing a space at a line wrap in the
source means an added artifact that the author did not intend.  I
would agree that the correct way to handle it would be to go on the
basis of the character set of the document, but there are just too
many unlabled documents out there.  If someone has their display
charset set for Japanese or Chinese, then I assume they plan to
read Japanese or Chinese and don't want extra spaces thrown in.  If
someone wants to read a language that requires interword space, they
should set their display charset to that language.

I made the patch, and it was incorporated in the "1998-08-29 (2.8.1dev.23)"
CHANGES: "* don't replace '\n' with ' ' if Chinese or Japanese - HN".
If someone has the interest and the programming skills, then a "better"
alternative I suppose would be to test if Lynx is really getting a multi-
byte stream or not, and only _not_ add the space if that's true.  Seems to
add more complexity than necessary, but the "big two" do handle interword
space correctly in mixed documents, and it's nice I admit.

__Henry