axiom-mail
[Top][All Lists]
Advanced

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

RE: [Axiom-mail] Terminal Fonts and Axiom


From: Page, Bill
Subject: RE: [Axiom-mail] Terminal Fonts and Axiom
Date: Tue, 21 Nov 2006 23:33:17 -0500

On Tuesday, November 21, 2006 9:04 PM C Y
> > 
> > --- Themos Tsikas <address@hidden> wrote:
> > 
> > > Those characters used to work for a specific IBM font on the
> > > RS/6000. I  believe that the encoding is cp850 or ibm850. When
> > > you use a font with an iso8859 encoding, you get the mess you
> > > describe.
> 
> A little more info on this - after tracking the set character output
> back through the code, it looks like i-output.boot.pamphlet is where
> the font definitions take place.  
>

http://wiki.axiom-developer.org/axiom--test--1/src/interp/IOutputBoot
 
> Some of the definitions appear using this form:
> 
> SETANDFILEQ($plainSpecialCharacters0,[
>     EBCDIC( 78),      -- upper left corner   (+)
>     EBCDIC( 78),      -- upper right corner  (+)
> etc.
> 
> EBCDIC would appear to refer to Extended Binary Coded Decimal
> Interchange Code, apparently an alternative to ASCII. 
> http://en.wikipedia.org/wiki/EBCDIC
> 

"It descended from punched cards and the corresponding six bit
binary-coded decimal code that most of IBM's computer peripherals
of the late 1950s and early 1960s used. ..."

Cliff, you make me feel very old if you really did not previously
know the meaning of the acronym EBCDIC! :-) But be careful not to
be confused by the name. If you take a look in vmlisp.lisp.pamphlet
you will see that EBCDIC is just a poorly named macro for a common
Lisp function (int-char x).

http://wiki.axiom-developer.org/axiom--test--1/src/interp/VmlispLisp

> Judging by the chart on wikipedia, 78 would be 4E in hexadecimal
> which is indeed the + character.  plainRTspecialCharacters seems
> to hold definitions not relying on the EBCDIC encoding.  As near as
> I can tell there are several styles of character output for EBCDIC
> plain and default, and the RT definitions which appear to be the
> ones which work on modern systems.
>

In Axiom right now the only character definitions that are used are
$RTspecialCharacters and $plainRTspecialCharacters. See

http://wiki.axiom-developer.org/axiom--test--1/src/interp/SetvarsBoot

These are just more poorly chosen names for extended ASCII (CP850)
and plain ASCII character tables.

Actually I was surprised to see that

  )set output characters default

works properly on my Windows version of Axiom, although the actual
default is 'plain'. Apparently the MSDOS box in Windows uses CP850
although a different code might be default in other countries.

The rest of the tables in i-output are just cruft. I cannot imagine
that any system running Axiom today would actually use EBCDIC.
 
> Interesting.  I wonder how much flexibility is built into this
> arrangement.  Perhaps character sets which look better than either
> default or plain could be selected.
> 

You definitely have the right idea.

On Tuesday, November 21, 2006 9:35 PM C Y wrote:
> 
> Well, to answer my own question - some fun can be had with the
> following command:
> 
> )lisp (setq $|plainRTspecialCharacters| '(+ + + + |\|| - ? [ ] { } + +
> + + + |\\|))
> 
> followed by
> 
> )set output character plain
> 
> Unfortunately unicode is apparently out of bounds (pity) but
> perhaps those wanting to tweak the appearance of output could use 
> variations on the above.

In general I wouldn't recommend doing this unless you understand
how it is implemented and why it works. It is quite possible that
this might change in the future.

> For example, this input:
> 
> )lisp (setq $|plainRTspecialCharacters| '(- - + + |\|| - ? [ ] { } + +
> + + + |\\|))
> )set output character plain
> sqrt(x)
> 
> results in a square root symbol like this:
> 
>          ---
>    (1)  \|x
>                                           Type: Expression Integer
> 
> instead of this
> 
>          +-+
>    (1)  \|x
>                                           Type: Expression Integer
> 
> I expect the + symbol was chosen to mark clearly the end of a
> particular line, so perhaps + is a more useful choice.  Anyway
> it appears easy enough to tweak.

Cool!

> 
> Eventually, some fun might be had with unicode support: 
> http://www.utf8-chartable.de/unicode-utf8-table.pl?start=8704
> although I expect the real effort on output formatting should
> go to output systems more sophisticated than the terminal.

You are right, but I expect that there are a lot of people who
will still want to use Axiom in terminal mode. I think the best
approach would be to clean-up 'i-output.boot' and provide some
modern standard character set alternatives there such as utf8,
iso8859-1 etc. And to extend 'setvars.boot' to allow meaningful
commands such as

  )set output characters utf8

However many of these character sets will not have support for
special line drawing characters such as those in CP850. So there
effect might not be much different than 'plain'.

Here is a very good but brief tutorial on character sets:

http://www.cs.tut.fi/~jkorpela/chars.html

It would be nice if the user did not have to specify the character
set in Axiom. There are some standard ways to determine the proper
default character set for a given terminal environment, at least on
Linux systems. See POSIX locale LC_CTYPE.

If you are willing to spend a little more effort on this I think
it might be appreciated by some people who use Axiom on international
platforms. However unless you want to do a little extra programming
I think you may be limited to supporting only single byte character
codes which might rule out utf-8. I suppose that character set support
really should be built into the Lisp that underlies Axiom, but as far
as I know GCL does not yet directly support unicode (some other lisps
do, e.g. clisp, sbcl).

Regards,
Bill Page.




reply via email to

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