KerTeX ``Prendre TeX à coeur !'' Thierry Laronde Annecy, FRANCE $Id: LISEZ.MOI,v 1.33 2012/01/27 12:39:41 tlaronde Exp $ ------------------------------------------------------------------------ 0. Avertissement, points particuliers, remerciements. Bien que le progiciel ait été, pour la dernière version, testé sur 3 systèmes : Plan9/i386, NetBSD_5.0.2/i386 et OpenBSD_5.0/i386, et compilé sur Mac OSX, Gentoo (Linux) AMD/64 bits PIE et FreeBSD 8.2/i386, le progiciel se stabilise mais reste une beta. Afin de permettre de l'évaluer en sécurité, les programmes et les fichiers sont installés dans deux répertoires dédiés ; l'un pour les données indépendantes du système, l'autre pour les données dépendantes du système (non seulement de la machine, mais de l'OS). Un seul programme est placé dans un répertoire "commun" : which_kertex qui vous permet, et permet à l'infrastructure de gestion des paquets de kerTeX, de connaître les particularités de l'installation. En invoquant which_kertex(1) vous verrez typiquement apparaître quelque chose comme ceci : $ which_kertex readonly KERTEX_VERSION=0.9999.0.2 readonly KERTEX_HOST=netbsd-i386-5.0.2 readonly KERTEX_SHELL=/bin/sh readonly KERTEX_BINDIR=/usr/pkg/bin/kertex readonly KERTEX_LIBDIR=/usr/pkg/share/kertex readonly KERTEX_USER0=root readonly KERTEX_GROUP0=wheel Dans ce qui suit, lorsque j'écris par exemple : $KERTEX_BINDIR, il faut remplacer cette description symbolique par la valeur effective de la variable (les variables ne sont pas, par défaut, dans l'environnement). Il vous faudra donc soit ajouter la définition de KERTEX_BINDIR à votre PATH, soit préfixer les programmes (les utilisateurs de Plan9 n'ont pas ce problème puisque une invocation comme : $ kertex/initex fonctionne sans problème). IMPORTANT : TeX attend en entrée des caractères encodés sur 8 bits. C'est-à-dire que si l'encodage est de l'utf-8, l'utilisation exclusive de la plage ASCII, par définition de l'utf, ne posera pas problème, mais que tout le reste en posera. Dans ce cas, il faut utiliser un filtre pour transcrire l'utf en un encodage correspondant sur 8 bits (ce qui suppose qu'il n'y a pas plus de 256 caractères). Et il faut qui plus est, que les fontes utilisées correspondent à cet encodage. Pour les systèmes gcc PIE : les utilitaires de compilation peuvent être configurés pour générer, par défaut, des exécutables PIE. En particulier la phase de lien --- effectuée sous couvert du compilateur --- peut ne pas fonctionner car nous créons des programmes statiques. Pour pouvoir compiler, créez un fichier de configuration ainsi : cat </tmp/maconf CFLAGS="-ansi -static -O -fno-builtin -Wall -Wstrict-prototypes -Wmissing-prototypes -fPIC" EOT et invoquez : .../rkconfig /tmp/maconf MODIFICATIONS ------------- 0.9999.1.1 : En plus de correction de bourdes sur la taille d'un tampon, ajout du support des paquets dépendant d'un autre paquet. 0.9999.0.4 : Principalement des corrections de bourdes, ou des adaptations aux versions légèrement différentes des utilitaires sur les différents systèmes (sinon, où serait le plaisir ?...). 0.9999.0.2 : Ajout de e-TeX, des programmes CWEB et de la première partie de l'infrastructure de gestion des paquets (chacun des '9' est pour l'une de ces 3 choses) ! 0.9.6.3 : - La gestion des noms des fontes réencodées pour PostScript a été corrigée ; cela touche dvisp(1), MetaPost ainsi que le fichier de configuration dvips.cnf et le fichier de correspondance psfonts.map. - Dvips(1) acceptait plus de formes de commentaires pour les fichiers de correspondance des fontes que MetaPost : MetaPost modifié pour accepter les mêmes commentaires. - Le mot réservé : KERTEXSYS, placé comme dernière alternative d'une spécification de chemins de recherche provoque l'ajout des répertoires de recherche par défaut de kerTeX à la spécification. REMERCIEMENTS ------------- Je tiens à vivement remercier les personnes suivantes (citées dans l'ordre chronologique) qui ont bien voulu ne pas s'arrêter au premier problème, et ont pris le temps de transmettre un rapport d'erreurs (et de réessayer à nouveau) : John Floren : essais du support de LaTeX, et support constant sur Plan9. Alexander Sychev : essais de compilation sur Linux (gentoo) PIE. Mark van Atten : essais de compilation sur FreeBSD 8.2. James K. Lowden : qui a pris le temps et la peine de tenter de faire ressembler un peu plus à de l'anglais ma traduction de ce fichier en README. Todd T. Fries : qui a pris le temps et la peine de passer le système au banc d'essai sur OpenBSD, de ne pas s'arrêter au premier échec ; de signaler les pierres d'achoppement (principalement dans R.I.S.K. pour la configuration par défaut) et de signaler également un débordement de tampon dû à une bourde dans les change files. OpenBSD a désormais ses fichiers de paramètres dans R.I.S.K. Doug McKenna : qui cherchait à obtenir TeX dans sa transcription C pour le faire fonctionner pas à pas ; l'a obtenu avec kerTeX et, ce faisant, a débusqué une erreur sur la taille du vecteur alloué pour le nom du format par défaut, et a pointé un conflit entre un nom utilisé par le programme WEB et un nom présent dans la libc de MacOSX. ------------------------------------------------------------------------ 1. Quoi. KerTeX est le noyau d'un système TeX, qui offre ce sur quoi tout est basé : la suite des programmes de Donald E. Knuth dédiés à la typographie digitale. Cette suite comprend, bien entendu, METAFONT et TeX ; mais également des programmes auxiliaires. Tous les programmes (dans la dernière version disponible) sont intégrés dans la distribution et compilés. À ces programmes s'ajoutent d'autres programmes liés au pilote transformant le dvi en PostScript (dvips(1) de Tomas Rokicki), MetaPost de John Hobby, e-TeX de l'équipe NTS (qui étend TeX, entre autres, pour l'écriture de droite à gauche, les programmes du système CWEB dû à D.E. Knuth et Silvio Levy, ainsi que BibTeX d'Oren Patashnik. À cela s'ajoute des fontes supplémentaires fournies par AMS, ainsi que les moyens de travailler avec les fontes normalisées PostScript grâce aux AFM publiés par Adobe. 1.0 : représentation 2D (x11 et rio) pour METAFONT. ------------------------------------------------------------------------ 2. Principes. Donald E. Knuth a écrit les programmes en utilisant un système de programmation lettrée (WEB), qui permet de décrire, pour le lecteur humain, le programme dans un ordre logique et didactique, tout en permettant d'assembler les morceaux dans l'ordre attendu par le compilateur. Le langage de programmation de WEB est le Pascal. (Il existe une version CWEB fonctionnant avec le C et dérivés --- j'utilise [TL] intensivement cette version-là.) Le problème est alors de parvenir à compiler le Pascal pour pouvoir disposer des programmes sur un poste informatique. Donald E. Knuth a grandement simplifié le problème, non seulement par la programmation lettrée qui permet d'observer le programme dans tous ses détails (par la production de livres avec index), mais aussi en identifiant toutes les parties du code qui nécessitaient d'être ajustées et en se cantonnant à un usage suffisamment basique des constructions du Pascal pour qu'une traduction en d'autres langages soit réalisable. Mais la normalisation du Pascal est une tentative tardive, et les compilateurs Pascal sont rares ou divergent. La solution adoptée par Tomas Rokicki, il y a 27 ans, a été de tenter de convertir le Pascal en C, du fait de l'ubiquité des compilateurs pour ce langage. C'est de facto ce qui est fait ici, en repartant de Web2C version 5.0C, version qui était dans le domaine public. KerTeX sépare donc logiquement les étapes : 1. On construit les outils servant à traduire le WEB en Pascal, puis le Pascal en C, sur la _matrice_ (le noeud effectuant la compilation) => c'est kertex_M. 2. Puis on utilise ces outils et le compilateur C, sur la matrice, pour générer des exécutables pour une certaine combinaison de machine et d'OS (il peut y avoir compilation croisée) : les programmes construits sont ceux de kertex_T. 3. _À l'installation_, puisque s'il y a compilation croisée les programmes ne peuvent s'exécuter sur la matrice --- on ne requiert pas la présence d'émulateurs... --- les étapes suivantes sont accomplies : a) On génère le ``dump'' pour METAFONT permettant d'obtenir un programme ayant le droit de s'appeler mf(1) --- car kerTeX passe le contrôle TRAP. b) On utilise a) pour générer les fontes Computer Modern. c) On utilise les TFM générées lors de b) pour obtenir le ``dump'' de TeX nous conduisant au programme qui a le droit de s'appeler tex(1) --- car kerTeX passe le contrôle TRIP. d) On génère le ``dump'' de MetaPost nous conduisant au programme qui a le droit de s'appeler mpost(1) --- car kerTeX passe le contrôle TWIST (le nom adopté dans kerTeX pour le banc d'essai de MetaPost). e) On génère des fontes supplémentaires, à partir des sources METAFONT fournies par AMS, ou à partir des fontes normalisées PostScript en travaillant à partir des fichiers de métriques publiés par Adobe. Il est donc à noter qu'en plus des programmes sont fournies les fontes de Donald E. Knuth, ce qui permet de disposer d'un système conforme à tout ce qui est décrit dans les 5 volumes de la série : Donald E. Knuth, Computers & Typesetting, volumes A-E, Addison-Wesley. Qui plus est, kerTeX se veut le noyau d'un système TeX. KerTeX peut être considéré comme un "OS" hébergé par un hôte. Installer kerTeX, c'est le porter pour cette hôte (kerTeX a été conçu pour une portabilité maximale, pour pratiquement tous les OS, et toutes les tailles d'OS). En théorie, cela permettra également de confiner la gestion des paquets TeX à kerTeX : une fois que le système est installé sur un OS hôte, kerTeX s'occupe des paquets TeX ; la charge de devoir maintenir une myriade de systèmes de gestion de paquets est supprimée. Un paquet est créé pour kerTeX, et donc disponible sur tous les systèmes hôtes. ------------------------------------------------------------------------ 3. Pour qui. Nous avons nettoyé le processus de génération afin de disposer de sources qui sont conformes à C89. Ce qui signifie que littéralement, les programmes sont disponibles pour tous les systèmes disposant d'un compilateur C normalisé et de la bibliothèque normalisée. Les programmes compilés ne dépendent que de la libc. À l'exécution, seul MetaPost invoque des scripts écrits en Bourne shell basique. Il faut donc soit qu'une instance de sh(1) existe sur le système, soit transcrire les scripts en un langage compris par le shell du système (les fichiers se comptent sur les doigts d'une main et sont absolument basiques). Enfin la gestion du système dépend, toujours d'un Bourne shell, mais aussi de quelques utilitaires essentiels. Mais, ,,au pire'', n'est utilisé qu'un sous-ensemble restreint d'utilitaires POSIX.2, et les parties dépendant du système sont clairement identifiées dans l'organisation hiérarchique des sources. [Il y a beaucoup à dire, et de nombreuses solutions. Je fais court.] À titre d'exemple, certains programmes, nécessitant l'utilisation de plusieurs fichiers, ouvraient ``/dev/null'' quand l'un des arguments n'était pas fourni. Mais ce n'est pas du C89. Dans notre version, on ouvre des fichiers qui ne comportent que des commentaires et qui sont donc vides : ``null.mf'' ou ``null.tex'', qui sont fournis --- dans les sources de Donald E. Knuth d'ailleurs...---. Et voilà ! Mais ce n'est qu'un exemple parmi d'autres. Par contre, pour pouvoir compiler, il faut pouvoir disposer d'utilitaires. Le processus de compilation utilise sh(1), make(1), etc. en tout un sous-ensemble réduit d'utilitaires POSIX. Donc les programmes, c'est du C89. Le processus de compilation (et d'installation aussi ; mais cela peut être adapté trivialement) est POSIX. Et cette infrastructure utilisant POSIX, c'est R.I.S.K. : Reduced Instruction Set toolKit, qui fonctionne/doit fonctionner sur tous les systèmes offrant une compatibilité POSIX. R.I.S.K. doit fonctionner sur tous les Unix ou dérivés (il a été testé sur NetBSD, FreeBSD, Darwin (MacOS X)), ainsi que sur Plan9, sous APE. Rien n'empêche la compilation croisée pour des systèmes non POSIX (je pense à mingw pour les systèmes Microsoft). Quoi qu'il en soit, l'adaptation se fait au niveau de R.I.S.K., kerTeX en lui-même ne doit probablement pas être touché. ------------------------------------------------------------------------ 4. Compiler, installer et mettre à jour. Pour des motifs liés à la licence, mais également pour clarifier les choses (savoir sur quels éléments portent la licence de kerTeX ; ce qui n'était pas très clair précédemment parce que tous les auteurs et toutes les licences étaient cités), les sources sont séparées en plusieurs paquets. Pour faire bref, J'ai [TL] repris du code qui était en Domaine Public et des programmes qui étaient en DP et qui n'était officiellement plus maitenus par leurs auteurs originaux. À cela s'ajoutent l'organisation, les modifications que j'y ai apportées ainsi que le code que j'ai ajouté. La licence porte sur ces éléments qui sont dans kertex_M et kertex_T. Les programmes et les données, dont les licences sont parmi les plus permissives, mais qui sont toujours maintenus par leurs auteurs sont mis à part. Qui plus est, cela autorise des mises à jour minimales puisque les kertex_[TM] évoluent beaucoup plus fréquemment que le reste. Note 1 : les sources ont été réorganisées pour kerTeX et ont été assemblées à partir d'éléments pris un peu partout. Note 2 : pour l'équipe NTS : le change file etex.ch n'est pas le change file exact que j'ai trouvé puisqu'il a fallu l'adapter à la nouvelle version de TeX. J'aimerais que quelqu'un vérifie. Merci ! On doit noter qu'il faut sépare aussi deux choses : le droit moral, qui est inaliénable : que le code soit en Domaine Public ou pas, son/ses auteurs sont et restent auteurs ; les droits patrimoniaux sont plus matériellement ce que l'on peut faire du code. J'ai porté une attention particulière à respecter scrupuleusement ceci, et à porter au crédit des auteurs ce qui leur était dû. Tous les auteurs sont cités. Et si le nettoyage de ce qui était devenu ingérable pouvait encourager certains auteurs à travailler à nouveau leur code (parce qu'ils pourront se consacrer à ce que fait le code, et non à l'environnement de compilation et d'installation), je serai le premier à m'en réjouir ! Tout ce qui doit être fait a été écrit sous forme de scripts : get_mk_install.sh (pour les Unix) get_mk_install.rc (pour Plan9) les deux scripts étant téléchargeables sur la page Web dédiée à kerTeX : http://www.kergis.com/kertex.html Script qu'il vous suffit de lancer, ou de lire, l'un n'excluant pas l'autre... Mise à jour. ------------------------------------ Lors d'une mise à jour, tous les fichiers et les programmes distribués par kerTeX et qui sont de sa seule responsabilité sont purement et simplement réécrits/écrasés. Mais certains fichiers sont prévus pour être particularisés par l'utilisateur. Pour ceux-ci, l'infrastructure R.I.S.K. les déclare "précieux" et offre à l'installation le choix de visualiser les différences, installer la nouvelle version ou la passer. Deux fichiers sont dans ce cas: 1) dvips.cnf : fichier de configuration de dvips(1). Il doit être noté cependant que tant que la version stable 1.0 n'est pas atteinte, kerTeX peut être réorganisé et cette réorganisation peut avoir un impact sur ce qui doit --- pour ce qui concerne kerTeX --- être présent dans le fichier. Visualisez les différences, mais installez la nouvelle version en répercutant vos accommodements pour l'instant. 2) psfonts.map : les fontes PostScript gérées par kerTeX sont inscrites dans ce fichier et le morceau est encadré par des commentaires permettant de le mettre à jour. Vous pouvez ajouter d'autres fontes à celles-là, hors du morceau géré par kerTeX. À cela s'ajoute les formats (base, fmt et mem) générés lorsque l'on précompile de grands ensembles de macros pour METAFONT, TeX ou MetaPost (ex. : LaTeX). Mais latex(1) n'est qu'une copie de virtex(1), nommée latex, afin d'instruire le programme de charger le format précompilé correspondant "latex.fmt". Comme nous _copions_ l'exécutable, et qu'il est compilé statiquement, cela signifie que "votre" latex(1) continuera de fonctionner. Par contre, si nous avons modifié le programme ou la bibliothèque liée (pour la recherche des fichiers), votre version qui est "ancienne" n'en bénéficiera pas. Simplement recopier la nouvelle version de virtex(1) en latex pourra fonctionner dans certains cas, mais pas dans tous ; car si c'est le programme virtex(1) qui a été modifié, et pas la bibliothèque, certains nombres magiques qui lui permettent de vérifier qu'un format a été compilé par une version compatible auront changé, et il ne reconnaîtra pas le format compilé (message: "Fatal format file error; I'm stymied"). La solution la plus sûre est de recompiler et de recopier. ------------------------------------ ------------------------------------------------------------------------ 4. La gestion des paquets. Nouveau ! Les premiers éléments de la gestion des paquets ont été mis en place. Et le système kerTeX utilise lui-même le système de paquets pour générer le coeur des données : les compilations des ensembles de macro. normales (pour mf, tex, mpost, etex) et la génération des versions compilées et dérivées des fontes. Après l'installation, vous pouvez vérifier les chemins par : $ which_kertex readonly KERTEX_VERSION=0.9999.0.2 readonly KERTEX_HOST=netbsd-i386-5.0.2 readonly KERTEX_SHELL=/bin/sh readonly KERTEX_BINDIR=/usr/pkg/bin/kertex readonly KERTEX_LIBDIR=/usr/pkg/share/kertex readonly KERTEX_USER0=root readonly KERTEX_GROUP0=wheel et vous devez invoquer : $ $KERTEX_BINDIR/adm/pkg_core install qui générera les données dérivées. Cela est fait afin de ne pas invoquer METAFONT, TeX etc. sous root (pour les systèmes ayant ce concept), car il s'agit d'un risque de sécurité majeur : les programmes savent faire beaucoup, beaucoup de choses... y compris manipuler des fichiers ce qui n'était pas l'objectif initial. L'infrastructure de gestion des paquets génère tout sous un utilisateur non privilégié (pour l'instant : refuse de continuer si vous id 0), et ne bascule que lorsqu'il s'agit de mettre les fichiers en place. À titre d'exemple est aussi fourni (voir le site) : pkg_latex.sh qu'il suffit d'invoquer ainsi : $ $KERTEX_SHELL pkg_latex.sh install qui récupère la dernière version des sources et de la documentation, compile et installe le tout. [À noter que la taille ajoutée au final (avec la doc.) est proche de la taille du système kerTeX seul...] ------------------------------------------------------------------------ 5. Mettre en oeuvre. La seule règle à connaître est celle concernant la spécification des chemins d'accès. Si vous respectez la hiérarchie mise en place, il ne devrait pratiquement jamais être besoin de manipuler les variables d'environnement, les valeurs par défaut devant permettre de trouver les données. Toutes les spécifications sont, à la compilation, initialisées avec deux valeurs : 1) Le répertoire courant ('.'). 2) Le répertoire kerTeX : par exemple /lib/kertex/ pour les macros (KERTEXINPUTS) sur Plan9, ce qui sera préfixé /usr/pkg sous NetBSD etc. Si les variables d'environnement ne sont pas définies, kerTeX recherche dans les répertoires par défaut. Si les variables d'environnement sont définies, leur définition remplace les valeurs par défaut. Mais la facilité est offerte, en spécifiant le mot réservé "KERTEXSYS" comme dernier composant d'une spécification de chemins de recherche, d'instruire kerTeX d'ajouter à la spécification définie par l'utilisateur les répertoires par défaut. Exemple : KERTEXINPUTS="mes_repertoires:KERTEXSYS" provoquera la recherche dans mes_repertoires, puis, si le fichier n'est pas trouvé, la recherche dans les répertoires par défaut inspectés pour cette variable. Dans tous les cas, la recherche s'effectue pour chacune des alternatives et s'arrête dès que le fichier est trouvé. Par répertoire, le fichier est d'abord recherché directement là ; s'il n'est pas trouvé, un sous-répertoire du nom du programme est testé (par exemple, en invoquant dvips(1), le deuxième essai testera le répertoire + dvips/ ; cela fonctionne avec tous les programmes). Ces variables peuvent être redéfinies par l'utilisateur dans l'environnement : $ KERTEXINPUTS="bla-bla-bla..."; export KERTEXINPUTS KERTEXINPUTS est défini comme une liste de répertoires à explorer, séparés par ':' (deux points). Il en va de même des autres variables décrites ci-dessous. Partagée par de nombreux programmes : KERTEXFONTS : aussi important (pour l'utilisateur) que KERTEXINPUTS, et utilisée par TeX et dvips(1). TeX, par exemple, travaille avec les TFM (les TeX Font Metrics) qui lui décrivent la façon d'assembler géométriquement les glyphes. S'il n'arrive pas à charger une fonte, c'est qu'il ne trouve pas le *.tfm dans ses chemins. Il s'agit du répertoire racine, la recherche (partagée par tous les programmes) recherche éventuellement un sous-répertoire (tfm/, pk/, cm/, gf/, pfa/, pfb/) et si cela échoue recherche sans le sous-répertoire. Pour TeX, METAFONT et MetaPost : KERTEXPOOL : les messages à afficher. Le programme _doit_ les trouver. Pourquoi sont-ils à l'extérieur ? Pour permettre de les particulariser, de les traduire... Ah!!! Eh, oui !... KERTEXINPUTS : les chemins à parcourir pour trouver les macros, les .mf. Si un "\input" échoue, vous savez désormais pourquoi. KERTEXDUMP : si le format a été précompilé (``dump''ed), en fonction de argv[0] METAFONT/TeX tente de charger argv[0].{base|fmt}. C'est là qu'il le cherche. Pour dvips et bibtex : KERTEXINPUTS : les chemins à parcourir pour trouver sa configuration (dvips.cnf), les morceaux de code PostScript à inclure (*.ips), les fichiers d'encodage (*.enc) ainsi que des fichiers (probablement images eps) que votre document demande d'incorporé, ou les styles ou bases de données bibliographiques pour bibtex. Pour les programmes CWEB (ctangle(1) et cweave(1)) : CWEBINPUTS : on peut spécifier plusieurs répertoires alternatifs séparés par ':'. D'autres programmes plus spécifiques nécessitant de rechercher dans des répertoires ne leur "appartenant" pas (les programmes WEB etc.) sont initialisés avec les valeurs correctes pour kerTeX et ne tiennent pas compte des variables d'environnement. Mais comme le répertoire courant est toujours exploré, cela ne devrait pas poser de problème. ------------------------------------------------------------------------ 6. MetaPost de John Hobby. MetaPost a été ajouté à kerTeX. Quelques différences à noter avec les autres distributions : - Par souci de consistance, MetaPost ne gère plus le drapeau `-I' mais, à l'instar de mf et tex, est présenté sous deux incarnations : inimp(1) et virmp(). A la place d'invoquer `-I', il suffit d'appeler inimp(1) ; - De même --- mais le programme n'est pas directement visible par l'utilisateur --- makempx a été renommé texmpx(1) par symétrie avec troffmpx(1). - Les fichiers produits le sont dans le répertoire courant, en particulier .mpx afin de permettre une utilisation avec des sources en lecture seule. - Le seul utilitaire (newer(1)) qui n'était pas C89 mais nécessitait POSIX.1 a été supprimé, remplacé par des commandes Bourne Shell dans les scripts, afin que les programmes compilés soient portables et que l'adaptation n'ait à porter que sur les scripts (ce qui devrait être trivial). - Enfin, le passage au banc d'essai étant propre à MetaPost, cette épreuve a désormais son propre nom : TWIST ! (voir plus bas) MetaPost peut générer les labels avec troff(1) à la place de tex(1). Il convient par contre d'adapter la carte de correspondance des fontes pour troff, ce qui dépend de l'installation. Voir la page de manuel mpost(1). ------------------------------------------------------------------------ 7. Passer au banc d'essai. Donald E. Knuth a fourni des jeux d'épreuves pour passer les programmes prétendant être des implémentations de METAFONT et TeX. John Hobby a fait de même pour MetaPost. Et l'équipe NTS aussi pour e-TeX. Pour effectuer la vérification, invoquez: $ $KERTEX_BINDIR/adm/ck_tex $ $KERTEX_BINDIR/adm/ck_mf $ $KERTEX_BINDIR/adm/ck_mpost $ $KERTEX_BINDIR/adm/ck_etex Le résultat est publié sur la sortie standard en vous indiquant comment le lire et où trouver le manuel correspondant. Nos implémentations passent l'épreuve. ------------------------------------------------------------------------ 8. Convertir le dvi en PostScript(R) d'Adobe. La mise en page compilée par TeX est au format dvi. Pour obtenir une représentation du contenu (à l'écran ou une impression), il faut en passer par un pilote effectuant la traduction du dvi en une séquence d'instructions compréhensibles par le périphérique générant la représentation. dvips(1) est le pilote traduisant le dvi en PostScript. Le fichier de configuration est dans : [/usr/pk]/lib/kertex/dvips/dvips.cnf (ce fichier est appelé "config.ps" dans les autres versions de dvips). Afin de connaître la quantité de mémoire disponible dans votre imprimante PostScript, ainsi que la version PostScript supportée, vous pouvez lui envoyer ce programme : ----------BEGIN PS---------- %!PS /Times-Roman % we will use this font 14 selectfont % current font at 14pt 72 432 moveto % we don't know the size of the paper; just enough vmstatus % returns level used maximum exch sub % exchange used and maximum and substract used from max 20 string cvs % allocate string and convert value to it (free memory: ) show show % the string stacked pop % pop level 72 412 moveto (language level: ) show languagelevel 20 string cvs show % idem showpage % fiat lux %%EOF ----------END PS---------- La version dvips(1) de kerTeX est une version modifiée. Principalement : - C'est une version C89 pur ; tout le code dépendant du système a été supprimé. En particulier, dvips(1) ne cherche plus à envoyer le programme PostScript au gestionnaire d'impression : il produit (par défaut) le PostScript sur la sortie standard. Redirigez vers un fichier : $ kertex/dvips fichier.dvi >fichier.ps ou : $ kertex/dvips -o fichier.ps fichier.dvi ou transférez au gestionnaire : $ kertex/dvips fichier.dvi | lpr Seuls le caractère de séparation des répertoires et l'encodage système (essentiellement pour support ebcdic à la place de ascii) sont conservés (et gérés en fait par l'infrastructure R.I.S.K. : les adaptations éventuelles sont à réaliser là.) - Tout le support des "backtick commands" a été supprimé : les commandes enfouies dans les dvi et supposées être exécutées directement via system/popen ne sont pas traitées. (C'est une faille de sécurité importante et c'est qui plus est inutile puisque vous pouvez pré-traiter le fichier ou les images incluses.) - La génération automatique des fontes (METAFONT) manquantes existe toujours, mais elle n'est plus activée par défaut : vous devez spécifier l'option (nouvelle) "-G" pour l'obtenir. La commande à utiliser (si la génération n'est pas demandée ou si elle échoue) est publiée en commentaire sur stderr afin de permettre à l'utilisateur de la lancer lui-même par la suite. En particulier, le fichier missfont.log qui recueillait cette information n'est plus créé. Par principe, dvips(1) génère des flots (sur stdout et stderr) et n'écrit rien par défaut. Il peut donc être invoqué en "survol" d'un répertoire en lecture seule. - Les supports des commandes spéciales de emTeX et TPIC ont été supprimés. - Le support pour HyperTeX (pour les liens PDF) est inclus. - Le support des fontes Adobe est en place. Par défaut (dans le fichier dvips.cnf), les versions T1 des fontes Computer Modern sont utilisées. Le support des fontes passe par des cartes de correspondances (*.map) qui comprennent le nom utilisé par TeX, le nom à utiliser pour PostScript, éventuellement un ré-encodage, et éventuellement un fichier de description (.pfa ou .pfb) à inclure. C'est une question de configuration (de fichiers *.map) et le plus simple est de lire le manuel de Tomas Rokicki qui est inclus (sous forme de source) avec kerTeX. Pour les options, la page de manuel est à jour. Pour un tutoriel, en particulier sur la gestion des fontes et des correspondances, générez le manuel de Tomas Rokicki (partiellement obsolète pour les options, mais reste la référence pour le reste) : cp [/usr/pkg]/lib/kertex/dvips/dvips*.tex /tmp cd /tmp # Vous devez avoir dvips.tex et dvipsmac.tex kertex/tex dvips.tex # production du dvi kertex/dvips -G dvips.dvi >dvips.ps # certaines fontes (logo) à générer Pour passer votre installation au banc d'essai, la page de test de Tomas Rokicki est belle : #BEGIN_DVIPSCK TARGETBINDIR=/usr/pkg/bin # bin host repertory (NetBSD) KERTEXLIB=/usr/pkg/lib/kertex # machine independent kerTeX stuff cp $KERTEXLIB/dvips/doc/test.tex /tmp cd /tmp # Attention ! deux passes. À la première, il y a un message d'erreur, # mais c'est normal car le fichier à inclure est précisément # celui que l'on cherche à produire (le test inclut en lui-même une # image de lui-même en encart). # Ne cherchez surtout pas à aller trop vite en nommant directement # le premier PostScript "mtest.ps" sinon vous entrez dans une boucle # non pas infinie, mais qui se terminera lorsque votre disque sera # plein... # $TARGETBINDIR/kertex/tex test.tex $TARGETBINDIR/kertex/dvips test.dvi >test.ps # un message d'erreur normal non fatal mv test.ps mtest.ps # mtest.ps est le nom du fichier à inclure. $TARGETBINDIR/kertex/dvips test.dvi >test.ps # le résultat. Admirez ! #END_DVIPSCK ------------------------------------------------------------------------ 9. Les fontes. C'est un sujet à part entière, qui ne sera abordé que succinctement dans ce qui suit et exclusivement pour expliciter les particularités des fontes distribuées avec KerTeX. Il doit être noté que nous utilisons dans kerTeX certains des identifiants (les noms) qui peuvent comporter un sous-répertoire. Plutôt que d'ajouter, ``à plat'', dans un unique répertoire, des fontes qui n'ont pas le même encodage etc., nous les répartissons dans une hiérarchie, à la façon de l'arborescence Unix, et ce sous-répertoire est partie du nom. (Cela a une importance cruciale, car dvips(1) a été modifié pour les utiliser.) TeX est un moteur de mise en forme, qui ne ``voit'' pas le dessin des caractères qu'il assemble, mais doit connaître leurs spécificités métriques, c'est-à-dire les moyens de les assembler. Il est ainsi possible d'utiliser avec TeX des fontes dont on ne connaît que les métriques, sans posséder le dessin précis des caractères --- mais à supposer que ce dessin précis puisse être fourni au moment du rendu par le périphérique interprétant le dvi généré par TeX. Qui plus est, au final, pour TeX un caractère, c'est un entier : l'encodage est donc primordial, et l'encodage de la fonte doit correspondre au flot de caractères fourni en entrée à TeX. Mais il est possible, à divers niveaux, d'opérer des transcriptions. En l'occurrence, comme Adobe fournit les spécifications métriques des fontes normalisées de PostScript, qui sont présentes dans les imprimantes PostScript, il est possible d'utiliser ces fontes avec TeX. L'avantage principal --- mais la même chose pourrait être faite avec les fontes Computer Modern, à conditions de décrire les fontes virtuelles --- est de pouvoir créer des fontes couvrant l'ensemble de la plage latin1 et donc, pour des utilisateurs de latin1 ne se cantonnant pas dans la plage ASCII, d'utiliser par exemple directement les caractères accentués sans passer par les ligatures. Mais par défaut, l'encodage standard PostScript ne couvre que la plage ASCII. Il y a donc diverses manipulations opérées pour bénéficier de la plage latin1, qui plus est en étant compatible avec les conventions de ``plain TeX''. Des fontes utilisables avec un encodage latin1 sont donc créées à l'installation, et se trouvent dans le sous-répertoire : PKGDIR/fonts/tfm/tex-latin1/ Elles doivent être utilisées en précisant le sous-répertoire tex-latin1/, ainsi par exemple : \font\tenrm=tex-latin1/Times-Roman at 10pt Le sous-répertoire indique ici l'encodage, qui n'est pas normal, et qui est à la fois compatible avec ``plain TeX'' et l'encodage 8 bits latin1 (mais le sous-répertoire n'est pas interprété : c'est un moyen d'organisation des données, pas un indice pour le logiciel de l'encodage), la fonte en elle-même portant le nom PostScript suivi éventuellement d'un suffixe introduit par `_' s'il s'agit d'une version modifiée, la ou les deux lettres suivantes indiquant le type de la manipulation : - `c' version condensée (étroite) de l'original ; - `e' version étirée de l'original ; - `o' version oblique d'un original droit ; - `u' (upright) version droite d'un original oblique ; - "sc" version petites capitales (small caps) d'un original comportant des minuscules. Voici la liste des tfm créés à l 'installation : tex-latin1/Courier-Bold.tfm tex-latin1/Courier-BoldOblique.tfm tex-latin1/Courier-Oblique.tfm tex-latin1/Courier.tfm tex-latin1/Helvetica-Bold.tfm tex-latin1/Helvetica-BoldOblique.tfm tex-latin1/Helvetica-BoldOblique_c.tfm tex-latin1/Helvetica-Bold_c.tfm tex-latin1/Helvetica-Oblique.tfm tex-latin1/Helvetica-Oblique_c.tfm tex-latin1/Helvetica.tfm tex-latin1/Helvetica_c.tfm tex-latin1/ITCAvantGarde-Book-sc.tfm tex-latin1/ITCAvantGarde-Book.tfm tex-latin1/ITCAvantGarde-BookOblique.tfm tex-latin1/ITCAvantGarde-Book_sc.tfm tex-latin1/ITCAvantGarde-Demi.tfm tex-latin1/ITCAvantGarde-DemiOblique.tfm tex-latin1/ITCBookman-Demi.tfm tex-latin1/ITCBookman-DemiItalic.tfm tex-latin1/ITCBookman-Light-sc.tfm tex-latin1/ITCBookman-Light.tfm tex-latin1/ITCBookman-LightItalic.tfm tex-latin1/ITCBookman-Light_sc.tfm tex-latin1/ITCZapfChancery-MediumItalic.tfm tex-latin1/NewCenturySchlbk-Bold.tfm tex-latin1/NewCenturySchlbk-BoldItalic.tfm tex-latin1/NewCenturySchlbk-Italic.tfm tex-latin1/NewCenturySchlbk-Roman-sc.tfm tex-latin1/NewCenturySchlbk-Roman.tfm tex-latin1/NewCenturySchlbk-Roman_sc.tfm tex-latin1/Palatino-Bold.tfm tex-latin1/Palatino-BoldItalic.tfm tex-latin1/Palatino-BoldItalic_u.tfm tex-latin1/Palatino-Italic.tfm tex-latin1/Palatino-Italic_u.tfm tex-latin1/Palatino-Roman-sc.tfm tex-latin1/Palatino-Roman.tfm tex-latin1/Palatino-Roman_c.tfm tex-latin1/Palatino-Roman_e.tfm tex-latin1/Palatino-Roman_o.tfm tex-latin1/Palatino-Roman_sc.tfm tex-latin1/Times-Bold.tfm tex-latin1/Times-BoldItalic.tfm tex-latin1/Times-Bold_o.tfm tex-latin1/Times-Italic.tfm tex-latin1/Times-Roman-sc.tfm tex-latin1/Times-Roman.tfm tex-latin1/Times-Roman_c.tfm tex-latin1/Times-Roman_e.tfm tex-latin1/Times-Roman_o.tfm tex-latin1/Times-Roman_sc.tfm Les fontes décrites sur 8 lettres seulement, dans la version originelle de dvips(1) sont aussi fournies, mais pour compatibilité seulement. Par nature, il ne ``manque'' pas des fontes, puisqu'il suffit qu'un paquet de formatage les utilisant les ajoute à l'endroit prévu. Sont fournies par kerTeX, bien évidemment toutes les fontes Computer Modern de Donald E. Knuth, avec leurs versions PostScript T1 fournies par AMS, ainsi que toutes les fontes fournies par AMS. Les fontes normalisées PostScript sont utilisables à partir des métriques fournies par Adobe (voir ci-dessus), mais seules les métriques sont présentes : la définition des fontes doit être présente dans les périphériques. (Par exemple, un logiciel de rendu dvi sera, a priori, incapable de dessiner le résultat s'il n'a pas accès à une version des fontes ; mais pourtant, le dvi sera imprimable sur une imprimante PostScript, précisément parce que cette imprimante a ces fontes en résident.)