Re: [efrench] [57] Suppression du dossier initex.

[Manuel Pégourié-Gonnard <mpg@xxxxxxxxxx>]

Bonjour,

Le 27/01/2011 11:27, Raymond a écrit :
> C'est un gros travail qui a été fait. J'admire. Je vais encore voir de plus
> près ce qu'il en est maintenant. Je ne me serais jamais lancé dans de tels
> changements.
> 
Merci. Comme je l'ai dit plusieurs fois, je pense que de tels changements
étaient importants pour rendre le projet plus maintenable.

> J'ai aussi quelque peu travaillé pendant ce temps et voici quelques
> points qui me touchent de plus près.
>      1. J'ai utilisé LaTeX et french.sty sous windows de 1993 à
>      aujourd'hui. Et voulant voir ce que ça donnerait sous Unix
>      (Ubuntu), j'ai découvert le site de Laurent début 2010 et j'ai
>      appris par la même occasion la mort de Bernard Gaulle et la
>      reprise de frenchpro sous efrench. Je reste plutôt spécialiste de
>      Windows que de Linux.

Tant mieux, de mon côté c'est plutôt le contraire, même si je dispose
d'une machine (virtuelle) Windows pour mes tests.

>      1a. Encore maintenant MikTeX est le système LaTeX le plus répandu
> sous Windows.
>      1b. Quand j'ai transféré sur le dépôt les éléments de la dernière
> distribution FrenchPro pour Windows, j'ai constaté que plusieurs
> fichiers étaient presque identiques en ce sens que ce qui faisait la
> différence, c'était la définition de la fin de ligne (CR-LF sous
> Windows). C'est pour ne pas devoir gérer deux sources que j'ai
> construit sous répertoire src2pack les éléments du répertoire windows.
> Bien sûr, chacun peut reconstruire quelque chose du même genre. Cette
> partie n'est pas au niveau des sources. En plus la structure des
> répertoires était un peu différente entre le paquet pour Linux et
> celui pour Windows et Laurent a simplement placé sur le dépôt la
> structure du paquet de Linux, j'ai rajouté ce qui manquait pour
> Windows et MikTeX.
> 
Concernant les fins de lignes, en principe tous les *TeX, qu'ils
provienne de TeX Live ou MikTeX, acceptent les deux styles de fin de
ligne. Je ne pense pas qu'il soit utile de distribuer des fichiers CR-LF
sous Windows, si ces fichiers sont destinés à être lus par TeX. En tout
état de cause, si on finit par avoir besoin de tels fichiers, il
conviendra de les générer à partir de la version Unix (ou vice-versa, je
ne suis pas sectaire) plutôt que de maintenir des fichiers dupliqués
dans le dépôt.

Par ailleurs, MikTeX comme TeX Live respectent la TDS, je ne vois donc
pas de raison a priori d'avoir des structures de repertoires
différentes.

Il faut voir que l'univers de TeX est bien plus uniforme aujourd'hui
qu'il a pu l'être il y a 7 ans et plus, il faut en profiter. Je
distribue quelques paquets et n'ai jamais eu à préparer deux
distributions distinctes pour Unix et Windows, j'espère qu'il en sera de
même pour eFrench.

