bug-texinfo
[Top][All Lists]
Advanced

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

Re: @documentencoding and TeX


From: Stepan Kasal
Subject: Re: @documentencoding and TeX
Date: Wed, 25 Aug 2004 12:32:42 +0200
User-agent: Mutt/1.4.1i

Hello,

On Wed, Aug 25, 2004 at 10:24:12AM +0200, Akim Demaille wrote:
> It is my understanding that all the outputs properly understand
> @documentencoding except TeX.  Since TeX is behind texi2dvi, and since
> recode is fairly common, at least on the machine where LC_ALL != C, I
> suggest the following patch.  It does considerably simplify my file,
> until proper TeX support is implemented.

I see several problems with recode:

1) latin1..texinfo handles \"a (the 8bit char) correctly, but it doesn't
handle other characters, eg. \'a

2) latin2..texinfo is not implemented properly; it seems that it does
latin1..texinfo anyway (similar for latin2..TeX)

3) it's not an active project, and it's not maintained.

Aditionally, your approach of changing the 8bit chars to their 7bit
representations (like @"a) doesn't produce nice manuals, at least
currently.  TeX then uses 7bit fonts, and the words containing diacritics
cannot be hyphenated.

So, at the current stage, I'd simply admit that the TeX texinfo backend
doesn't support non-ASCII encodings.
I don't think it's worth it to put your patch it.
(But, of course, it's up to Karl to decide.)

A related issue:

I'd like to have l2..TeX or l2..ASCII conversion (I use a perl script
called cstocs for LANG=cs currently), but it seems to be hard to achieve.

The recode sources seem a bit complicated to me, and the author doesn't
want to work on it, a new generation program is promised, to be prototyped
in python, ... but no progress for a few years, IIRC.

The iconv program from glibc doesn't handle some mappings well.  It
doesn't have support for TeX encoding, and it is not able to "strip
diacritics."

I had recently experienced problems with ``recode -f utf8..xx'': it
deleted also a few characters after the intranslatable one.
iconv -c works reliably in this situation.

So I cannot decide which project should be the standard recoding program,
which I could contribute to.
The fact that GNU recode was renamed to Free recode brings even more
confusion.

Have a nice day,
        Stepan Kasal




reply via email to

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