Modifier L^{A}TEX^{∗}

\begin{matrix}c \\ ◯ \end{matrix} Copyright 1995, L^{A}TEX3 Project Team^{†} Tous droits réservés.

12 décembre 1995

Table des matières

Introduction 1 Le système 2 Quelques exemples 3 Quelques garanties 5 Possibilités de configuration 5 Conditions de modification 6 Que pensez-vous ? 7

Résumé Ce document a été réalisé en réponse à l’affirmation que les conditions de modification et de distribution pour les fichiers constituant le Nouveau système standard L^{A}TEX devraient être similaires à celles indiquées par la Version 2 de la « GNU General Public Licence », telle qu’elle a été publiée par la Free Software Foundation.

Introduction

Cet article décrit les principes à la base de notre politique de distribution et de modification des fichiers constituant le système L^{A}TEX. Il a été écrit à l’issue de discussions détaillées sur les problèmes que posent la gestion et la maintenance d’un système de traitement de documents largement distribué et utilisé par diverses personnes pour de nombreuses applications. Ces discussions ont impliqué les utilisateurs, les mainteneurs d’installation gérant L^{A}TEX et différentes organisations qui le distribuent. Ces discussions se poursuivent et nous espérons que les idées exposées dans cet article apporteront une contribution utile au débat.

∗Titre original : « Modifying L^{A}TEX 2ε »

†traduit par S. Le Callonnec (<sebastien.le-callonnec@eleve.emn.fr>) le 21 mars 2000

Notre volonté est que L^{A}TEX soit un système sur lequel les utilisateurs de tout type puissent compter pour satisfaire leurs besoins. Un tel système doit être stable et maintenu de manière suivie. Ceci implique qu’il doit être raisonnablement facile à maintenir, sinon il ne sera tout simplement pas maintenu du tout. Voici un résumé de notre philosophie fondamentale :

Nous pensons que la liberté de compter sur un standard largement diffusé pour l’échange de document et le formatage est aussi importante que la liberté de faire des expériences avec le contenu des fichiers. Nous adoptons ainsi une politique similaire à celle que Donald Knuth applique aux modifications du système TEX sous-jacent : certains fichiers et leur nom font partie du système et ainsi, le contenu des ces fichiers ne devrait pas être changé à moins que les conditions suivantes soient satisfaites :

– ils sont clairement identifiés comme n’appartenant plus au système standard ;

– le nom du fichier est changé.

Le système

En développant cette philosophie et les limites qui en découlent sur la façon dont les changements peuvent être faits sur le système, nous avons été profondément influencés par les faits suivants concernant les utilisations très répandues et très diversifiées du système L^{A}TEX.

1. L^{A}TEX n’est pas simplement un système de traitement de document ; il définit également un langage pour l’échange de documents.

2. Les fichiers de classe de document standard et quelques autres définissent un formatage particulier pour un document.

3. Les packages que nous maintenons définissent une interface de document particulière et, dans certains cas, un formatage particulier de certaines parties d’un document.

4. Les interfaces entre différentes parties du système L^{A}TEX sont très complexes et il est par conséquent très difficile de vérifier qu’un changement apporté à un fichier n’affecte pas la fonctionnalité non seulement du fichier, mais également d’autres parties du système connectées de manière peu évidente au fichier qui a été changé.

Ceci nous conduit au principe général :

sauf rares exceptions, si vous changez le contenu d’un fichier, alors la version modifiée doit porter un nom de fichier différent.

Nous ne souhaitons certainement pas empêcher les gens de faire des expériences avec le code de différentes façons et de l’adapter à leurs propres besoins. Cependant, nous nous inquiétons du fait que toute distribution de modifications du code soit clairement identifiée comme ne faisant pas partie de la distribution standard. Le libellé et la forme des conditions de distribution sont ainsi flexibles, mais seulement sous la contrainte de préserver L^{A}TEX comme un produit standardisé et auquel on peut se fier pour les raisons décrites ci-dessus : l’échange et le formatage de documents.

Quelques exemples

Nous allons développer ici les arguments qui nous ont conduits à la conclusion ci-dessus.

Le développement séparé est considéré comme nuisible !

Dans beaucoup de domaines, l’utilisation de L^{A}TEX comme langage de communication est aussi importante que son excellente capacité de composition ; c’est une considération importante pour une large population d’auteurs, d’éditeurs de journaux, archivistes, etc.

Associé à ce problème de portabilité se trouve le fait que les noms de fichier font partie de la syntaxe utilisateur final.

Comme exemple concret, prenons le package « array.sty » de la série « tools ». Une fonction haut niveau a été ajoutée à ce fichier fin 1994 et un document utilisant cette fonction peut contenir la ligne :

   \usepackage{array}[1994/10/16]

En fournissant l’argument optionnel, l’auteur du document indique qu’une version du fichier array.sty postérieure à cette date est requise pour exécuter ce document sans erreur.

