La version Win32 de Web2c possède quelques spécificités qui méritent d’être notées.
La commande kpsecheck peut aussi indiquer le statut d’utilisation de la mémoire partagée : en utilisation ou non-utilisée. Cette information peut être très utile, car si le statut rapporté est « en utilisation », cela signifie qu’un ou plusieurs processus tournent et utilisent le bloc de mémoire partagée. Dans ce cas, une réinitialisation des tables de hachage basée sur les fichiers ls-R, comme la commande mktexlsr l’effectue, sera automatiquement repoussée jusqu’à ce que tous les processus utilisant la version courante en mémoire partagée soient terminés. Il est prévu d’enlever cette limitation dans une version future, mais la version actuelle de Kpathsea ne permet pas de faire facilement cette réinitialisation.
Enfin, la même commande kpsecheck peut indiquer l’endroit où Kpathsea pense pouvoir trouver la Dll de Ghostscript. En effet, sous Win32, il est souvent plus simple de travailler directement avec la Dll de Ghostscript, et de la trouver en utilisant la clé appropriée dans la base de registre, que d’utiliser gswin32c.exe et de modifier le PATH qui a une longueur limitée.
Vous avez une option dans le menu TeXLive (Démarrer -> Programmes -> TeXLive) qui vous permet de lancer à nouveau le programme TeXSetup.exe en mode maintenance. Les étapes à franchir sont pratiquement les mêmes que celles de l’installation.
Le seul point différent concerne la sélection des composants. En mode maintenance, une comparaison est effectuée avec les composants installés sur votre disque dur. Vous verrez alors s’afficher en vert les composants dont vous ne disposez pas encore, en rouge ceux dont vous disposez mais pour lesquels une version plus récente est disponible et en noir ceux qui sont déjà installés.
Ainsi vous pouvez choisir d’ajouter ou de mettre à jour des composants soit depuis votre CD-ROM, soit depuis Internet auquel cas il est probable que vous trouverez également des composants plus récents que ceux que vous avez déjà installés.
Il vous appartient de faire votre choix parmi l’ensemble des composants. Pour le reste, les étapes sont identiques à celles de l’installation initiale.
Si vous choisissez d’ajouter des fichiers qui ne proviennent pas de la distribution TeX Live (ou fpTeX), il vous est fortement recommandé de les mettre dans le répertoire $TEXMFLOCAL. De cette manière, vous serez certain qu’il n’y aura pas de problème lors d’une mise à jour de TeX Live.
L’arborescence pointée par $TEXMFLOCAL est initialement vide. Si vous souhaitez y ajouter les fichiers de
style pour supporter le logiciel de calcul formel Maple, vous devrez mettre ces fichiers dans le répertoire
c:\Program Files\TeXLive\texmf-local\tex\latex\maple\
et les fichiers de documentation dans
c:\Program Files\TeXLive\texmf-local\doc\latex\maple\
Ensuite, n’oubliez pas de reconstruire les bases de données de fichiers, soit en utilisant le menu prévu à cet effet (Démarrer -> Programmes -> TeXLive -> Maintenance), soit en lançant manuellement la commande mktexlsr. Si vous l’oubliez, vos fichiers ne seront pas trouvés.
La procédure de désinstallation est disponible soit depuis le programme TeXLive.exe, soit depuis le menu TeXLive, soit depuis le panneau de contrôle (menu Démarrer -> Panneau de Contrôle, option Ajouter/Enlever des programmes). Cette procédure nettoie votre disque dur de la plupart des fichiers qui y ont été mis lors de l’installation initiale. Cependant, TeX est un système qui génère maints fichiers et, pour l’instant, il n’est pas prévu de mécanisme pour en garder la trace. D’autre part, les composants supplémentaires spécifiques à Windows possèdent leur propre procédure de désinstallation qu’il faudra lancer séparément. Enfin, les éventuels fichiers que vous aurez mis dans le répertoire $TEXMFLOCAL ne seront pas inquiétés. Donc, même si la majeure partie des fichiers est nettoyée automatiquement, il vous restera quelques opérations manuelles à effectuer.
Le programme TeXSetup.exe possède un certain nombre d’autres options intéressantes. Vous pouvez en obtenir la liste en lançant :
Voici leur description :
Kpathsea est compatible avec les noms UNC, donc vous pouvez les utiliser pour récupérer votre répertoire texmf principal depuis le réseau. Mais encore mieux que cela, tous les fichiers, y compris ceux de configuration et excepté les binaires dans bin/win32 sont compatibles et partageables avec teTeX ou le TeX Live Unix. Cela signifie que vous pouvez utiliser Samba, soit pour monter votre distribution Unix sur votre client Windows, ou votre client Unix depuis un NT serveur. Plusieurs stratégies sont possibles :
Winshell devrait automatiquement trouver le visualiseur Windvi. Si ce n’était pas le cas, lancez Winshell depuis le menu Démarrer ou le raccourci sur le bureau, et allez dans Options->Program Calls :
Remarquez que l’installateur de WinShell associe les fichiers avec extension .texà WinShell. Ceci est correct, à moins que vous ne souhaitiez utiliser un autre éditeur (tel que WinEdt ou Emacs).
Il manque un correcteur orthographique à WinShell. Si vous avez installé la collection tex-extrabin et le composant ispell, vous avez alors accès au correcteur Ispell disponible sur la plupart des systèmes Unix. Le programme est sur votre PATH, donc il sera trouvé, même si vous l’appelez à partir d’une console (fenêtre DOS). Si vous avez installé la documentation, référez vous à c:\Program Files\TeXLive\texmf\doc\html\manpages\ispell.html pour plus d’informations (fichier également disponible sur le CD-ROM). Si vous utilisez habituellement un vérificateur d’orthographe, vous pouvez souhaiter ajouter une icône pour Ispell à WinShell (voir la sous-section 5.9.4).
Pour un excellent (mais commercial, quoique peu onéreux) correcteur orthographique, se reporter à http://www.microspell.com.
D’autres informations sur WinShell en section 5.9.
Le fichier de configuration de dvips se trouve par défaut en c:\Program Files\TeXLive\texmf-var\dvips\config\config.ps. Vous pouvez l’ouvrir avec n’importe quel éditeur de texte (comme WinShell) pour modifier certains paramètres :
Le fichier de configuration pour Pdftex se trouve en c:\Program Files\TeXLive\texmf-var\pdftex\config\pdftex.cfg.
Vous pouvez l’ouvrir dans un éditeur de texte pour modifier son contenu, par exemple remplacer le format de
papier A4 par le format US letter ou tout autre. Ouvrez le fichier de configuration dans un éditeur de texte et
remplacez les valeurs des paramètres page_width et page_height pour spécifier les valeurs voulues, par
exemple :
page\_width 8.5 true in
page\_height 11 true in
Sauvegarder le fichier et sortir de l’éditeur.
À partir des versions compatibles avec Ghostscript 6.50, Ghostview n’est plus un logiciel libre, mais un shareware. Il n’est donc plus fourni sur le CD-ROM.
Si vous voulez changer le format du papier, ouvrez GSView à partir du menu Démarrer, Programmes. Depuis le sous-menu Media, sélectionnez Letter. Le sous menu Display Settings vous permet également d’améliorer la netteté du rendu en positionnant les deux valeurs Text Alpha et Graphics Alpha à 4 bits.
Pour ce qui est de l’impression, se référer à la sous-section 5.8.
Les fichiers .ps et .eps seront ouverts automatiquement par GSView.
Vous pouvez lancer Windvi à partir du menu Démarrer, Programmes, TeXLive ou en double cliquant un fichier .dvi dans l’explorateur de fichiers..
Pour sélectionner un format de papier US Letter, allez dans le menu View, Options de Windvi et sélectionnez « US (8.5"x11") » dans la liste déroulante Paper Type. Cliquez OK et fermez Windvi.
La première fois que vous ouvrirez un fichier .dvi, vous pouvez trouver le facteur de zoom trop important, réduisez le en tapant sur la touche « moins » du clavier numérique jusqu’à ce qu’il soit à votre goût.
Vous pouvez modifier le format de papier dans les options de Windvi (menu View, Options) ainsi qu’un certain nombre d’autres paramètres comme par exemple la capacité à exécuter des commandes externes spécifiées dans des \special{}.
Les fichiers :
c:\Program Files\TeXLive\texmf\doc\windvi\Examples\wtest.dvi
c:\Program Files\TeXLive\texmf\doc\windvi\Examples\wtest.tex
démontrent l’ensemble des possibilités de Windvi.
L’impression avec Windvi nécessite pour l’instant que les paramètres de mode METAFONT et de résolution soient positionnés en accord avec les caractéristiques de votre imprimante.
Vous pouvez les modifier dans le menu View, Options de Windvi ou vous trouverez une liste déroulante de modes (MF mode) ainsi que la possibilité de fournir une résolution (pixels per inches). Vous pouvez également les assigner une fois pour toutes en lançant Windvi en ligne de commande :
Lorsque vous quitterez Windvi, les paramètres seront sauvegardés. les modes disponibles sont définis dans le
fichier
c:\Program Files\TeXLive\texmf\metafont\misc\modes.mf
Les paramètres de Windvi sont sauvés dans un fichier du nom de $HOME/windvi.cnf. Vous pouvez le localiser de la manière suivante :
Si vous avez des problèmes avec Windvi, il est conseillé d’effacer le fichier de configuration, puis de refaire un test dans la configuration par défaut.
Vous pouvez tester rapidement votre installation basée sur WinShell en ouvrant le fichier
c:\Program Files\TeXLive\texmf\tex\latex\base\sample2e.tex Le source LaTeX doit apparaître à
l’écran. Compilez-le en cliquant sur l’icône LaTeX dans la barre d’outils, ensuite visualisez-le en cliquant sur
l’icône Preview (Windvi).
La première fois que vous visualiserez un document avec Windvi, il va créer les fichiers de fontes bitmaps qui ne sont pas installées. Après avoir visualisé quelques fichiers, vous aurez créé la plupart de ces fichiers et vous ne verrez plus souvent apparaître la fenêtre de création de fontes. Retournez à WinShell, et essayez Dvips puis GSView.
En cas de problèmes, reportez-vous à la sous-section 5.11.
Il est possible d’imprimer depuis Windvi. Dans ce cas, l’impression utilise le pilote unifié d’impression de Windows, il est donc par définition compatible avec toutes les imprimantes. Cependant, il y a un inconvénient : cette impression génère des fichiers (spool) très importants, quelques versions anciennes de Windows le supportent mal. L’avantage est que vous pouvez tirer parti de l’impression d’images BMP ou WMF par exemple. Il faut également faire bien attention à ce que les paramètres de l’imprimante soient correctement définis (sous-section 5.6.5) sous peine d’avoir un effet d’échelle (imprimer à 600 dpi sur une imprimante qui fait réellement 300 dpi résulte en un seul quart de la page visible).
L’impression est souvent plus rapide en utilisant dvips, puis en imprimant le fichier .ps depuis GSView. Pour imprimer depuis GSView, sélectionner Print. . . dans le menu File. Une fenêtre de dialogue pour l’impression apparaît.
Si vous utilisez une imprimante Postscript, soyez sûr de sélectionner PostScript Printer en choisissant cette option dans Print Method en bas à gauche de la boîte de dialogue, faute de quoi l’impression échouera. Vous pouvez ensuite sélectionner une imprimante quelconque parmi celles installées.
Si vous utilisez une imprimante qui ne supporte pas PostScript, sélectionnez Ghostscript Device dans Print Method. Ensuite cliquez sur le bouton djet500 et sélectionnez votre imprimante.
Si vous utilisez WinShell et une imprimante PostScript, le plus pratique est de définir un bouton Impression dans la barre d’outils de WinShell qui appellera dvips avec les options envoyant directement le résultat à l’imprimante. Pour des instructions détaillées sur la manière de procéder, reportez-vous à la sous-section 5.9.3.
L’auteur de WinShell (Ingo de Boer, merci à lui) publie des versions beta de la prochaine version qui sont également des correctifs. On peut les récupérer sur http://www.winshell.de. Il s’agit en général de fichiers archives aux format .zip qu’il suffit de décompresser dans le répertoire où se trouve WinShell, soit à l’aide d’un utilitaire tel que WinZip, ou bien d’une ligne de commande avec unzip. Si vous avez récupéré un correctif du nom de winshellbugfix.zip et que vous l’avez sauvegardé dans le répertoire de WinShell, alors vous devez exécuter :
Répondre « oui » quand il vous est demandé si des fichiers doivent être écrasés.
Si votre document comporte plusieurs fichiers (une thèse par exemple), essayez d’utiliser la capacité de WinShell à gérer des projets. Depuis le menu Project, attribuez un nom à votre projet, donnez le nom du document maître et ajoutez les autres fichiers qui composent votre projet. Ces fichiers apparaissent dans la fenêtre de gauche, vous pouvez cliquer dessus pour les visualiser et passer de l’un à l’autre. L’icône LaTeX provoque la compilation du fichier maître.
À noter les icônes de la barre d’outils pour commuter l’affichage du panneau concernant le projet (à gauche) et de la fenêtre de log (en bas). Si vous n’utilisez pas la fonctionnalité de projet, vous pouvez souhaiter faire disparaître la fenêtre de gauche pour travailler sur toute la largeur de l’écran.
Name: Print
exe file: dvips
cmd-line: -D600 %m -o \emph{vclw}
Décochez l’option pour « DVIPS first »
Maintenant, vous pouvez imprimer un document sur l’imprimante vclw en cliquant simplement sur l’icône Print. Si vous voulez utiliser une imprimante différente, il faut repasser par dvips pour imprimer dans un fichier, puis utiliser GSView pour envoyer ce fichier sur l’imprimante de votre choix.
Name: Ispell
exe file: ispell
cmd-line: -t -d francais %c.tex
Décochez les options pour « LaTeX first » et pour « DVIPS first »
Maintenant, lorqu’un document LaTeX est ouvert, vous pouvez cliquer sur l’icône Ispell pour réaliser une
vérification orthographique. Ispell va ouvrir une nouvelle fenêtre et afficher le premier mot inconnu sur la gauche
avec le nom de fichier sur la droite. En dessous, vous verrez le contexte dans lequel ce mot inconnu apparaît. La
plupart du temps, plusieurs propositions de remplacement vous sont offertes. Pour remplacer le mot, entrez le
numéro de la proposition choisie. D’autres possibilités existent, par exemple vous pouvez presser la barre
d’espace pour ignorer cette détection d’erreur. Pour plus d’informations sur Ispell, référez -vous au manuel
:
c:\Program Files\TeXLive\texmf\doc\html\manpages\ispell.html
Quand vous choisissez de remplacer un mot dans Ispell, le remplacement ne sera effectif dans WinShell qu’une fois le processus Ispell terminé et le fichier sauvegardé (cliquez sur le X dans le coin supérieur droit de la fenêtre), il vous faudra ouvrir le fichier à nouveau dans WinShell.
Ce que recouvre la dénomination Win32 n’est pas un système d’exploitation. C’est un ensemble de fonctions très vaste5 que vous pouvez utiliser pour écrire des programmes pour différentes versions des systèmes d’exploitation de la famille Windows.
Windows se décline en plusieurs versions :
Win9x est capable de faire tourner des programmes 32 bits et des programmes 16 bits en même temps. Mais le système d’exploitation lui-même n’est pas entièrement écrit en mode 32 bits et ne fournit pas une protection mémoire entre les applications : les applications 16 bits peuvent écraser des parties du système d’exploitation en mémoire ! Des parties du système telles que le GDI (Graphical Device Interface) ne se voient allouer que des ressources de taille très limitée pour gérer les bitmaps, les pinceaux et les polices, et ces resources sont allouées de manière globale pour tous les programmes qui tournent de manière concurrente. Par exemple, toutes les entêtes de bitmaps utilisés par tous les programmes qui tournent simultanément ne doivent pas requérir plus que 64ko de mémoire. Ceci explique le comportement du moniteur de performance, et le fait que vous pouvez mettre votre système à genoux en utilisant de manière intensive les objets graphiques.
NT, 2K et XP ne souffrent pas de ces limitations, et d’aucune autre limitation de Win9x. Ce sont de vrais environnements multitâches, avec une vraie mémoire protégée. Ils répondent de manière plus fluide que Win9x de par leur meilleure gestion de la mémoire, leur système de gestion de fichiers plus performant, etc.
Vous allez vous demander : mais pourquoi diable devrais-je me préoccuper d’une ligne de commande alors que j’ai Windows ?
Bonne question. le problème est de nature très générale. Toutes les opérations ne peuvent pas être accomplies très facilement à l’aide de la seule interface graphique. La ligne de commande vous donne la puissance de la programmation – si vous avez un bon interpréteur de commandes.
Mais le problème est plus fondamental : TeX est un outil qui fonctionne en batch, de manière non-interactive. TeX a besoin de calculer la meilleure mise en page pour chaque page, de résoudre les références croisées, etc. Ceci ne peut être réalisé que par un traitement global du document. Ce n’est pas encore une tâche qui peut être réalisée interactivement.
Ceci implique que vous devriez utiliser TeX depuis la ligne de commande. En fait la situation n’est pas si catastrophique. Il y a un avantage à écrire des outils en ligne de commande pour des tâches complexes : ils sont bien plus fiables, parce qu’ils n’héritent pas de la complexité inhérente aux interfaces graphiques. Il est ensuite possible de concevoir des outils graphiques qui servent d’interface aux outils en ligne de commande. C’est le cas de TeX : vous interagirez avec lui la plupart du temps au travers d’un éditeur de textes qui possède une interface graphique – voir la section 5.6.1 par exemple.
Cependant, il se peut que vous ayez besoin d’utiliser la ligne de commande dans un certain nombre de situations, par exemple en cas de problèmes, parce que vous avez besoin de trouver une erreur dans votre installation – voir la section 5.11.
L’API Win32 admet les deux caractères / et \ comme séparateurs pour les noms de fichiers. Mais pas les interpréteurs de commande ! Donc, chaque fois qu’un nom de fichier est utilisé par un programme, vous pouvez utiliser l’un ou l’autre séparateur, mais sur la ligne de commande, vous devez utiliser \ comme unique séparateur. Ce qui explique que vous pouvez taper :
mais pas :
Dans le premier cas, seuls des programmes utiliseront le chemin que vous avez fourni, dans le deuxième c’est l’interpréteur de commandes qui va vouloir s’en servir directement.
Tout ceci pour dire : ne soyez pas surpris de voir des noms de fichiers écrits avec des / en guise de séparateurs, à la Unix ; fpTeX est un portage de Web2c, dont l’objectif est d’être compatible avec toutes les plateformes. Pour cette raison, les fichiers de configuration utilisent la convention Unix des séparateurs dans les noms de fichiers.
Il est aussi à noter qu’il existe un autre séparateur qui sert à séparer plusieurs chemins, comme c’est le cas dans la variable d’environnement PATH. Sous Win32, ce séparateur est un ; alors que c’est le caractère : sous Unix. Étant donné que le : sert de séparateur de nom de périphérique dans plusieurs systèmes d’exploitation, ici c’est Unix qui a adopté la convention de Win32 en utilisant le caractère ; pour séparer plusieurs chemins. En fait Unix peut utiliser ; ou :, alors que Win32 ne peut pas utiliser : qui serait ambigu.
Une des plus mauvaises caractéristiques de Win9x vis-à-vis de TeX est probablement ce qu’on appelle le système de fichiers FAT. TeX utilise une myriade de petits fichiers dont la taille varie entre 1ko et 5ko. Le système FAT est ancien et date d’une époque bien antérieure à l’apparition des disques de plusieurs Go qui sont monnaie courante aujourd’hui. Tout ceci pour dire qu’il n’est pas possible de gérer efficacement les 30000 fichiers de TeX Live sur un disque dur formaté en FAT. Les fichiers se verront allouer chacun 32ko au minimum, donc l’installation de TeX Live utilisera beaucoup plus de place que nécessaire.
Le seul moyen d’éviter ce problème consiste à passer en FAT32 ou NTFS. Ces systèmes sont plus récents et n’ont pas l’inconvénient de FAT. La taille des clusters par défaut y est de 4ko, leur accès est plus performant. NTFS est protégé, redondant et on peut même ajuster la taille des clusters jusqu’à 512 octets à la création.
Il existe dans votre système des variables qui agissent un peu comme des variables globales à tous vos programmes. On appelle cet ensemble de variables l’environnement. Chaque programme hérite à son démarrage d’une copie de l’environnement. Il peut modifier les valeurs des variables, ajouter ou enlever des variables, mais les modifications ne sont effectives que pour sa propre copie et ne sont pas propagées aux autres programmes, sauf à ceux qu’il lance lui-même.
Votre variable PATH est une variable spéciale de l’environnement utilisée pour chercher les programmes lorsque vous en demandez l’exécution. Il y a une procédure différente pour modifier cette variable selon que vous êtes sous Win9x, ME ou NT/2K/XP.
Les modifications ne prendront effet qu’après redémarrage de la machine.
Si il y a déjà un PATH défini pour votre compte utilisateur, cliquez dessus. Dans le champ Variable apparaît PATH et dans le champ Valeur, la liste courante de répertoires séparés par des ;. Ajoutez les répertoires où se trouvent vos exécutables (i.e. c:\Program Files\TeXLive\bin\win32). Si la variable PATH n’est pas encore définie, il suffit de taper son nom dans le champ Valeur et la valeur initiale que vous souhaitez lui donner dans le champ Valeur. Important : cliquez sur le bouton Appliquer avant de cliquer sur Ok, de cette manière, les modifications seront propagées immédiatement à votre session.
Le meilleur moyen de savoir si une variable a été correctement définie consiste à ouvrir une console et à taper
la valeur correspondante devrait vous être retournée.
En lisant la documentation de Web2c, vous verrez que les différents programmes dérivés de TeX utilisent le même moteur de base. Par exemple, tex.exe et latex.exe sont des copies exactes du même programme, mais chacun utilise un fichier de format différent, en se basant sur le nom par lequel il a été invoqué.
Sous Unix, ce mode de fonctionnement est réalisé en faisant appel aux liens symboliques. On peut économiser un peu d’espace disque, car plusieurs moteurs de base sont utilisés avec différents fichiers de format.
L’API Win32 ne connaît pas les liens symboliques. Dans le but d’économiser tout de même un peu de place disque, tous les moteurs TeX de base ont été mis dans des DLL (Dynamic Linked Library). Ceci se traduit par l’aspect suivant pour les fichiers :
Il existe même un outil générique appelé lnexe.exe qui permet de simuler les liens durs de Unix sous Win32, mais uniquement pour les fichiers .exe.
Vous pouvez également définir un niveau de trace :
La trace de l’exécution des commandes suivantes sera conservée dans le fichier err.log. Si vous voulez rediriger le flux stderr sur le flux stdout, ce qui n’est normalement possible sous aucune version de Windows, il vous suffit de faire :
De cette manière, vous pourrez rediriger à la fois stdout et stderr dans le même fichier.
kpsewhich -expand-path $SELFAUTOPARENT | c:/Program Files/TeXLive |
kpsewhich -expand-path $TEXMF | c:/Program Files/TeXLive/texmf |
kpsewhich -expand-path $TEXMFCNF | .;c:/Program Files/TeXLive/texmf/web2c; |
c:/Program Files/TeXLive/bin/win32; | |
c:/Program Files/TeXLive/bin; | |
c:/Program Files/TeXLive | |
kpsewhich -expand-var $TEXINPUTS | .;c:/Program Files/TeXLive/texmf/tex// |
kpsewhich cmr10.tfm | c:/Program Files/TeXLive/texmf/fonts/tfm/public/cm/cmr10.tfm |
kpsewhich latex.fmt | c:/Program Files/TeXLive/texmf/web2c/latex.fmt |
Il y a plusieurs questions immédiates à se poser :
Le logiciel TeX Live est complexe, car composé de plus de 250 programmes et environ 40000 fichiers d’origines très différentes. Il est pratiquement impossible de prédire toutes les causes possibles de problèmes. Néammoins, nous ferons notre possible pour vous aider dans tous les cas.
La totalité des fichiers source, y compris pour Windows, est disponible dans l’archive source/source.tar.bz2 sur le CD-ROM. Pour recompiler l’ensemble de la distribution pour Windows, il vous faut :
Il reste beaucoup de travail à faire pour rendre la compilation plus simple.