Re: LYNX-DEV Unicode support: charsets

[Klaus Weide]

On Wed, 4 Dec 1996, Drazen Kacar wrote:

> Klaus, I still don't know if console on OSF 4.0 can deal with Unicode or not,
> but I've found out something else. I can't stand Linux only things :) Yur docs
> say:
> 
>  - EXPERIMENTAL, currently enabled only for Linux console: 
>    can (attempt to) automatically switch terminal mode and load new
>    code pages on change of display character set.
> 
> The fact is that plain old xterm can do this. Here's the escape sequence:
> 
> ESC ] 5 0 ; "font name" BEL
> 
> For example:
> 
> ^[]50;-dec-terminal-medium-r-normal--14-140-75-75-c-80-iso8859-2^G
> 
> Only one code page at the screen can be active this way and xterm will
> resize itself if the font size changes. There might be a way to have more
> than one code page, but I think special fonts are needed for that. Xterm
> can switch fonts, but only the lower 128 chars. Don't ask me why not the
> higher ones as well. Esc codes exist, but xterm docs say that they have
> no visible effect in xterm. I've checked, they don't. Even if this was
> possible, there'd be big problems with curses package which wouldn't know
> it should send some esc codes. I suppose you can bypass it somehow for
> the initializating sequence.

If it switches only the lower 128 chars, it's of course useless for most
cases.  All the differences between e.g. iso8859-1 and iso8859-2 are in 
the upper 128 chars, and we probably always need the ASCII chars available.

> But, there is another trick for color xterm. I didn't check this one out,
> because I don't know enough about Athena Widget Set. Basicaly, you can
> define which font will be used for bold chars on a particular xterm.
> You do this either by command line option or with Xdefaults. If there is
> color, bold is not really needed and it can be dumped in favor of normal
> font in another code page. Changing the fonts dinamically (ie. from
> running Lynx processs) is beyond my abilities, but perhaps someone can do
> the trick. If it's possible, there can be any two active code pages. If it
> isn't, the user can (if he/she wants to) select two fixed code pages
> before running xterm with Lynx. Or the bold font can be made fixed, and
> you can change the normal one with esc sequence. This is a bit wierd, but
> there is no esc code for changing bold font.

For this to work, all use of bold in the current code would have to be
weeded out.  Then all code that may turn bold OFF also would have to be
changed, to not do this if the bold state is used for some other purpose
than, err, bolding.  Well I'll gladly leave that to Rob if he wants to
do this, or someone else...

Frankly, I don't see much need for lynx-controlled codepage switching
if Lynx is running in an xterm (or rxvt).  In that case you could
always run another copy of Lynx in a different window, which could
have any font you want.  You can have one window for viewing iso8859-1
pages, another for iso8859-2, another for KOI8 etc. all at the same
time (whereas the bold hack would probably give at most one
alternative codepage), and you have a mouse to cut and paste URLs
between the windows if necessary.  (I assume that if you have enough
memory for running X you can also afford to run several copies of Lynx...)

Add to that that I am trying to avoid using X when possible, and then
calculate the likelihood that I will try to implement one of your
ideas...  But anyway the code for doing the switching is nearly
self-contained and independent of the other chartrans code, it is just
one function that gets called (hopefully..) in the right place and
gets passed an argument indicating which character set to switch to.
It is in a separate new file, UCAuto.c.  So it should be fairly easy
for anybody who wishes to support this for another system, assuming
there is a simple way (emit an escape sequence or run a system
command) to do it on that system.

  Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;