Chapitre 4

Analyse préliminaire

Avant d'utiliser la chaîne de traitement proprement dite, un examen attentif de plusieurs numéros déjà parus doit être mené pour chaque revue. Cet examen doit être fait pour chaque nouvelle revue. Idéalement, l'analyse doit porter sur une période rétrospective suffisamment longue et un nombre de numéros suffisamment important pour englober l'ensemble des caractéristiques et variations de la revue. Cette analyse servira à identifier les types de documents (articles, comptes rendus, notes, études, etc.) et leur structure sémantique (titres, résumés, sections, subdivisions, tableaux, équations, illustrations, citations, renvois, références, notes infra-paginales, etc.).

C'est aussi l'occasion d'observer la régularité et la conformité de l'application du protocole de rédaction en vigueur, ce qui a un impact important sur la qualité. En principe, si les documents présentent une structure uniforme et constante (à l'intérieur d'un même document et d'un document à l'autre), si le protocole de rédaction a dûment été respecté et si l'étape du choix ou de la création de la DTD a été bien fait, les composants sémantiques rencontrés devraient tous être conformes à la DTD, dans leur présence, leur nombre et leur ordonnance. Dans la situation où la correspondance entre la DTD et certains éléments logiques se retrouvant dans les documents est impossible, il faudra apporter des modifications soit à la DTD, soit aux documents, soit à la fois à la DTD et aux documents. Cette intervention mérite une réflexion importante puisqu'elle est riche de conséquences. Dans un contexte de conversion rétrospective, il est impossible d'intervenir sur le contenu des documents. Les changements à la DTD doivent être faits en considérant un éventail de besoins et non seulement le besoin précis qui nous amène à vouloir modifier la DTD. Aussi, les changements à la DTD doivent être additifs et non correctifs, de façon à garder une certaine compatibilité avec les documents produits antérieurement à ces changements.

