On Fri, 1 Jun 2001, Juliusz Chroboczek wrote:
> RB> I notice the CSI 11/12m stuff doesn't work: evil idea DONT try it :-)
>
> Sorry, I don't have my reference handy. Is that some SGR attribute?
It's the ECMA-48 character set specifier and is normally assumed to be
CP437 and a flipped version of such. But it's completely non ISO-2022
and many people think it's truely evil because it makes most of the
C0 characters into printable graphics (Like DOS ANSI.SYS).
For reference:
ESC [ 10 m Turn this off
ESC [ 11 m Use CP437.
ESC [ 12 m Use CP437 but flip bit 8. (xor 0x80)
No other CSI effect this charset including CSI 0 m (Nasty!)
> RB> Are you going to do ISO646 national sets ?
>
> Yes, if we can work out a set of XLFD names for them. Anybody got
> suggestions?
Well the standard names of the ones in the i18n package are:
ISO646-CA ISO646-CA2 ISO646-CN ISO646-CU ISO646-DE ISO646-DK
ISO646-ES ISO646-ES2 ISO646-FR ISO646-GB ISO646-HU ISO646-IT
ISO646-JP ISO646-JP-OCR-B ISO646-KR ISO646-US ISO646-YU ISO_646.BASIC
ISO_646.BASIC:1983 ISO_646.IRV ISO_646.IRV:1983 ISO_646.IRV:1991
> By the way, if you have a map from DEC Technical into Unicode, I'm
> interested. There's a semi-standard XLFD for that (-dec-dectech).
A semi-map for DEC-Tech is at:
http://vt100.net/charsets/technical.html
The problem is not all the characters are in unicode (heresy!)
> Note by the way that you don't need to install XFree86; you only need
> its encoding files. And hacking a makefile by hand for systems that
> don't have Imake is a two-minute job:
>
> CFLAGS = -g -DFONTENC_NOT_IN_X -DSYSTEM_FONT_ENCODINGS_DIRECTORY=...
> # optionally -DBSD or -DSVR4, GNU libc systems don't need anything
>
> luit: luit.o iso2022.o ...
Ahh, this solves my issue. Problem solved.
--
Rob. (Robert de Bath <rdebath @ poboxes.com>)
<http://www.cix.co.uk/~mayday>
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
