Re: @documentencoding and TeX

[Akim Demaille]

>>> "Stepan" == Stepan Kasal <address@hidden> writes:

Hi!

Cc'ed to François, since recode is concerned.

 > 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

Indeed.  But at least in my language in it is not really a problem.
Recode should be fixed though.

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

To be fixed I guess.

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

I didn't know about this.  If that's true, that's too bad: recode
saved my life a million times.

 > 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.

As I said, that's a workaround until proper support is implemented in
Texinfo.  In the meanwhile, this hack is quite effective, and
significantly improves the life of several people here.

 > 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.)

I beg to differ.  We have been waiting for latin 1 for *years*.  I
have put my trust in Texinfo many years ago telling people that we
should use it for our manuals, do prove me wrong.

I can understand that the right implementation is hard to make, but
heck, is that a reason to reject something that works?  I'm less
interested in the quality of the design than in the result per se.

 > 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.

That does sound like an FP project indeed :)

 > 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.

What confusion?