Outre les modifications de nature sémantique, les amendements doivent s'inscrire plus largement dans l'utilisation souhaitée, tant à court qu'à plus long terme, des documents. En effet, la mise en page en fonction de différents médias (papier, écran, etc.), la recherche structurée, la réutilisation de certaines parties de documents, etc. dépendront tous d'une indication SGML (un élément spécifique, une valeur d'attribut, etc.).

Par exemple, pour attribuer un formatage différent au prénom et au nom de l'auteur, les deux composants doivent se retrouver dans deux éléments SGML différents : le prénom et le nom de famille. Autre exemple : pour effectuer une recherche sur le nom d'un auteur cité, les références bibliographiques doivent être balisées comme telles, et non comme de simples éléments paragraphes au même titre que les autres paragraphes du texte.

Il faut également discerner les caprices de la mise en page papier actuelle, faite de façon manuelle la plupart du temps, des véritables besoins de discernement visuel des composants logiques. Ainsi, une information SGML doit être prévue pour faire en sorte qu'une liste ordonnée soit rendue de façon différente d'une liste à puces (par exemple un attribut type="numero" ou type="puce" pour l'élément liste). On pourra ainsi, à l'étape de production d'une sortie papier, produire respectivement un numéro séquentiel ou un symbole tel un rond plein (« * ») devant chaque item de liste. De plus, on peut s'interroger sur la nécessité de prévoir l'inclusion d'une valeur d'attribut différente pour désigner une liste à puce dont les items sont précédés d'un rond plein (« * »), celles dont les items sont précédés d'un rond vide (« ○ »), ou encore celles dont les items sont précédés d'un astérisque (« * »). Il y a fort à parier que les différents symboles observés pour mettre en retrait une liste à puce relèvent davantage d'un quelconque hasard au moment de la mise en page que d'un véritable besoin d'exprimer un élément logique spécifique.

En théorie, la production du SGML et les ajustements à la DTD ne devraient pas être faits en fonction des limites des outils employés ; cependant, en pratique, on ne peut ignorer cet aspect. Par exemple, une formule mathématique peut être finement balisée selon un modèle de DTD approprié (fonction, numérateur, dénominateur, arguments, etc.). En pratique cependant, plusieurs logiciels de notre chaîne de traitement ne peuvent reconnaître et traiter adéquatement une formule reproduite sous cette forme. On se rabattra alors sur une représentation graphique de la formule, c'est-à-dire l'insertion d'un fichier image. Ceci peut demander des modifications à la DTD. Autre exemple : l'emploi de jeux de caractères étrangers, bien qu'ils puissent être représentés en SGML (entre autres par l'emploi d'entités caractères codées en Unicode[ 3 ]), peut nous faire rencontrer les limites des outils de traitement. Ici, encore, on préconisera une solution de rechange impliquant des modifications au SGML produit et, conséquemment, à la DTD. Si le nombre de limitations rencontrées par les outils est très important, on décidera, afin de ne pas « corrompre » abusivement la source SGML, de produire des versions SGML transitoires.

Nous avons recours à une version SGML transitoire pour la production du PDF (une étape plus en aval de la chaîne qui sera expliquée plus loin). Cette version transitoire sert à réordonner et qualifier certains éléments de façon à accommoder certaines caractéristiques propres aux revues (par exemple, le fait de présenter les résumés à la toute fin de l'article plutôt qu'au début).

Pré-traitement

Figure 1

Mise en styles et préparation des textes. La chaîne de traitement proposée comporte une étape de pré-traitement des documents originaux. Cette étape consiste à appliquer un ensemble de styles, contenus dans un modèle de document (feuille de style), à un document original en format Word. L'utilisation de styles sur des parties de texte inscrit, dans le format natif du traitement de texte, des codes qui nous permettront d'automatiser le balisage en SGML.

C'est à cette étape que l'on insuffle une certaine «intelligence» au document. Ainsi, le modèle de document et les styles qu'il contient ne sont pas destinés à modifier l'apparence des documents, comme l'ont d'abord pensé les concepteurs de cette fonctionnalité, mais plutôt à identifier certaines parties des documents. Par exemple, nous chercherons à identifier les titres, les auteurs, les références bibliographiques, les résumés, etc. Il est important de comprendre que nous n'utiliserons pas les styles à des fins de mise en page, mais bien d'identification des différents composants du texte.

Outre l'application des styles, l'uniformisation et la normalisation des textes doivent être effectuées. Ainsi, les tableaux, les listes et les notes infra-paginales doivent avoir été produits avec les fonctionnalités appropriées du traitement de texte (en d'autres mots, que ce soient de vrais tableaux et non des chaînes de texte séparées par des tabulations, par exemple). Nous analysons, à l'étape de la programmation, l'ensemble des codes du traitement de texte : les liens entre les appels de notes et les notes, la largeur relative des colonnes des tableaux, l'alignement des contenus des cellules des tableaux, etc., et nous reproduisons cette information dans les documents SGML. Au besoin, certains composants doivent être réordonnés (par exemple, si l'auteur a ajouté son résumé à la fin, on devra le repiquer au début du document, à la suite des éléments de titres et d'auteurs, tel que le prévoit la DTD).

Nous avons développé un modèle de document pour chacune des revues. Ces modèles contiennent en moyenne de 30 à 50 styles différents en fonction du nombre de composants retrouvés. Parmi ces styles, certains sont de type paragraphe (blocs de texte) et d'autres de type caractère (chaînes de texte à l'intérieur des blocs).

L'étape de mise en styles pourra être réalisée par la personne responsable de la préparation des textes à publier, soit habituellement une personne faisant partie du comité de production de la revue. À cet effet, nous avons, dans le cadre du projet Érudit, entrepris de donner des séances de formation personnalisée aux responsables des revues, lesquelles portaient sur la préparation des documents et l'application des feuilles de styles.[ 4 ] Le lecteur trouvera en annexe une copie du document accompagnant cette formation. Notre expérience démontre que cette étape est plus facilement réalisable par des personnes maîtrisant bien leur outil de traitement de texte. Un certain contrôle de qualité doit être effectué sur les premiers documents stylés.

Une fois stylé, le document servira d'intrant (input) à l'étape de conversion SGML. C'est pourquoi il doit s'agir d'une version finale du texte, c'est-à-dire qu'il doit être complet et déjà comprendre toutes les corrections nécessaires. À cet effet, nous avons rencontré quelques problèmes puisque le traitement traditionnel des revues comporte une ou plusieurs étapes de correction d'épreuves une fois le document mis en page à l'aide d'un logiciel d'éditique (tel PageMaker ou QuarkXPress). Les corrections sont alors effectuées directement dans ces logiciels et ne sont pas repiquées dans la copie de traitement de texte initiale. Une copie d'exportation en format RTF (consistant en une représentation ASCII du format binaire de Word) peut habituellement être obtenue à partir de ces logiciels. Il s'agit cependant d'une copie incomplète puisque tout composant qui n'est pas à l'intérieur du flot principal de texte (tels légendes de figures et notes de bas de page) doit être ajouté un à un au texte principal. On perd également les liaisons dynamiques entre les notes et les appels de notes, de même que les fonctionnalités de tableaux lors de l'exportation. Bref, pour chaque revue, nous avons dû évaluer la somme de travail que représentait le repiquage des corrections dans la version Word versus celle que représentait le reformatage d'un document Word provenant d'un logiciel d'éditique. Dans les deux cas, cela a constitué une tâche supplémentaire, non prévue à l'origine, causée directement par la poursuite de deux systèmes parallèles de publication pendant la durée du projet pilote.

Notre système de traitement, préconise une utilisation de fonctionnalités appropriées du traitement de texte (styles, notes, tableaux, etc.). De plus, les corrections de nature textuelle (orthographe et syntaxe, de même que la plupart des corrections de nature typographique) doivent être faites dans le fichier de traitement de texte. Il faut prendre en considération le fait que ce fichier sert à la production de documents d'archivage, de documents dérivés (sommaires, tables des matières, listes de résultats de recherche, etc.) ainsi que de plusieurs formats de diffusion. Ce fichier source, de par son contenu et sa structure, doit donc être le plus achevé possible. Cela exige de la personne qui prépare les textes, de bonnes connaissances linguistiques et typographiques. Les erreurs révélées en aval dans la chaîne de production doivent être repiquées dans les fichiers de traitement de texte.

Galées électroniques. Depuis la fin du projet Érudit, nous avons testé l'intégration du processus de révision des épreuves dans la chaîne de traitement. Dans un processus plus traditionnel, cette révision se fait habituellement sur les épreuves papier des articles, une fois la mise en page effectuée à l'aide de logiciels d'éditique. Les corrections apportées peuvent être à la fois de nature orthographique, syntaxique, typographique, et peuvent aussi concerner des aspects du montage. La diffusion du même contenu sur plusieurs supports de diffusion nous amène à discerner en les corrections devant être repiquées dans le fichier initial de traitement de texte (de façon à ce que l'ensemble des formats de diffusion profitent de ces modifications), des corrections s'appliquant uniquement à la mise en page papier. Nous produisons donc maintenant des « galées électroniques »[ 5 ], c'est-à-dire des sorties papier obtenues à partir de FrameMaker+SGML sans avoir à effectuer d'importantes interventions manuelles au niveau du montage. Sur ces galées sont apportées les corrections se rapportant au texte (et non à sa mise en page en vue de l'imprimé), lesquelles seront ensuite être repiquées dans le fichier Word initial qui servira à la regénération des différents formats produits. Dans la perspective où plusieurs formats différents (SGML, HTML, PDF) sont produits à partir d'un même fichier initial, on comprendra l'intérêt d'effectuer un maximum de corrections en amont (donc dès la révision du fichier Word) et non en aval, sur un format en particulier plutôt qu'un autre.

