[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] New request `trin' and asciify
From: |
Sigfrid Lundberg, NetLab |
Subject: |
Re: [Groff] New request `trin' and asciify |
Date: |
Mon, 18 Mar 2002 08:49:39 +0100 (CET) |
On Sun, 17 Mar 2002, Werner LEMBERG wrote:
>
> As already mentioned on this list, I have removed almost all `charXXX'
> entities from the font definition files (and I will continue).
>
> Right now I discovered another dependency between input and output
> encoding. For example, in latin1.tmac you can find (after macro
> expansion)
>
> .tr \[char229]\[oa]
>
> which maps input code 0xE5 to `a with ring above', disabling the
> asciify mechanism. With the charXXX entries in the font files, this
> translation wasn't necessary, and .asciify could map char229 back to
> `a with ring above'.
A (perhaps) related observation: I picked up Ted Harding's smallcaps macro
(to replace my own work-horse
.de smallcaps
.sy smallcaps.pl '\\$' > /tmp/smallcaps
.so /tmp/smallcaps
.sy rm /tmp/smallcaps
..
which seems obsolete)
It turned out that this works (cutting and pasting from macro def):
.char \\[oa] \\s[\\n[.sc.ps]]Å\\s[\\n[.cap.PS]]
whereas this don't:
.char å \\s[\\n[.sc.ps]]Å\\s[\\n[.cap.PS]]
Bug or feature (truth or dare)?
Sigge