lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev lynx and other character sets


From: David Woolley
Subject: Re: lynx-dev lynx and other character sets
Date: Tue, 29 Jun 1999 08:48:38 +0100 (BST)

> 
> 2. What do you mean by display character set? Where is it defined? In a 
> terminfo database
> or similar? What should I do if I want to define a display myself to support 
> my character set?

The display character set is the one used by your terminal.  For a
US or UK MS-DOS machine, it will be IBM code page 437; for an 8 bit
terminal in the US or UK, it would probably be ISO 8859/1; for a 7 bit
terminal it would be ISO 646, where the reference version of ISO 646 is
the same as ASCII, but there is, for example, a UK version which replaces
hash by the UK currency symbol.

> > 
> > The point here is that most of the complexity arises from bi-directional
> > text, not from the associated HTML elements and attributes.
> 
> Aha! So is there any schedule to do this? We need this, and I think I can find
> some volunteers here in Iran to add anything that will be needed for Persian 
> support.

Not that I know of; one can analyse the problem without having to think
that deeply about how to code it.

> 
> > (Linux can be put into Unicode mode, but can only display
> > the subset corresponding to the loaded code page; I don't think that
> > it does BIDI.)
> 
> I can't understand. You are talking about a TERMINAL supporting bidi?

Any true Unicode terminal must support bidi - however, I doubt that there
are many, if any, dedicated Unicode terminals.  In general you can't do
Unicode on character cell terminals; the character codes for Indian
languages, and probably Thai, don't encode glyphs, they encode phonetic
characters, but the actual scripts involvle complex ligatures, and there
are often multiple valid solutions (although some are preferable to others).
Even Naskhi must look ugly when forced into fixed size cells, even if the
terminal is clever enough to overlap the cells.

Given that you can't do character cell displays in general Unicode, you
can't rely on libraries like curses which assume that you can predict the
placement of characters on the screen; a general Unicode solution is 
probably forced to be a GUI solution.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]