>       2. Je me demande si inputenc.sty peut ce que peut keyboard.sty,
> c'est à dire aussi transcoder les messages sortants d'une
> version 7 bits à 8 bits ou utf8 (comme c'est le cas avec
> \usepackage[8b,utf8]{keyboard}, par exemple.

Si vous parlez bien des messages affichés par TeX dans le log, avec
inputenc + fontenc ils sont convertis dans l'encodage de fonte courant,
c'est-à-dire T1 la plupart du temps en français (EU1 resp. EU2,
c'est-à-dire Unicode, dans le cas de XeLaTeX, resp. LuaLaTeX). Pour
mémoire, T1 est essentiellement latin1.

Donc certes sur ce point la fonctionnalité n'est pas la même, mais je ne suis
pas sûr que la différence soit sensible.

Par contre, nous pouvons continuer à chercher des différences, avec des exemples
précis, et les documenter, et éventuellement réintroduire keyboard.sty
si ces différences s'avèrent assez fondamentales. Ceci dit, il faut quand même
voir que la majorité des autres paquets suppose qu'inputenc est utilisé.

> Il faudra en tous
> cas, en attendant, laisser keyboard.sty et les différents *.kbc
> à disposition, car tous les utilisateurs ne passeront pas
> facilement et immédiatement à utf8 et à et à inputenc.sty

Je dois admettre que je n'utilisais pas French moi-meme avant. Je suis
curieux d'avoir plus de détails sur les éventuels problèmes que vous
pourriez recontrer en tentant de convertir vos fichiers à inputenc.

> et le
> 7 bits ne pourra disparaître que si nous offrons un transcodage
> de 7 bits à utf8 facile à utiliser pour leurs anciens fichiers.

Je ne sais pas si le 7 bits a vocation à disparaître. Si quelqu'un aime
saisir \'e plutôt que « é », il peut continuer si ça lui chante. Sinon,
le problème n'est en rien spécifique au français, et c'est à mon avis
vers des outils généralistes qu'il faut se tourner.

> Là, j'ai quelque chose en vue. Par contre pour transformer
> ansinew en utf8, j'utiilise Notepad++ qui est gratuit et tourne
> sous Windows et Wine (émulateur Win sous Linux) sans problème..
> Je ne vois actuellement rien de si simple pour latin9 qui
> diffère en six symboles de ansinew.

Sous Unix, n'importe quel éditeur de texte à peu près décent sait
transcoder de n'importe quelle encodage existant. L'outil recode, en
ligne de commande sait même convertir de et vers les séquences LaTeX
habituelles (enfin, j'ai découvert hier qu'il ne comprent pas \^i). Il
est possible qu'il existe sous windows. Sinon GNU iconv existe très
probablement sous Windows aussi.

>       2a. J'ai effectué quelques tests en ansinew (la norme sous
> Windows), latin9 (ce que proposait B. G.) et utf8. Il est vrai que
> ansinew.kbc n'était pas complet et qu'il est différent de latin9.kbc,
> ce qui pose déjà un problème pour une large compatibilité
> Linux-Windows. Il est évident qu'utf8 résoud ce problème et est
> accepté de mieux en mieux  sous Windows. Avec toujours encore la
> différence concernant les fins de ligne ! !
> 
Encore une fois, je ne vois pas ce qu'il ya de spécifique au français,
et surtout je ne pense pas que le but d'eFrench soit de faire passer
tout le monde à utf-8. Le paquet inputenc prend en charge les encodages
8 bits classiques (y compris les différences entre latin1, latin9 et
ansinew).

>       3. Tout ceci pour veiller à une construction de paquets pour
> windows (MikTeX ou TeXLive) et pour Linux et Mac-OsX qui ne
> dégrade pas l'environnement de travail de l'utilisateur de TeX,
> LaTeX et efrench.sty.
> 
Sur ce point je vous rejoins largement. Il est clair qu'il convient
d'éviter les régressions et que l'impact des changements effectués sera à
tester soigneusement avant distribution. Votre expérience d'utilisateur
de longue date nous sera très bénéfique.

>        4. En installant le paquet german (je travaille aussi souvent
> en allemand) par TeXLive, j'ai remarqué qu'il y avait deux
> paquets, un de programmes et un autre de documentation. Ça a
> l'air d'être le cas pour d'autres langues. Bernard Gaulle a
> établi des programmes (frenchle.sty et french.sty) et de la
> doc, mais aussi des outils, en particulier ceux de transcodage.
> Je verrais assez pour efrench trois paquets en conclusion, que
> ce soit pour TeXlive ou pour MikTeX. MikTex respecte la
> structure TDS, mais elle est placée sous MikTex. C'est encore
> en objet intéressant d'étude et de mise en place.
> 
Ce découpage en sous-paquet est usuellement effectué au niveau de la
distribution (MiKTeX ou TeX Live) quand elle ré-emballe le paquet à sa
sauce. Ce n'est a priori pas à nous de nous en soucier.

>     Je m'arrête pour l'instant. Merci pour tout ce qui va vers une
> simplification et je crois que de grand pas en avant ont été
> faits. Il y aura quelques pas à faire, non par en arrière, mais à
> gauche et à droite, directions Linux, Windows, TeXLive, MikTeX,
> etc.
> 
Oh, n'hésitez surtout pas à le dire franchement si vous pensez que je
suis allé trop loin, le contrôle de version est justement fait pour ça,
et si j'ai essayé d'avoir des commits à peu près propres et atomiques,
c'est aussi pour revenir facilement en arrière si besoin est.

Pour résumer :
- je ne crois pas à la nécessité de produire des paquets différents pour
  Unix et Windows, jusqu'à preuve du contraire ;
- je continue à penser qu'il en faut pas garder les exéctubles kbXtoY,
  pour deux raisons : le problème du transcodage est un problème général
qui appelle des solutions générales (lesquelles existent en large
partie, nous pouvons les documenter) ; où irions-nous si chaque langue
proposait son outil de transcodage ? Par ailleurs, c'est la raison
principale qui rend l'integration à MikTeX et TeX Live délicate..
- je ne suis pas opposé à la réintroduction de keyboard.sty s'il est
  relativement intdépendant due kbXtoY et si vous pensez qu'il y a un
réel bénéfique (à documenter clairement) par rapport à inputenc.

Toutes remarques bienvenues !

Manuel.

---
Projet eFrench - Pour une typographie informatique de langue fran�se libre.