Traitement des images. Les illustrations que peuvent comporter les articles parviennent habituellement aux responsables des revues sous différentes formes: photos, impressions laser, velox, etc. et plus rarement sous forme électronique : fichiers vectoriel ou bitmap provenant de logiciels graphiques et images numérisées (scans). Traditionnellement, ces images sont insérées dans le texte au moment du montage de la copie à imprimer par le typographe qui les numérise et les retouche, ou encore par le technicien de l'atelier de pré-impression qui les reproduit par procédé photographique.

L'intégration des images dans la chaîne de traitement Érudit est de beaucoup facilitée si ces documents nous parviennent en format numérique. Les images sont traitées comme des fichiers séparés qui sont référés à partir des documents.

Les secrétariats des revues n'étant habituellement pas équipés en matériel et savoir-faire pour manipuler des images, ce type d'intervention sera effectué par le fournisseur de service, en l'occurrence l'équipe d'Érudit. Cependant, les comités de revues devraient tenter d'obtenir des auteurs, autant que faire se peut, une version des images en format électronique. Ces images devraient toujours être de très bonne qualité (avec une haute résolution et, si possible, en couleur) afin de servir à l'archivage. C'est à partir des images de bonne qualité qu'on effectuera le traitement (surtout des modifications de formats de fichiers, des baisses de résolution, des sauvegardes en noir et blanc) en vue des différents modes de diffusion (archivage, Web et papier). Afin de standardiser le processus de traitement des images, nous avons établi des procédures normalisées.[ 6 ] Enfin, bien que cela ne se soit pas encore produit, un type d'intervention de même nature est à préconiser pour d'autres formats non textuels (vidéo, son, images 3D, etc.).

