Re: @documentencoding and TeX

[François Pinard]

[Akim Demaille]

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

Thanks! :-)

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

In fact, while historically Recode implemented a "step" between a subset
of Latin-1 and Texinfo, the avenue to take is a "step" between something
wider than Latin-1, likely UCS (that is, Unicode or ISO 10646) and
Texinfo.  I think this is what the prototype currently does, here.

I've also been saving various proposals for a while on this topic, but
Recode may not decide how Texinfo is getting more international, yet it
should follow.

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

The last release of Recode, done by someone else with my permission but
without my close supervision, left me in an awkward situation, as I
cannot dismiss all the valuable work that was put in and now-promised to
users, but cannot either pursue some internal directions that were set
up in that release, and merely given to me to later complete.  Also, the
latest release was not as as "solid" as the previous one, generated many
valid user reports, and I'm not comfortable with that either.

My only way out of that dilemma is to produce a major refreshing of
the Recode project, and despite I did a good amount of work in that
direction, yet I'm not working steadily at it as I used to.  From my
viewpoint, the project is not dead.  I quite understand that users do
not see much of it yet, and I do know there will be a while before
Recode 4.0 is ready, because there is still much to be done.

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

Let me be anecdotical for this paragraph.  For all my French works with
Texinfo, my associate Laurent patched a version of `texinfo.tex' which
I have been happily using for years.  This is quite astonishing to me
since Laurent is not a programmer, but the need was so excruciating at
the time that he did whatever was necessary.  His patch does not require
a prior recoding step (yet it sometimes does for a a few documents
having a few non-French characters we need).  Despite useful locally,
the patch does not have the generality required to be really meaningful
for the whole of the Texinfo user community, and our intent ("us" means
Laurent and I) is to adapt to whatever solution Texinfo offers.

>  > 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 Recode sources are rather complicated, the C language requires a lot
of care on memory allocation issues, and for Recode at least, is uneasy
for prototyping ideas.  That's one of the reason why the prototype
(Recodec) is not writte in C.

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

Before `iconv' was written in GNU libc, Ulrich suggested that I adapt
Recode so it could be used as a library, and provided specifications.  I
did produce a Recode library then, precisely because of this request,
but felt uncomfortable with some of the specifications, and did not
follow them.  One reason for the reluctance was that `iconv' wanted
some purity in its definitions that was surely nice, but did not
correspond that the experience I had, at the time, with users need,
as expressed by those who wrote to me all along: I did not feel like
merely eradicating from Recode everything that does not fit the `iconv'
model.  Another reason is that some of the implementation complexity of
`iconv' came from the API design, which had contraints which appeared a
bit gratuitous to me.  Another point, maybe related to the first, was
the extreme Unicode centrality of `iconv'.  While there are many good
things in Unicode, and that I am a constant Unicode user myself, I just
do not want to participate in any fanatical promotion of Unicode, nor to
transform Recode into an instrument of such fanatism.

>  > The fact that GNU recode was renamed to Free recode brings even
>  > more confusion.

> What confusion?

The FSF is about Free Programming much more than about Free Programmers,
at least when you do volunteer work _for_ the FSF.  One may not just
go and prefix one of a package with `GNU', you ought to demonstrate a
high level of obedience to the FSF political means of the day and many
internal little details and rules.  In my case, that went rather well
for decades, but my patience eroded along the decades, having to cope
with authoritarian or abusive people.  When this obedience became really
unbearable, I replaced `GNU' by `Free' in some of my projects, as a way
to recover my own freedom.

I surely praise the GNU project and FSF commendable goals.  And even now
that I broke away of the FSF authority, I stayed collaborative as usual,
and some packages of mine are still in-line with the FSF goals, enough
for the FSF to still distribute them, even if they did not overly like
(as you might guess) the replacement of "GNU" by "Free".  I do not push
for them to distribute my things, they are free as much as I am :-).

There is a wonderful French proverb that says: "Il est plus facile de
mourir pour la femme qu'on aime, que de vivre avec elle." :-) I do not
know how well it translates in English, but roughly: "It is easier to
die for the woman we love, that to live with her.".

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard