1 Introduction
Écrire ses papiers en LATEX est une tradition relativement bien
établie de notre domaine dont on peut penser
qu'elle se maintiendra.
Cela tient sans doute d'une part à l'excellente qualité finale des
impressions papier obtenues et d'autre part à des facteurs
plus sociologiques, tels la gratuité de LATEX, le poids des
habitudes et un certain consensus entre auteurs et éditeurs.
Toutefois, nous disposons aujourd'hui, avec le web, d'un nouveau moyen
de diffusion de nos oeuvres.
La technique la plus simple de publication électronique d'un article
est la mise à disposition d'une
versions formatée par LATEX (.dvi ou PostScript).
Cette démarche simplifie le travail de l'auteur qui
réutilise le fichier qu'il envoie à son éditeur.
La démarche du lecteur internaute est ensuite finalement la même que
celle du lecteur d'un journal scientifique ou des actes d'une
conférence : après une lecture rapide du document il imprimera
l'article pour le lire tranquillement si il est intéressé.
La publication du document en HTML offre des possibilités
supplémentaires: recherche de mots-clés dans le document, lecture non
linéaire à partir d'une table de liens, accès par un simple click de
souris à d'autres
documents, tels des articles référencés ou des documents
complémentaires omis dans la version papier faute de place.
En outre, le fichier HTML sera plus petit, ce qui minimise les
temps de chargement, et sa lecture se fera à travers l'outil
universel de l'internaute: le browser web.
En effet, tous les systèmes (et en particulier les ordinateurs
personnels) ne proposent pas un visualiseur
dvi ou PostScript.
Par ailleurs, la piètre qualité des documents imprimés à
partir du HTML interdit l'écriture d'articles directement en HTML.
Les possibilités offertes par la lecture web se justifient
particulièrement dans le cas des manuels de logiciels : en effet on lit
rarement ces manuels d'une traite, on butine plutôt dedans à la
recherche d'une information précise. Par ailleurs, la lecture sur
écran est ici un avantage qui offre au lecteur un aller et retour
rapide entre une fenêtre où il utilise le logiciel et une autre où il
consulte sa documentation. Enfin, les mises à jour des manuels lors
des changements de versions des logiciels sont immédiates.
Les manuels étant souvent de taille importante, et leur mise au point
demandant de nombreuses itérations, il est particulièrement important
de disposer d'un traducteur rapide. L'utilisateur doit également pouvoir
facilement paramétrer les traductions ou même d'étendre la fonctionnalité
du traducteur.
En effet, il est vain de croire que
l'auteur d'un traducteur puisse tout prévoir ; d'autre part il est
parfois impossible
de rendre en HTML certaines constructions LATEX ou certains
symboles.
Dans ce dernier cas, il faudra rendre le symbole par un équivalent,
dont le choix dépend du goût de l'utilisateur et de la nature de son
document.
Les lecteurs intéressés par par un manuel de référence d'HEVEA
consulteront [7].
En effet,
cet article décrit plutôt le fonctionnement interne d'HEVEA.
Il commence
établir le principe d'une traduction lexicale de LATEX vers HTML
(sections 2).
De ce principe résulte l'architecture d'HEVEA qui
distingue nettement l'émission de HTML par
le gestionnaire de sortie (section 3) et la reconnaissance
de l'entrée par l'analyseur lexical principal (section 4).
La section 4 explique également comment reconnaître et
traduire les formules mathématiques en HTML.
La réalisation du mécanisme de commande et d'appel par
nom de LATEX et son utilisation pour paramétrer
HEVEA sont ensuite décrites en détail
(sections 5 et 6).
Enfin, je conclue par une rapide comparaison d'HEVEA avec d'autres
traducteurs et par quelques perspectives d'avenir.