Nous avons exposé dans cette section les différents éléments portant sur le pré-traitement des textes, soit l'application des styles et le traitement des images. Une fois le document pré-traité, il est prêt à être converti en SGML.

HTML

Un principe de base de la philosophie SGML voulant que l'information, une fois balisée en SGML, puisse être réutilisée plusieurs fois et cela avec différentes saveurs, tant dans l'intégralité du contenu (en tout ou en parties) que dans la forme du contenant (dans un format particulier), il est tout naturel de convertir les fichiers SGML en fichiers HTML. Il s'agit en fait d'une conversion SGML (DTD PUM) vers SGML (DTD HTML). OmniMark s'est présenté comme l'outil tout désigné pour ce type de conversion d'autant plus qu'à cette étape du processus, nous étions beaucoup plus familiers avec son langage de programmation. Ainsi, les articles sont convertis automatiquement en HTML. Nous produisons, de la même façon, une table des matières pour chaque numéro de revue. Cette table des matières ne provient pas d'un document initial unique saisi sous forme de table des matières, mais plutôt de la concaténation d'informations récupérées dans l'ensemble des articles (titres, sous-titres, auteurs) en format SGML. C'est un bon exemple de réutilisation de l'information.

Puisque l'ensemble des documents produits sont basés sur la DTD PUM, la conversion du SGML vers le HTML est réalisée par un seul programme de conversion pour l'ensemble des revues. Ce programme comporte cependant quelques particularités de présentation propres à chaque revue, et d'une telle pratique résulte une apparence assez semblable pour chacune des revues. La fabrication d'une signature, d'une maquette complètement différente pour chaque revue est maintenant réalisée à l'aide des CSS (Cascading Style Sheet), fonction de plus en plus supportée par les navigateurs Web.

La version SGML comportant explicitement des indications sur les liens entre les appels de notes et les notes, entre les citations et les références bibliographiques, et entre les appels de tableaux et figures et les tableaux et figures eux-mêmes, nous avons traduit ces caractéristiques en liens hypertextuels dans la version HTML afin de procurer plus d'aisance de navigation à l'intérieur du document. Nous avons également implanté un mode de référence aux images à partir d'images « timbre-poste » qui en révèlent un aperçu. Le lecteur peut alors décider de télécharger l'image plein format en cliquant sur l'aperçu. Ceci évite d'avoir des articles (fichiers) trop gros, donc trop longs à télécharger.