Cette fonction serait complètement sans intérêt si nous autorisions la distribution d’une autre version du package array sous le même nom, car cela signifierait qu’il pourrait y avoir des fichiers en circulation d’une date postérieure mais sans la nouvelle fonctionnalité. Si le document était traité en utilisant cet « autre array », alors il produirait très certainement des erreurs « commande indéfinie » et ne serait sans doute pas compilable du tout.

Qu’y a-t-il dans un nom de fichier ?

Dans un langage à balises pur, tel que SGML, il est assez clair que le contrôle de la présentation finale réside chez le receveur du document et non chez l’auteur.

Cependant, à la façon dont L^{A}TEX est le plus souvent utilisé en pratique, il est évident que la plupart des utilisateurs (du moins lorsqu’ils utilisent les classes et packages standard) comptent sur le fait que le formatage sera préservé lorsqu’ils envoient le document à un autre site.

Par exemple, supposons que vous produisiez un document pour « camera-ready-copy », utilisation encore la plus commune de L^{A}TEX dans l’édition, employant la classe « article », et que vous mettez au point le formatage en ajoutant, par exemple, des sauts de lignes explicites, etc. pour assurer qu’il rentre dans la limite de 8 pages imposé par un journal ou un compte-rendu de conférence.

Il est alors envoyé à l’éditeur ou à un répondant qui, sans que personne ne le sache, a une version non standard du fichier de classe « article » faisant passer le document à 9 pages. La conséquence de ceci sera, au minimum, une énorme perte de temps pour que tous les gens impliqués comprennent ce qui a cloché ; cela mènera également très certainement chacun à attribuer à l’autre la responsabilité de la chose pour une incompatibilité qui n’était en fait dûe qu’à une mauvaise politique de distribution.

Il vous faut également remarquer que, pour la plupart des utilisateurs, la version du fichier de classe « article » employée est choisie par le mainteneur d’un site ou les compileurs de distribution CD-ROM. Pour la plupart des utilisateurs, les symboles article dans :

   \documentclass{article}

font tout autant partie de la syntaxe L^{A}TEX que les symboles 12pt dans :

   \hspace{12pt}

Ils devraient donc ainsi tout deux définir un formatage standard plutôt que produire tantôt une page supplémentaire, tantôt un espace de 5 pt plus grand.

Les utilisateurs comptent sur le fait que la commande (ou l’entrée du menu) « LaTeX » produise un L^{A}TEX completèment standard, incluant le fait qu’« article» est l’« article standard ». Ils ne seraient pas ravis du tout si la personne qui a installé et maintient L^{A}TEX pour eux était autorisée à personnaliser « article » tous les deux jours afin d’améliorer (selon lui ou elle) la mise en page, ou parce qu’un autre utilisateur souhaitait écrire dans une autre langue ou composer un document avec des fontes différentes.

TEX lui-même

Nous avons modelé nos politiques sur celles du système TEX car celui-ci a été largement reconnu comme un système de composition stable et de haute qualité.

La politique de distribution initiée par Donald Knuth pour TEX a les aspects suivants :

– il existe une méthode clairement spécifiée pour le changement de parties du programme en utilisant des « fichiers de changement » ;

– bien que des changements arbitraires soient permis, le programme résultant peut être appelé TEX seulement si ses fonctionnalités sont précisément les mêmes que TEX (i. e. ni plus ni moins) dans tous les domaines importants ;

– il y a beaucoup de fichiers dans le système qui ne peuvent pas être changés du tout (sans changer le nom) : les exemples en sont le fichier plain.tex et les fichiers associés aux fontes, y compris les fichiers source de Metafont.

Complexité de maintenance

Notre expérience dans la maintenance de L^{A}TEX nous a montré à quel point les interactions entre différentes parties du système sont complexes.

Nous avons ainsi, à l’aide des rapports d’erreur que vous nous avez soumis, développé un large éventail de fichiers test que nous lançons pour vérifier les effets que chaque changement provoque. Un pourcentage non négligeable de ces séries de tests donne des résultats inattendus et démontrent des dépendances insoupçonnées dans le système.

Quelques garanties

Nous n’essayons certainement pas d’émpêcher les utilisateurs de reformater les documents L^{A}TEX de la manière qu’ils le souhaitent. Il y a de nombreuses façons de personnaliser des documents qui vous arrivent selon votre style personnel sans changer le contenu des fichiers L^{A}TEX standard ; en effet, la liberté est un des nombreux avantages du système. La manière la plus simple pour faire ceci est de remplacer

     \documentclass{article} par \documentclass{myart}

Nous ne souhaitons pas non plus décourager la production de nouveaux packages améliorant la fonctionnalité ou l’implémentation de ceux que nous distribuons. Tout ce que nous demandons est que, dans l’intérêt de tous les utilisateurs de L^{A}TEX, vous donniez à votre package ou votre classe magnifiquement amélioré un autre nom.

Possibilités de configuration

