Re: lynx-dev lynx2.8.2dev.19 patch #6 (em dash = --)

[Klaus Weide]

On Thu, 18 Mar 1999, Leonid Pauzner wrote:
> 16-Mar-99 20:28 Klaus Weide wrote:
> > On Wed, 17 Mar 1999, Leonid Pauzner wrote:
> >> 16-Mar-99 12:18 Klaus Weide wrote:
> >> > Besides, the character translations are also used within PRE etc., and
> >> > even in translated  plain text, so there is a good reason to leave
> >>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^no, no &emsp symbol in any 8bit font.
> 
> > Think
> 
> >    HTTP/1.0 200 OK
> >    .....
> >    Content-type: text/plain;charset=utf-8
> >    .....
> 
> Probably. (I have no idea how utf-8 console work about such spaces
> with a fixed-width screen font).

But you don't need  Display character set == Document charset,
that's the whole point of the chartrans stuff.  :)


About how utf-8 console works in general - not too well in more
complex cases (where there are more than a few non-US-ASCII characters
per line), except possibly when compiled with slang and
SLANG_MBCS_HACK.  Not tested in a while.

About how utf-8 for linux console (the only situation I know where
Display character set == UTF-8 makes sense) would work for a U+2003 -

 (1) either it gets translated to "normal" space(s) by lynx,
     so no special consideration necessary, or

     (if it should get fed as utf-8 to the output)
 (2) it depends on the currently loaded (linux kernel) console
     translation tables - usually it would end up as one space
     or one unknown character symbol, but if no mapping loaded and no
     unknown character symbol either, it could end up as "nothing"
     i.e. zero space (which then brings the cursor position out of
     synch with what lynx thinks, but that is a general problem not
     limited to U+2003).  In no case will it use more than one space.


     Klaus