Pour l'instant nous stockons sur notre serveur Web la version HTML préconvertie. Cependant, la conversion, tant pour les articles que pour la table des matières, pourrait aisément être faite « à la volée » (on the fly) puisqu'il n'y a aucune intervention manuelle sur les fichiers HTML. Dans un mode d'accès client/serveur, on pourrait facilement faire en sorte que l'utilisateur, par le biais son client Web, fait la demande d'un fichier HTML (par exemple un article donné) et qu'alors seulement le serveur (sur lequel est installé OmniMark) convertit, au moment de la demande, le fichier SGML en HTML. Ceci aurait pour avantage d'occuper moins d'espace disque (environ la moitié de moins, puisque seule la version SGML serait stockée). Il faudrait cependant tester les délais de réponses.

SGML

Les utilisateurs peuvent visionner les documents SGML à l'aide de Panorama Viewer de Interleaf[ 11 ], un navigateur SGML qui s'installe comme module externe (plug-in) d'un navigateur Web, tel Netscape.

Panorama Viewer permet de créer des liens entre différentes parties des documents ou différents documents. Il permet également de présenter des tables des matières dynamiques qui constituent des aides à la navigation. Une autre fonction de Panorama offre la possibilité d'annoter n'importe quelle partie d'un document, y compris une zone d'une figure déterminée par le lecteur. Enfin, il permet d'ajouter des signets dans un document.

Pour le centre de services, la diffusion des articles en format SGML requiert peu d'efforts puisqu'il s'agit du format natif des documents. Pour être plus exacts, nous diffusons une version SGML à peine différente de la version produite lors de l'effort de conversion enrichie décrite précédemment. Cette différence minime tient exclusivement à la non-reconnaissance, par le navigateur SGML, de certains caractères étrangers et symboles particuliers. Panorama Viewer étant en mesure de lire du SGML, il faut simplement lui indiquer la mise en forme propre aux différents éléments rencontrés. Ces instructions de formatage sont données sous la forme d'une feuille de style. La création d'une feuille de style ne s'effectue normalement qu'une seule fois par revue (voire même par DTD utilisée si on désire des produits normalisés et identiques). Ainsi nous avons créé des feuilles de style et des formats de tables des matières dynamiques (navigators) pour chaque revue, de manière à donner à chacune une signature caractéristique.

PDF

L'intérêt du PDF réside dans l'obtention d'un document électronique arborant un format de présentation semblable à l'imprimé. Un tel format permet aux lecteurs d'imprimer une version «mise en page papier» des articles diffusés en ligne. Les navigateurs SGML ou HTML dont nous avons discutés précédemment permettent également l'impression, mais la qualité de la mise en page n'est pas aussi complexe et soignée puisque les feuilles de style des navigateurs Web sont destinées avant tout à la présentation à l'écran.

La grande majorité des logiciels d'éditique (desktop publishing) sur le marché (les plus connus étant PageMaker et QuarkExpress) permettent une sauvegarde en format PDF pour diffusion sur le Web. Ces logiciels ne sont cependant pas en mesure de lire en intrant (input) un fichier SGML et l'interpréter correctement. Il existe toutefois des outils performants capables à la fois de prendre en intrant du SGML et de permettre une mise en page professionnelle (FrameMaker+SGML[ 12 ] de Adobe, Interleaf 6 SGML[ 13 ] de la compagnie Interleaf, et ADEPT Publisher[ 14 ] réalisé par ArborText). Il s'agit toutefois de produits dispendieux et assez complexes à manipuler.