Le format du système L^{A}TEX standard peut être configuré de plusieurs façons afin de s’adapter aux besoins et aux ressources d’une installation. Par exemple, le chargement des fontes et de leurs tables peut être personnalisé afin de faire coïncider les formes, les familles et les encodages normalement utilisés en mode texte. En écrivant également des fichiers de définition de fontes appropriés, les tables de fontes peuvent être elles-même initialisées pour tirer profit des fontes et tailles disponibles. Le chargement de motifs de césure peut être adapté pour prendre en compte les langues utilisées ; ceci doit être fait lors de la création du format car c’est en effet le seul moment où les motifs peuvent être chargés.

Une liste complète de ces possibilités de configuration peut être trouvée dans le guide Options de configuration pour L^{A}TEX 2ε (cfgguide.tex). Cependant, comme il y est dit et répété, le nombre de possibilités de configuration est strictement limité ; nous espérons qu’après avoir lu le présent document, vous comprendrez les raisons de cette décision. Une conséquence de ceci est qu’il n’existe aucune disposition pour la création d’un fichier de configuration général, ou pour l’ajout de code juste avant le \dump du fichier de format.

Ceci était une décision délibérée et nous espérons que tout le monde (oui, vous y compris !) soutiendra cette intention. Il y aura sinon un rapide retour à la situation même rencontrée avec plusieurs versions incompatibles de L^{A}TEX 2.09, qui nous a poussés à l’origine à produire L^{A}TEX 2ε : le nouveau, et le seul, « L^{A}TEX standard ». Ceci rendra L^{A}TEX non maintenable et, de fait, non maintenu (pas par nous, en tous les cas).

Par conséquent, vous ne devriez pas employer les fichiers de configuration ou d’autres parties de la distribution de manière abusive pour produire des versions non standard de L^{A}TEX.

Certaines des configurations autorisées peuvent résulter en un système qui peut produire des documents qui ne sont plus « formatage compatibles » ; par exemple, l’utilisation de fontes par défaut différentes produira très probablement des sauts de lignes et de pages différents. Si vous installez sur un système multiutilisateurs configuré de telle manière qu’il ne soit pas « formatage compatible », il vous faut alors considérer les attentes des utilisateurs qui ont besoin de créer des documents portables. Une bonne façon de répondre à leurs besoins est de fournir de plus une forme standard de L^{A}TEX, sans personnalisations « formatage incompatibles ».

Conditions de modification

Il est possible que vous ayez besoin de produire un système de traitement de document basé sur le L^{A}TEX standard mais avec des fonctionalités qui ne peuvent être implémentées en utilisant les fichiers de configuration approuvés et se conformant aux restrictions s’appliquant au code qui y est autorisé. En d’autres mots, vous pouvez avoir besoin d’un système suffisamment distinct du L^{A}TEX Standard qu’il n’est pas possible de le créer en utilisant les options de configuration que nous fournissons ou en produisant de nouvelles classes et packages.

Si vous produisez un tel système, alors, pour les raisons décrites ci-avant, vous devriez vous assurer que votre système soit clairement distingué du L^{A}TEX Standard de toutes les manières possibles, y compris les suivantes :

1. Donnez à votre système un nom distinct, tel que NS-TeX, qui le différencie clairement de L^{A}TEX.

2. Assurez-vous qu’il ne contienne aucun fichier avec le même nom qu’un fichier de la distribution standard mais avec un contenu différent. (Si ce n’est pas possible, il vous faut alors :

– vous assurer qu’on ne puisse pas accéder accidentellement aux fichiers provenant du sysème non L^{A}TEX lors de l’utilisation du L^{A}TEX standard ;

– vous assurer que chaque fichier du système non-L^{A}TEX s’identifie claire-

ment comme tel sur le terminal et dans le fichier de log.)

3. Assurez-vous que la méthode utilisée pour lancer votre système est clairement distincte de celle utilisée pour lancer le L^{A}TEX Standard, par exemple en utilisant un nom de commande ou une entrée de menu qui n’est clairement pas latex (ou LaTeX etc).

4. Assurez-vous que, quand un fichier est traité par votre système, l’utilisation d’un L^{A}TEX non-standard est clairement déclarée par n’importe quel moyen approprié.

5. Assurez-vous que ce qui est écrit au début du fichier de log montre clairement que votre système a été utilisé et non L^{A}TEX Standard. Consultez le fichier cfgguide.tex pour savoir comment faire cela.

6. Expliquez clairement aux utilisateurs que les rapports de bogues concernant votre système ne doivent pas être envoyés aux mainteneurs du L^{A}TEX Standard.

Note aux administrateurs système

Si vous installez une version non-standard (modifiée) de L^{A}TEX sur un site multiutilisateur, veillez alors s’il vous plaît à installer le L^{A}TEX Standard et observer les conditions énumérées ci-dessus, et tout particulièrement 3.

Que pensez-vous ?

Votre opinion sur les problèmes soulevés dans ce document nous intéresse ; la meilleure façon de nous faire savoir ce que vous pensez et discuter vos idées avec d’autres est de rejoindre la liste LaTeX-L et y envoyer vos commentaires. Pour s’inscrire sur cette liste, envoyez à :

   listserv@urz.uni-heidelberg.de

la ligne suivante :

subscribe LATEX-L ⟨votre prénom⟩ ⟨votre nom⟩