Notre choix s'est arrêté sur le logiciel FrameMaker+SGML en raison de son coût abordable et de sa plus grande facilité de paramétrage. FrameMaker+SGML permet la création, la modification et la publication de documents SGML dans un environnement convivial. Dans le cadre du projet Érudit, nous utilisons uniquement les fonctionnalités d'importation du SGML et de mise en page sophistiquée offertes par l'outil. Il s'agit, ici aussi, de définir un mécanisme d'application de style pour chaque élément en fonction de son contexte SGML. Cette feuille de style est dirigée vers la mise en page sur papier (et non à l'écran) et, à cet effet, FrameMaker+SGML offre la possibilité de paramétrer plusieurs des caractéristiques requises par l'imprimé (par exemple, la gestion des veuves et orphelins, paragraphes solidaires, multi-colonnes, notes en bas de page, patron de césure à la fin des lignes, forme des en-têtes et bas de pages, etc.).

Chaque revue possède une feuille de style différente, laquelle a été conçue en se basant sur la maquette de la forme imprimée des revues participantes. Les fonctionnalités de FrameMaker+SGML nous permettent sans difficulté de reproduire de façon presque identique l'aspect habituel des revues. L'application d'une feuille de style exhaustive et bien conçue (qu'on arrive généralement à obtenir après un processus de réajustement lors des premières productions) permet d'automatiser à 90 % le montage du document, ce qui constitue un excellent rendement. On doit toutefois faire certaines interventions manuellement afin de compléter le travail (par exemple, déplacement des figures, condenser de l'espacement du texte ça et là pour forcer un saut de page, fractionner des notes de bas de page trop longues, etc).

Une fois le document monté avec FrameMaker+SGML, il ne reste qu'à produire une version PDF à l'aide du logiciel Acrobat de Adobe. Il s'agit là d'une opération sans grande difficulté qu'on peut apparenter à un simple « sauvegarder sous PDF ». On peut ainsi produire un premier fichier PDF de basse résolution, destiné à être visionné sur le Web, et un second fichier PDF de meilleure résolution, celui-ci destiné à être acheminé à l'atelier de pré-impression en vue de l'impression des exemplaires papier.

Pour les usagers, la consultation des documents PDF se fait avec le logiciel Acrobat Reader, qui existe comme module externe (plug-in) pour les navigateurs Web. On peut consulter les documents PDF à l'écran avec ce logiciel, mais ils sont plutôt destinés à être imprimés.

Dans le cadre du projet Érudit nous avons exclusivement produit des documents PDF pour le Web, à raison d'un fichier unique par article (et non d'un fichier regroupant tout un numéro d'une revue), puisque les revues poursuivaient pendant la même période, le traitement habituel pour la production de la version papier de la revue.

Diffusion sur un serveur Web

Pour diffuser des documents sur le Web, nous avons créé un site Web[ 15 ] qui est hébergé sur notre serveur Web. Ce site est la porte d'entrée principale pour l'accès aux articles. Techniquement ceci a demandé l'installation d'un serveur (Sun), le paramétrage du système d'exploitation, l'installation de logiciels serveurs et la mise en place d'une procédure de sauvegarde des données du site.

Outil de recherche

La diffusion en ligne (et également sur cédérom) permet, pour le lecteur, d'accéder aux textes à l'aide d'un outil de recherche. Pour ce faire, on doit implanter un outil de recherche en texte intégral qui peut indexer des documents SGML, tout en conservant l'information sur la structure, de façon à permettre aux usagers d'exprimer des contraintes sur la structure dans leurs requêtes. On peut, par exemple, préciser la recherche de textes comportant le nom d'un chercheur mais uniquement lorsque celui-ci se retrouve dans une bibliographie et non en tant qu'auteur de l'article. Dans le cadre du projet Érudit, nous avons installé, sur le site Web, un prototype de moteur de recherche qui doit encore être amélioré. Il s'agit de Harvest[ 16 ]. La collection indexée comprend l'ensemble des articles ayant été publiés par les revues pendant la durée du projet pilote. Il s'agit d'un mode d'accès au texte très performant que seule la version électronique permet d'obtenir.