modélisation du texte numérique multilingue : vers des modèles

MODÉLISATION DU TEXTE NUMÉRIQUE MULTILINGUE :
VERS DES MODÈLES GÉNÉRAUX ET EXTENSIBLES
FONDÉS SUR LE CONCEPT DE TEXTÈME
GÁBOR BELLA
TELECOM BRETAGNE,
JUIN
2008
RÉSUMÉ
Cette thèse s’intéresse aux modèles de texte numériques, plus précisément
à la définition même des éléments textuels atomiques et à la manière dont
le texte se compose à partir de ceux-ci. En réponse aux besoins d’internationalisation des systèmes informatiques, les modèles de texte historiques, basés
sur l’idée de la table de codage, ont été enrichis par des connaissances semiformelles liées aux systèmes d’écriture, connaissances qui sont désormais essentielles pour l’exécution de la moindre opération textuelle. Ainsi sont nés le
codage de caractères Unicode et les formats de fonte dits « intelligents ».
Par la réalisation que cet enrichissement ne représente que le début d’une
convergence vers des modèles fondés sur des principes de la représentation
des connaissances, nous proposons une approche alternative à la modélisation de texte, selon laquelle l’élément textuel se définit non comme une entrée d’une table mais par les propriétés qui le décrivent. Le formalisme que
nous établissons — initialement développé dans le cadre de la représentation des connaissances — nous fournit une méthodologie pour définir, pour la
première fois de manière précise, des notions telles que caractère, glyphe ou
usage, mais aussi de concevoir l’élément textuel généralisé que nous appelons
textème et qui devient l’atome d’une famille de nouveaux modèles de texte.
L’étude de ces modèles nous amène ensuite à comprendre et à formaliser, du
moins en partie, des phénomènes tels que la contextualité ou la dépendance
entre éléments textuels, phénomènes qui sont également présents, même si
parfois de manière cachée, dans les modèles actuels. Dans la thèse nous analysons également les enjeux liés à l’implémentation des modèles proposés.
MOTS CLÉS : modèle de texte, représentation des connaissances, Unicode,
document numérique, typographie
ABSTRACT
This thesis is concerned with the modelling of electronic text. This modelling involves the definition both of the atomic text elements and of the
way these elements join together to form textual structures. In response to
the growing need for internationalisation of information systems, historical
models of text, based on the concept of code tables, have been extended
by semi-formalised knowledge related to the writing system so that, by now,
such knowledge is essential to text processing of even the simplest kind. Thus
were born the Unicode character encoding and the so-called ‘intelligent’ font
formats.
Realising that this phenomenon marks only the beginning of a convergence towards models based on the principles of knowledge representation,
we here propose an alternative approach to text modelling that defines a text
element not as a table entry but through the properties that describe the element. The formal framework that we establish, initially developed for the
purposes of knowledge representation, provides us with a method by which
precise formal definitions can be given to much-used but ill-defined notions
such as character, glyph, or usage. The same framework allows us to define a
generalised text element that we call a texteme, the atomic element on which
a whole family of new text models is based.
The study of these models then leads us to the understanding and formalising, at least partially, of phenomena such as contextuality and dependency
between text elements; such phenomena are also present, although sometimes
in a hidden way, in current text models. This thesis also examines implementational issues related to the proposed text models.
KEYWORDS: text model, knowledge representation, Unicode, electronic document, typography
REMERCIEMENTS
En premier, j’exprime ma gratitude envers John Plaice et Chris Rowley pour
avoir accepté d’être rapporteurs de ma thèse, compte tenu de l’effort considérable qu’ils doivent entreprendre pour arriver jusqu’à Brest depuis l’Australie
et le Royaume-Uni pour participer au jury de ma soutenance. Je remercie également Isabelle Garron et Jacques André pour avoir accepté d’être membres
de mon jury.
Parmi les personnes avec qui j’ai eu l’honneur de travailler pendant la préparation de ma thèse, je tiens à tout d’abord mentionner Yannis Haralambous :
c’est lui qui m’a incité à m’essayer à la recherche scientifique et qui m’a initié
à la typographie numérique — dont sa maîtrise est inégalée. Je lui dois ma
gratitude pour m’avoir fait confiance dès le début et tout au long de ma thèse.
Yannis est à l’origine de plusieurs idées importantes dans mon travail, et il a
contribué à bien d’autres à travers des discussions enrichissantes (et longues),
des emails nocturnes, etc. : sa patience et son esprit pédagogique doivent aussi
être applaudis.
J’exprime également ma gratitude envers Ioannis Kanellos, mon directeur
de thèse qui, avec sa « main invisible », n’a cessé de guider mon travail de
recherche dans la bonne direction. Avant tout, il m’a montré l’importance
de prendre du recul par rapport à mon travail, de savoir reconnaître le motif
général derrière les problèmes particuliers, de voir la forêt à travers les arbres.
Grâce à ses critiques constructives et à son attitude encourageante, j’ai pu
améliorer ma thèse considérablement.
Je tiens à remercier Serge Garlatti, directeur d’études au département Informatique de TELECOM Bretagne, de m’avoir apporté des éclaircissements
essentiels au sujet des ontologies, et de m’avoir suggéré quelques idées excellentes qui ont fini par trouver leur chemin dans ce manuscrit.
Sur un plan non-scientifique, Annie Gravey, chef du département Informatique, m’a donné énormément d’aide au long de ma thèse, aussi bien financièrement que personnellement ; je serais heureux d’être dirigé, dans l’avenir,
par des chefs avec les mêmes qualités humaines.
Je dois également mentionner Agnès Letourneur du service FC, que je remercie pour quatre ans de collaboration agréable, ainsi que pour sa confiance
et pour son soutien qui ont été importants pour le financement de ma thèse.
Sur le plan personnel, ma gratitude la plus grande appartient à mes chers
parents. Sans leur support inconditionnel, je n’aurais pu aller jusqu’au bout
cette thèse, ni faire durer mon séjour en France pendant toutes ces années.
pour m’avoir donné la joie de vivre, à tous mes amis dont
Merci à
l’amitié m’était si importante, et aussi à mes camarades doctorants au département et à l’école avec qui j’ai partagé tant de repas, de cafés et de discussions.
Je dédie cette thèse à la mémoire de mon cousin, Bella Péter.
Brest, 23 janvier 2008.
TABLE
DES MATIÈRES
INTRODUCTION
11
1 MODÈLES DE TEXTE
1.1 Concepts de base . . . . . . . . . . . . . . . . . . . . . .
1.2 L’origine de l’écrit et son développement . . . . . . . . .
1.3 L’écrit imprimé . . . . . . . . . . . . . . . . . . . . . . .
1.4 Les premiers modèles informatiques de l’écrit . . . . . . .
1.4.1 Les notions de caractère et de codage . . . . . . .
1.4.2 Une tentative de formalisation de la notion
de caractère et du texte informatique . . . . . . .
1.4.3 L’extensionnalité de la définition précédente . . .
1.4.4 Les premiers modèles visuels . . . . . . . . . . . .
1.5 L’évolution de la fonte ou l’émancipation du glyphe . . .
1.5.1 TEX . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2 Le langage et les fontes PostScript,
la notion de nommage de glyphes . . . . . . . . .
1.6 L’aspect multilingue du texte informatique . . . . . . . . .
1.6.1 Codages de caractères nationaux . . . . . . . . . .
1.6.2 Typographie et traitement des écritures
non-alphabétiques . . . . . . . . . . . . . . . . .
1.7 Le document interactif et le Web . . . . . . . . . . . . . .
1.7.1 Le format de document RTF . . . . . . . . . . . .
1.7.2 HTML et le Web . . . . . . . . . . . . . . . . . .
1.7.3 PDF . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.4 SVG . . . . . . . . . . . . . . . . . . . . . . . . .
1.8 Le codage de caractères Unicode . . . . . . . . . . . . .
1.8.1 Les problèmes ayant mené à la création d’Unicode
1.8.2 Les principes fondamentaux d’Unicode . . . . . .
1.8.3 Universalité . . . . . . . . . . . . . . . . . . . . .
1.8.4 Caractères et non glyphes . . . . . . . . . . . . .
1.8.5 Cohérence théorique contre usages pratiques . . .
1.8.6 La base de données d’Unicode . . . . . . . . . . .
1.8.7 Une tentative de renforcement théorique :
le rapport technique ISO/IEC TR 15285:1998 . . .
1.8.8 Le principe (ou le mythe) de texte brut . . . . . . .
1.8.9 Résumé des problèmes théoriques
liés aux principes d’Unicode . . . . . . . . . . . .
1.9 La notion de « propriété »
dans les formats de fonte intelligents . . . . . . . . . . . .
1.9.1 Le modèle de texte commun aux différents formats
intelligents . . . . . . . . . . . . . . . . . . . . . .
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
18
20
23
24
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
28
29
30
31
. . . 38
. . . 43
. . . 44
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
47
52
53
53
54
56
58
58
59
59
60
66
68
. . . 70
. . . 73
. . . 78
. . . 80
. . . 81
1.9.2 Propriétés dans les différents formats de fonte
et plates-formes de composition . . . . . . . . . . . . . 84
1.9.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 87
1.10 Synthèse : l’évolution de la modélisation du texte informatique 88
2 PROPOSITION D’UN CADRE DE MODÉLISATION DE TEXTE INTENSIONNEL 91
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.1.1 Les notions de concept, de propriété, d’extension
et d’intension selon Frege et Russell . . . . . . . . . . . 93
2.1.2 Modèles cognitifs basés sur la notion de « théorie » . . . 95
2.2 Application de la représentation des connaissances
à la modélisation textuelle . . . . . . . . . . . . . . . . . . . . 99
2.2.1 Les propriétés : éléments de T1 . . . . . . . . . . . . . . 100
2.2.2 Les clés de propriété : éléments de T2 . . . . . . . . . . 101
2.2.3 Les catégories de clés : éléments de T3 . . . . . . . . . 102
2.2.4 Le caractère Unicode, le glyphe et le signe
typographique en tant qu’éléments de T3 . . . . . . . . 105
2.3 Le textème : élément textuel généralisé . . . . . . . . . . . . . 106
2.3.1 Définition formelle du textème . . . . . . . . . . . . . . 108
2.4 Conséquences du modèle . . . . . . . . . . . . . . . . . . . . 109
2.4.1 L’intensionnalité de l’ensemble des propriétés . . . . . . 109
2.4.2 L’œuf et la poule : la clé et la valeur de propriété,
sont-elles également du texte ? . . . . . . . . . . . . . . 110
2.4.3 Changements d’usage . . . . . . . . . . . . . . . . . . . 111
2.4.4 Relations entre propriétés et textèmes
dérivées de leurs extensions et intensions . . . . . . . . 111
2.4.5 La structure du texte en textèmes . . . . . . . . . . . . . 114
2.4.6 Pertinence vis-à-vis des écritures du monde . . . . . . . 115
2.4.7 Le textème permet l’invention d’usages novateurs . . . . 120
2.5 Le rôle du contexte
dans la représentation textuelle . . . . . . . . . . . . . . . . . . 128
2.5.1 Les différents aspects contextuels
du texte numérique . . . . . . . . . . . . . . . . . . . . 129
2.5.2 Le contexte macroscopique . . . . . . . . . . . . . . . 130
2.6 Le contexte d’usage . . . . . . . . . . . . . . . . . . . . . . . . 134
2.6.1 Le changement de contexte d’usage . . . . . . . . . . . 137
2.6.2 Changements d’unité pertinente . . . . . . . . . . . . . 139
2.6.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 144
2.7 Dépendances au sein du texte en textèmes . . . . . . . . . . . 145
2.7.1 Quelques exemples de dépendances . . . . . . . . . . 145
2.7.2 Dépendances dans les modèles de texte
d’Unicode et de M-text . . . . . . . . . . . . . . . . . . 147
2.7.3 Dépendances et représentation des connaissances . . . 148
2.7.4 Quelques questions fondamentales . . . . . . . . . . . 149
2.7.5 Définitions et analyse théorique de la notion
de dépendance . . . . . . . . . . . . . . . . . . . . . . 150
2.7.6 La dépendance algorithmique doit trouver
sa place dans le cadre formel de modélisation . . . . . 156
8
2.7.7 La gestion des dépendances . . . . . . . . . . . . . . . 159
2.7.8 Méthodes pratiques de gestion de dépendances . . . . 162
2.7.9 Synthèse de l’analyse des dépendances et des solutions
proposées . . . . . . . . . . . . . . . . . . . . . . . . . 167
3 RÉALISATIONS INFORMATIQUES DE MODÈLES DE TEXTE EN TEXTÈMES
3.1 L’applicabilité du modèle aux systèmes existants . . . . . . . .
3.2 Implémentation du modèle de textèmes dans le logiciel Ω2 . .
3.2.1 Le nœud de textème dans Ω2 . . . . . . . . . . . . . .
3.2.2 La gestion des dépendances dans Ω2 . . . . . . . . . .
3.2.3 Modules et textèmes . . . . . . . . . . . . . . . . . . .
3.2.4 Textèmes dans la sortie d’Ω2 . . . . . . . . . . . . . . .
3.2.5 Optimisations de la gestion des textèmes dans Ω2 . . .
3.3 Documents en textèmes . . . . . . . . . . . . . . . . . . . . .
3.3.1 Un cadre de normalisation des propriétés
à travers une description basée sur RDF et OWL . . . .
3.3.2 Optimisations au sein des documents en textèmes . . .
3.4 Le modèle de textèmes en tant que modèle de texte générique .
3.4.1 Opérations élémentaires de manipulation de texte . . .
3.4.2 La compatibilité de la chaîne de textèmes et de la chaîne
de caractères . . . . . . . . . . . . . . . . . . . . . . .
3.4.3 Un codage de signes intensionnel
à la base du modèle de texte générique . . . . . . . . .
3.4.4 Utilisation du codage de signes
avec le modèle de texte en textèmes . . . . . . . . . . .
3.4.5 Relations de composition entre signes . . . . . . . . . .
3.4.6 Structures de données et optimisations
dans l’implémentation d’un modèle de texte générique
3.4.7 Calcul de l’extension commune d’un textème . . . . . .
3.4.8 Calcul de l’égalité et de la dépendance
extensionnelles entre textèmes et signes . . . . . . . . .
3.4.9 Recherche de relations de spécialisation
ou de généralisation entre un textème donné
et les éléments du codage de signes . . . . . . . . . . .
3.4.10 Conclusions sur l’utilisabilité pratique
d’un codage de signes intensionnel . . . . . . . . . . .
169
170
171
172
173
173
174
174
176
4 CONCLUSIONS ET PERSPECTIVES
4.1 Résumé des résultats . . . . . . . . . . . . . . . . . . . . . . .
4.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Perspectives d’usage et d’évolution pour les modèles de texte
intensionnels . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Les aspects interface homme-machine
des modèles de texte en textèmes . . . . . . . . . . . .
4.3.2 Modèle de texte intensionnels sans textèmes . . . . . .
215
215
219
BIBLIOGRAPHIE
225
A LISTE
231
DE PUBLICATIONS
9
177
183
188
189
191
200
203
205
205
208
209
211
213
222
222
224
10
INTRODUCTION
Le sujet de cette thèse est la modélisation informatique de données textuelles.
Le mot texte, dans son sens général, n’est pas un terme précis : il peut tout
autant désigner le contenu d’un livre qu’un seul mot, une lettre manuscrite,
un document numérique, etc. Les propriétés qui caractérisent ces différentes
formes de l’écrit (le support, les propriétés graphiques, le système d’écriture,
la longueur, etc.) sont, bien entendu, tout aussi variées. Dans cette thèse, nous
chercherons à établir notre définition du texte autour d’une de ses propriétés
invariantes, à savoir qu’il s’agit, dans une première approximation, d’une suite
de signes élémentaires.
Par modélisation nous entendons la conceptualisation de certains aspects
de l’écrit dans le but de mise en œuvre à travers une technologie particulière. L’acte de modélisation consiste tout d’abord à choisir parmi les propriétés qui peuvent caractériser une écriture celles qui sont pertinentes par rapport
à l’usage ou aux usages visé(s) par le modèle. L’étape suivante est celle de la
conceptualisation — nous aurions pu également employer les termes formalisation ou abstraction — des propriétés choisies, afin d’établir les éléments
constitutifs et les structures de base du modèle. Ces éléments et structures
conceptuels sont ensuite réalisés par l’intermédiaire d’une technologie donnée, compte tenu de contraintes matérielles et d’ingénierie.
Il serait cependant illusoire, justement à cause des contraintes mentionnées, d’imaginer la modélisation comme un processus linéaire. Les limitations technologiques ont, hélas, un effet déterminant sur la conceptualisation
d’éléments et de structures et limitent également les usages possibles du modèle à construire. En effet, dans l’histoire, l’invention de nouveaux modèles et
concepts est souvent indissociable des avancées technologiques qui ouvrent
la voie à leur mise en œuvre. L’exemple le plus classique de la modélisation
de l’écrit est sans doute celui qui découle de l’invention de l’imprimerie de
Gutenberg. L’usage que Gutenberg visait était la reproduction des ouvrages
religieux calligraphiés de son époque, avec la plus grande fidélité possible. Le
choix des éléments conceptuels de son modèle — que l’on appelle aujourd’hui glyphes — était par conséquent subordonné à l’atteinte de son objectif,
un usage à forte orientation visuelle (cf. l’illustration en page 22). Cependant,
la conception du modèle ne peut très probablement pas être dissociée du
perfectionnement de certaines techniques de ciselure, d’alliage de métaux et
de composition de nouveaux types d’encres, dont la maîtrise par Gutenberg
était non seulement nécessaire pour la mise à point de la machinerie qu’il a
inventée, mais peut-être aussi le catalyseur de ses idées initiales.
Le modèle qui découle des travaux de Gutenberg — et qui a subi un développement continuel à travers les siècles qui ont suivi son invention — a
eu une profonde influence sur l’évolution de la société occidentale toute en11
tière. Cette influence, qui ne peut être surestimée, a été mise en évidence par
de nombreux auteurs, dont le plus connu est sans doute Marshall McLuhan
[47]. En parallèle, les nouveaux usages et technologies de création et de transmission de texte (le télégraphe, la machine à écrire, etc.) ont fait apparaître
de nouveaux modèles, où l’on observe toujours et encore la détermination
mutuelle entre modèle abstrait et technologie de réalisation.
Quant à l’ordinateur, il n’a pas fallu longtemps avant que le traitement
de l’information textuelle ne devienne une de ses tâches principales. Tout au
long de son évolution en puissance, les usages de l’ordinateur n’ont cessé de
se multiplier et de se diversifier, y compris les usages textuels. Les premiers
codages de caractères à six ou sept bits des années 1950 et 1960 — qui représentent également une modélisation particulière de l’écrit, notamment celle
basée sur la table de codage qui n’est autre qu’une simple énumération d’éléments textuels atomiques identifiés par des codes numériques — ont augmenté
en taille (à huit bits et au-delà) et se sont diversifiés au fil des années.
Cependant, à partir de la fin des années 1980, le développement des exigences vis-à-vis de la représentation numérique du texte — les exigences visuelles induites par la PAO, le multilinguisme induit par l’internationalisation
ou l’interactivité induite par l’échange de documents, notamment à travers
Internet — ont atteint un point où une évolution purement quantitative du modèle n’était plus suffisante. Pour la première fois dans l’histoire, on a tenté de
créer un nouveau modèle de texte qui soit universel, c’est-à-dire qui couvre
la totalité des écritures du monde. La diversité de celles-ci était cependant si
importante que la recherche d’un modèle commun n’était pas possible sans
davantage de réflexion analytique, sans se demander ce que l’on entend, enfin,
par écriture ou caractère ?
Le résultat de ces réflexions, mais aussi de nombreux compromis, a été le
codage de caractères Unicode et un modèle de texte à deux strates que nous
appellerons caractère-glyphe, où le choix entre caractère ou glyphe comme
unité textuelle de base est fait selon l’usage du texte en question : l’échange,
la manipulation interne et le stockage d’un texte supposent le plus souvent
que celui-ci est représenté sous la forme de chaînes de caractères, alors que
l’affichage du texte s’effectue à travers un modèle visuel dont l’unité textuelle
n’est pas le caractère mais l’image de celui-ci, le glyphe.
À part les tendances unificatrices d’Unicode et l’augmentation drastique
du nombre des écritures qu’il couvre, la particularité qui distingue ce codage
de ses prédécesseurs est avant tout sa tentative de construire son répertoire de
caractères selon un ensemble de critères fondés sur des considérations théoriques. On observe ainsi une transition depuis une approche descriptive dite
extensionnelle qui définit l’ensemble à travers l’énumération de ses éléments
(est « caractère » toute entrée de la table de tel ou tel codage), vers une approche intensionnelle qui, au contraire, décrit l’ensemble et ses éléments par
leurs propriétés.
En réalité, l’émergence d’une telle approche était inévitable car il n’aurait
pas été possible de faire face à l’explosion du nombre de caractères répertoriés sans recourir à un principe organisateur plus évolué. D’ailleurs, il s’agit
d’un phénomène courant : dès que le segment du « monde réel » que l’on
vise à décrire atteint une certaine taille critique, l’adoption de structures or12
ganisatrices plus complexes semble devenir incontournable. Or, la représentation des connaissances est justement un domaine scientifique directement
concerné par l’étude de différentes structures abstraites appliquées à l’organisation de données brutes décrivant le monde.
Un des premiers résultats de cette thèse est la mise en évidence du fait que
le modèle de texte d’Unicode, avec ses fondements théoriques et sa base de
données, ne représente qu’une transition, un premier pas plus ou moins inconscient vers une nouvelle génération de modèles qui épousent inévitablement certaines approches de la représentation des connaissances. Car, bien
qu’Unicode introduise la notion de propriété de caractère et sa propre base
de données de propriétés, cette dernière est construite de manière ad hoc et
ne couvre en réalité qu’un nombre très restreint d’usages. Il s’ensuit que l’approche extensionnelle — la table de codage et le code numérique — reste le
mode d’accès primaire et le moyen unique d’identification des caractères Unicode. Notons encore que le codage est à peine extensible ou modifiable, non
seulement à cause de la lourdeur du processus de normalisation mais aussi par
sa conception même. Finalement, la catégorisation bipolaire des signes d’écriture entre caractères et glyphes s’avère être non-intuitive, ambiguë et parfois
même insuffisante.
En général, les qualités et les défauts d’un modèle donné peuvent être évalués de nombreux points de vue. Un scientifique peut s’intéresser à ses mérites
conceptuels, alors qu’un ingénieur raisonnera plutôt en termes de potentiel
de réalisation et d’une suffisance qualitative souvent évaluée de façon subjective : même si un modèle n’est pas parfait — aucun modèle ne peut l’être —,
est-il « assez bon » pour résoudre les problèmes pratiques jugés les plus importants ? De nouveau, c’est l’interaction de considérations conceptuelles et de
contraintes matérielles qui mène le processus de modélisation vers une synthèse supposée acceptable. Dans cette thèse, nous tenons compte des mêmes
considérations lorsque nous évaluons les mérites et les lacunes d’Unicode et
du modèle de texte caractère-glyphe, en les comparant à d’autres solutions
potentielles.
En procédant ainsi, il ne faut cependant oublier que la problématique de
la modélisation de l’écrit est loin d’être une question purement technique. De
même qu’il est aujourd’hui accepté que l’invention de Gutenberg a révolutionné la société toute entière à partir du XVe siècle, il ne relève pas de l’exagération de supposer que les formes de communication numériques modernes
doivent exercer une influence tout aussi importante sur la société contemporaine, même si les manifestations concrètes de cette influence restent encore
à débattre. Or, malgré une popularité toujours grandissante de la communication audiovisuelle, ce qui a suggéré à McLuhan la vision d’un retour de la
société moderne vers l’expérience « audio-tactile », l’écrit en tant que médium
n’est pas, pour autant, en train de perdre son importance. La majorité écrasante de l’information disponible sur Internet reste textuelle, non seulement
au niveau inférieur des formats de documents tel que HTML mais également
dans le sens où l’usage primaire d’Internet reste, toujours et malgré tout, la lecture. Il s’ensuit que dans un monde où le mot « information » devient de plus
en plus synonyme d’« information numérisée » et le mot « existence » (d’un article, d’une information, voire d’une personne) synonyme de « présence sur le
13
Web »1 , les modèles de texte ont un impact profond sur l’exploitation et la production de l’information écrite. Leur tendance à représenter certains aspects
de la communication écrite au détriment d’autres, à favoriser certains usages
textuels et en défavoriser, voire même exclure d’autres, est extrêmement déterminante aussi bien dans le contexte de la numérisation du patrimoine écrit
— la galaxie de Gutenberg — que pour les textes qui restent à être créés. Les
limitations d’un médium donné influent forcément sur le contenu, la structure
ou encore la présentantion de l’information que le médium est censé transmettre.
En réponse à ces motivations, nous proposons et examinons dans cette
thèse un cadre nouveau de création de modèles de texte. Ce cadre est fondé
sur l’idée d’un procédé intensionnel de définition des éléments textuels : ceuxci sont décrits non pas comme entrées d’un répertoire mais comme des ensembles de propriétés. Inspirés de certaines notions et résultats de la représentation des connaissances, nous essayons dans cette thèse de découvrir les
rapprochements potentiels entre ce domaine et celui de la modélisation de
texte, ce dernier étant jusqu’à maintenant dominé presque exclusivement par
des approches ad hoc d’ingénierie à orientation pragmatique. Le cadre formel qui résulte de nos considérations tente de rompre avec cette attitude en
faveur d’une approche plus théorique, en fournissant tout d’abord une méthodologie pour donner enfin une formalisation adéquate de notions telles que
caractère, glyphe, propriété ou contexte d’usage, jusqu’alors définies de manière approximative et informelle. D’autre part, le même cadre formel nous
permet d’unifier caractère et glyphe sous un même concept : l’unité textuelle
généralisée que nous appelons textème.
Tout au long de la thèse, nous avons veillé à maintenir une attitude cohérente vis-à-vis de l’acte de modélisation, en séparant la conception du cadre
formel théorique de celle des réalisations pratiques. Le rôle du premier est
d’introduire une méthode rigoureuse et puissante de définition de modèles de
texte, basée sur une approche intensionnelle. La complexité qu’entraîne inévitablement cette puissance ne fait, bien entendu, que refléter la complexité
des phénomènes que le système est censé décrire. Ce n’est pas au cadre formel mais aux réalisations pratiques, c’est-à-dire aux modèles de texte actuels,
d’apporter des simplifications éventuelles, en s’adaptant aux besoins et aux
contraintes technologiques.
C’est dans cette considération que nous avons choisi de développer ces
deux aspects séparément dans le texte de la thèse afin de maintenir la clarté
de nos propos. Un chapitre est consacré au fondement et à l’analyse de la théorie du cadre de modélisation proposé, alors que les diverses formes possibles
d’implémentation sont traitées dans un chapitre à part. Cette séparation nette
nous permet d’éviter les basculements constants entre les approches scientifique et d’ingénierie qui auraient produit un discours incohérent et difficile à
suivre.
La structure de la thèse se présente donc de la façon suivante : le premier
chapitre est consacré à un examen critique et détaillé des modèles de texte
informatiques du passé et du présent, avec un accent important sur le modèle
caractère-glyphe, le codage Unicode et les formats de fonte dits intelligents,
1
Voire : présence parmi les résultats rendus par notre moteur de recherche préféré...
14
car il s’agit de véritables normes de représentation textuelle d’aujourd’hui et
des années à venir. Si nous consacrons à ce chapitre une partie considérable
de la thèse, ce n’est pas simplement pour établir un état de l’art, mais plutôt dans le but de fournir une analyse détaillée des modèles actuels à travers
la synthèse de certaines critiques déjà formulées à leur égard par d’autres
auteurs (notamment Yannis Haralambous, cf. [31] et [27]) avec quelques éléments de recherche originale. Il s’agit également de montrer que ces modèles
sont loin d’être inévitables ; au contraire, ils ne représentent qu’une voie de
développement particulière parmi d’autres possibles. De plus, certaines technologies présentées dans ce chapitre (comme le format de document PDF ou
le fonctionnement interne du logiciel TEX) nous serviront comme référence
pour certains développements dans les chapitres ultérieurs.
Le deuxième chapitre introduit un cadre formel de représentation des
connaissances qui sert ensuite à définir le concept de textème et à construire
les nouveaux modèles de texte dont il devient l’unité élémentaire. Les conséquences de la définition du cadre, ses propriétés principales, ses nouveaux
usages potentiels et ses aspects plus complexes sont ensuite analysés.
Le troisième chapitre est consacré aux problèmes d’implémentation : la
compatibilité des modèles intensionnels avec les modèles existants (notamment avec Unicode), la complexité algorithmique des fonctions de gestion
textuelle les plus courantes, les optimisations possibles au niveau du stockage.
Ce même chapitre présente également nos expériences concernant l’implémentation d’une variante du modèle dans le logiciel de préparation de documents Oméga (Ω). Ensuite, nous montrons comment il est possible de réaliser
une description sémantique formelle de propriétés de textèmes par l’intermédiaire d’un cadre de représentation des connaissances tel que RDF et OWL.
Finalement, le même cadre est employé pour construire un codage de signes
intensionnel et extensible, qui unifie le principe de codage avec le modèle
de texte en textèmes ; ainsi devient-il possible de profiter en même temps des
avantages des approches extensionnelle d’Unicode et intensionnelle de notre
modèle.
Enfin, le chapitre terminal, dédié aux conclusions et aux perspectives, offre
un bilan de nos résultats, tout en indiquant les voies de recherche non abordées dans le cadre de la thèse mais en liaison directe avec elle. Il s’agit, entre
autres, de l’influence qu’exerce les modèles proposés sur les aspects d’interface homme-machine du texte informatique, mais aussi d’un modèle de texte
alternatif qui peut être considéré comme la continuation logique du modèle
en textèmes, donné comme une réponse possible aux problèmes adressés au
chapitre 2.
15
16
CHAPITRE 1
MODÈLES DE
TEXTE
Le but de ce chapitre est de présenter les différentes formes de représentation textuelle depuis l’invention de l’écriture jusqu’au présent, notre sujet
principal étant, bien entendu, le texte informatique. Plus particulièrement, ce
qui nous intéressera est avant tout la manière dont le texte se construit à partir
d’un ensemble de signes élémentaires et ainsi devient porteur d’information.
Il s’agit donc d’une analyse structurelle de l’écrit au niveau de ses éléments
constitutifs. La notion formelle qui nous permettra de saisir la structure et le
comportement du texte est celle de modèle de texte ou modèle de l’écrit. Dans
le présent chapitre, il sera donc question de présenter les différents modèles
de texte qui ont existé depuis l’invention de l’écrit, l’objectif principal étant
de pouvoir ensuite situer les modèles de texte informatiques en les comparant
aux modèles pré-informatiques.
Au long du chapitre, nous suivrons un fil principalement chronologique.
En retraçant l’histoire de l’écrit et des nombreuses transformations de ses modèles, nous verrons que la cause principale derrière les transformations est
presque invariablement un changement d’usage, très souvent entraîné par une
évolution technologique. Le même principe de nouveaux usages émergents
continue à gouverner le développement des modèles de texte informatiques.
1.1 CONCEPTS DE BASE
Avant d’entamer un résumé historique de l’écrit, nous devons d’abord donner des éclaircissements sur les deux concepts de base que nous avons employés jusqu’ici sans les avoir définis de manière exacte : ayant parlé de modèle de texte, nous restons encore redevables de la définition de modèle et de
celle de texte.
Il faut tout d’abord comprendre que lorsque nous parlons de modèle, nous Le modèle
ne référons pas à un éventuel rapport de modélé-modèle entre langue et écriture, ni entre parole et écriture : la question si l’écriture relève ou non d’une
modélisation de la langue ou de la parole dépasse les cadres de cette thèse.
Notre point de départ est l’écriture seule, en tant que système de notation
autonome.
Les écritures ne sont cependant pas de systèmes formels et figés, ni dans
le temps ni dans l’espace : notre patrimoine écrit est en expansion constante.
Les conventions des écritures ne cessent d’évoluer, d’autant plus que chaque
membre de la société qui se met à écrire contribue par cet acte sa propre
compréhension et son propre usage de l’écrit. Il n’est donc pas forcément
évident comment l’abstraction d’un système formel et cohérent pourrait se
faire depuis un ensemble si hétérogène de conventions ; car on sait, de plus,
17
que les règles que l’on apprend très jeune à l’école ne sont ni suffisamment
formelles ni spécifiques pour être considérées dans leur ensemble autrement
que comme un modèle « naïf ».
Néanmoins, il reste toujours possible de choisir de manière consciente
un sous-ensemble bien circonscrit d’œuvres « de référence » selon des critères
spécifiques, et en se basant sur ce sous-ensemble d’œuvres, d’en choisir ensuite les « aspects » (paramètres, propriétés, etc.) que nous jugeons intéressants
à conceptualiser. Ce que nous appelons modélisation de l’écrit n’est autre
donc que la formalisation d’un ensemble restreint de paramètres décrivant un
ensemble restreint d’œuvres écrites.
Cette définition reste d’ailleurs cohérente avec celle formulée dans l’introduction, à savoir que la modélisation est « la conceptualisation de certains
aspects de l’écrit dans un but de réalisation à travers une technologie particulière ». Justement, le fait de construire le modèle en vue d’une implémentation
précise et par l’intermédiaire d’une technologie donnée fournissent déjà des
indices quant aux aspects de l’écrit à prendre en compte ou à ignorer.
Le texte
Dans cette thèse, nous allons restreindre la portée de nos modèles à travers une interprétation restreinte du terme texte. Comme évoqué dans l’introduction, le sens courant de ce terme est plutôt vague car il peut référer à des
œuvres écrites de longueurs et de formes très variées. Nous allons donc proposer une définition qui reflète une propriété invariante à presque toutes formes
de l’écrit : qu’il s’agit d’une suite ordonnée, à prépondérance unidimensionnelle, d’un ensemble restreint et bien codifié de signes élémentaires (que l’on
appelle lettres, caractères, graphèmes, signes, etc., selon le contexte du disLe paragraphe comme cours). En principe, nous ne nous intéresserons à aucune question concernant
limite de nos études la structure d’un document au-delà de ce que l’on appelle aujourd’hui paragraphe : la pagination, la structure logique (chapitres, sections, titres, etc.), la
mise en page, etc., ne nous concerneront pas.
Ce choix particulier de la portée de nos études est fondé en partie sur la
réalisation que le paragraphe fonctionne comme unité structurelle à la fois du
discours, du contenu et de la présentation graphique d’un document textuel.
En tant que telle, il représente une césure nette entre les aspects microscopiques et macroscopiques du document, car il est tout à fait raisonnable de
supposer qu’aucune interaction ne se produit entre des signes d’écriture se
trouvant dans deux paragraphes différents (ce qui est d’ailleurs cohérent avec
ce que l’on observe dans la majorité écrasante de documents existants).
1.2
L’ORIGINE DE L’ÉCRIT ET SON DÉVELOPPEMENT
La notation
Les spécialistes s’accordent aujourd’hui sur la nécessité de faire une claire
pictographique distinction entre systèmes de notation pictographique et systèmes d’écriture
et l’écriture [19, p. 3]. Ces derniers auraient pu se développer à partir de systèmes pictogra-
phiques — cette opinion ne fait pas l’unanimité [20] — qui avaient initialement
servi des buts précis comme l’expression de la propriété de biens ou d’une
croyance, ou encore d’un événement contenu dans la mémoire commune
d’une société par un effet mnémotechnique, etc. À la source de la conception
des véritables écritures on aurait sans doute trouvé un changement d’attitude,
un changement de l’usage de l’écrit, par la volonté d’exprimer des énoncés
18
plus variés, plus proches de l’expression de la langue parlée : certains concepts
abstraits où une liaison entre composant graphique et composant conceptuel
du signe1 de l’écriture n’est pas évidente à établir au travers d’un rapport pictographique de mimésis. De tels concepts sont par exemple les morphèmes
grammaticaux de la langue ou les noms propres, y compris ceux venant d’une
langue différente et ainsi ne portant a priori aucune valeur sémantique associable à un lexème de la langue locale. Afin de répondre à ce nouvel usage,
les signes d’écriture ont dû se diversifier, se complexifier en développant tout
d’abord la possibilité d’une représentation phonétique dont la structure (syllabique, consonantique, phonographique, etc.) était souvent fonction de la
langue en question. On observe donc une inévitable phonétisation des écritures dès qu’elles atteignent un degré d’universalité fonctionnelle. La propriété
unidimensionnelle de l’écrit est probablement la conséquence, au moins en
partie, de ce phénomène.
Cependant, dans l’histoire, la phonétisation de l’écrit n’a que très rarement
été menée jusqu’au bout, et même si cela est arrivé, la « pureté phonétique »
de l’écriture n’a presque jamais perduré. Les raisons sont nombreuses : premièrement, l’écriture et la langue pour laquelle elle est utilisée n’évoluent en
général pas en parallèle, que ce soit une évolution phonologique lente et naturelle de la langue ou un changement profond comme par exemple lorsqu’en
Mésopotamie la langue akkadienne a supplanté le sumérien tout en gardant
son écriture cunéiforme. Pour de nombreuses raisons, on observe de la part de
la société (ou plus précisément de la part de l’élite qui maîtrise l’écriture) une
attitude conservatrice par rapport à son écriture et beaucoup moins conservatrice par rapport à sa langue. Deuxièmement, une ambiguïté linguistique
causée par une homonymie ou une homophonie (très abondantes dans les
langues monosyllabiques) étant en général moins évidente à résoudre dans le
cadre de l’écrit que dans l’oral à cause des différences entre les deux voies
de communication (manque de contexte méta-communicatif, distance temporelle entre émission et réception de l’énoncé, etc.), d’informations supplémentaires doivent être ajoutées pour faciliter la désambiguïsation. Troisièmement,
la transcription écrite d’un énoncé parlé ne peut en général être qu’approximative car un tel énoncé peut posséder un grand nombre de propriétés vocales
(longueur, accentuation, intonation, etc.).
Même en supposant donc que le rôle d’une écriture est de refléter une
langue parlée le plus fidèlement que possible, une telle réflexion ne pourrait,
en général, être construite sur une base purement phonétique. Cependant,
avec l’évolution et la diversification de la communication humaine, les usages
de l’écriture se sont diversifiés également, et la transcription phonétique de la
parole n’est devenue qu’un usage parmi d’autres — artistiques, didactiques,
rhétoriques —, parfois plus prioritaires. La multiplication des usages se traduisait en le besoin de transmettre des informations de natures plus variées :
morphologique, syntaxique, sémantique, prosodique, et ainsi de suite.
La diversification du contenu a mené à un inévitable enrichissement de
la structure de nombreuses écritures : il était question d’indiquer la séparation des mots (par espace ou point séparateur) ou leur rapprochement (trait
1
Le terme signe est employé ici et dans le reste de ce travail dans un sens général d’élément
graphique de base et non dans un sens sémiologique précis.
19
L’écriture et son aspect
phonétique
Aspects
non-phonétiques
de l’écriture
Les fonctions
linguistiques
de l’écriture
d’union), les morphèmes grammaticaux (comme fait le syllabaire hiragana
dans l’écriture japonaise, même s’il n’est pas exclusivement dédié à la notation grammaticale). Les exemples classiques d’éléments sémantiques d’une
écriture sont les logogrammes mais il faut également mentionner les déterminants qui servent à désambiguïser un signe phonétique homonymique (qui
porte plusieurs significations) par l’ajout d’une clé sémantique, comme dans
le cas de l’écriture chinoise.
Dans la plupart des cas, le changement de la structure d’une écriture s’est
réalisé par l’extension de son ensemble de base, c’est-à-dire par la création de
nouveaux signes, mais aussi par la modification des signes existants. Certains
des nouveaux signes que l’on appelle diacritiques, au lieu d’être introduits
dans la suite de signes qui forme la colonne vertébrale du texte, se sont placés
à la proximité des signes existants, perpendiculairement à la direction dans laquelle ceux-ci étaient disposés. C’était, du moins au micro-niveau, une appropriation de la deuxième dimension du support, dans le but d’enrichir l’écrit
sans pour autant modifier les règles qui gouvernaient l’usage de ses signes
d’origine. (Par exemple, dans le cas de textes sacrés comme le Coran ou la Torah, il n’était pas question d’altérer le message de Dieu — porté par les lettres
de base — ; pour cette raison, le texte n’a pu être enrichi que par des diacritiques graphiquement séparées.) Les diacritiques avaient donc une fonction
d’enrichir ou de modifier la valeur du signe auquel elles ont été associées. La
valeur ajoutée pouvait être de nature quelconque (phonétique, sémantique,
prosodique, etc.) : on trouve des exemples de diacritiques pour des usages
linguistiques très variés. La notion de diacritique a été inventée comme une
solution générique au problème de la diversification du contenu véhiculé par
l’écrit.
Déjà au tournant de notre ère, l’écrit est donc devenu un système complexe qui englobait des informations de natures très différentes, d’une part à
travers une stratification fonctionnelle (entre signes de fonctions linguistiques
différentes), d’autre part par une stratification graphique (entre signes « principaux » et diacritiques). Comme nous le verrons plus loin, cette richesse structurelle de l’écrit n’a pas perduré dans l’ère informatique, ce qui aujourd’hui
réduit considérablement les usages potentiels du texte numérique. Parmi nos
objectifs dans cette thèse est de proposer un nouveau modèle de texte qui
permet de réintroduire dans le texte informatique une certaine complexité
structurelle au niveau des signes individuels, pour que le texte se réapproprie
de sa capacité de stratification fonctionnelle.
1.3
L’ÉCRIT IMPRIMÉ
L’imprimerie en caractères mobiles a été inventée initialement en Chine,
puis en Europe par Gutenberg qui a été le premier à perfectionner la technologie. Ce qui nous intéresse à propos de cette invention est l’apparition d’un
modèle de l’écrit qui continue à inspirer aujourd’hui les approches informatiques au formatage de texte.
L’imprimerie crée
Au début, l’objectif de Gutenberg était de reproduire fidèlement les proson modèle de l’écrit priétés graphiques de l’écriture manuscrite — qui plus est : un type précis
d’écriture manuscrite, notamment la textura quadrata — par les moyens d’une
20
nouveauté technologique qui fonctionnait d’une nouvelle manière. L’imitation
était cependant si fidèle que non seulement ligatures, signes de ponctuation et
diacritiques d’abréviation ont été adoptées (celles-ci servaient dans les manuscrits d’une part à aligner verticalement les fins de lignes, d’autre part à réduire
le travail de copie) mais aussi chaque lettre de base — majuscule et minuscule
— avait plusieurs formes alternatives afin d’imiter l’aléatoire du texte manuscrit
(voir fig. 1.1).
Initialement, il s’agissait donc d’une imitation quasi-parfaite des propriétés
graphiques du manuscrit. La rupture technologique et la création d’un modèle
de l’écrit — dont l’unité constitutive était désormais le bloc en métal correspondant au poinçon — n’a pas immédiatement résulté en un changement de
forme, ni de fond. Ce n’est qu’une fois le secret de l’invention de Gutenberg
dévoilé et la technologie de l’imprimerie consolidée en Europe que les imprimeurs ont peu à peu abandonné leurs efforts de simuler l’esthétique du
manuscrit et ont créé de nouvelles qualités esthétiques, cette fois-ci propres
au processus typographique. Le développement de ces nouvelles esthétiques
graphiques était suggéré par des considérations économiques (similairement
aux évolutions au niveau de la taille et du poids des livres ou de l’abandon des
enluminures) qui ont résulté de la nouvelle invention. Les formes des lettres
se sont simplifiées et « idéalisées » par rapport à celles des manuscrits car l’imperfection et l’aléatoire du manuscrit en ont été supprimées. En général, la
technique de l’impression n’était pas capable, comme l’avait été l’écriture à la
main, d’offrir le potentiel de contrôler à tout moment les aspects graphiques
du texte : adapter les signes aux contraintes imposées par le support, contrôler
le corps du caractère en continu, associer librement lettres et diacritiques, et
ainsi de suite.
En vue des contraintes mentionnées, il n’est pas par hasard que l’impression en caractères mobiles a connu le plus grand succès en Europe alors que
parmi les Chinois — les premiers inventeurs — elle n’est pas devenu populaire,
pour ne pas mentionner les civilisations arabophones où elle a carrément été
rejetée à l’époque. La modélisation typographique était particulièrement mal
adaptée à ces écritures, au chinois à cause du nombre de ses caractères, à
l’arabe à cause de son style calligraphique, de son orientation souvent bidimensionnelle et de ses nombreuses diacritiques. La non-adoption de la typographie dans ces cultures n’était donc pas la conséquence d’un manque
de développement technologique mais de l’incompatibilité entre l’usage du
manuscrit et l’usage typographique.
La modélisation typographique du texte ne peut cependant pas être accusée de n’avoir eu qu’un effet simplificateur sur l’écrit. Elle l’a transformé,
certes, tout en y apportant ses propres contributions. L’acte intellectuel de
la conception de modèle a suscité une formalisation des connaissances sur
l’écrit. L’établissement progressif des règles et des usages typographiques lors
de l’invention, puis lors de l’amélioration de la technique et de l’art de l’impression a été possible justement grâce à cette formalisation. Par exemple,
l’interaction graphique entre lettres avoisinantes, nuisant à la continuité du
texte, a été formalisée par les notions de crénage et de ligature typographique.
L’usage de la ponctuation a été codifié et affiné (tels que les espaces à différentes chasses ou les traits à différentes longueurs). D’autre part, la typographie
21
Codification
et sémantisation
des propriétés
graphiques
FIG. 1.1 – La casse de la Bible à 42 lignes de Gutenberg, tirée de [67].
22
a introduit de nouvelles variables2 graphiques en plus de celui des lettres de
base et celui des diacritiques : les variations de graisse, de style et de corps du
caractère sont devenu porteuses d’information — linguistique ou autre.
Notons encore que le modèle du bloc en métal a renforcé la connexion
entre lettre de base et diacritique car ces deux se sont retrouvés gravés dans
le même poinçon. Puisque la libre association entre lettres et diacritiques était
contrainte par le travail et les ressources nécessaires pour graver autant de
poinçons qu’il y a combinaisons lettre-diacritique, il est devenu difficile de
changer les conventions existantes de diacritisation, ce qui a contribué à considérer les lettres diacritées comme des lettres à part entière dans les alphabets.
Le modèle imprimé conçu par Gutenberg a été utilisé jusqu’au XXe siècle,
mais les nouvelles technologies professionnelles qui l’ont supplanté — le Linotype et le Monotype — ne l’ont pas modifié en profondeur. Par contre, elles
ont simplifié, entre autres, l’interaction homme-machine par l’introduction du
clavier qui a accéléré considérablement la vitesse de composition. Ce n’est cependant pas la technologie Linotype qui a introduit l’idée du clavier mais son
antécédent plus primitif, la machine à écrire. Celle-ci représentait un départ La machine à écrire
marqué de la perfection élaborée de l’imprimerie vers un procédé simplifié
qui consistait à appuyer sur une touche afin d’imprimer le signe correspondant sur papier et puis décaler la « tête » d’impression par une chasse fixe.
En réalité, la machine à écrire n’était pas le concurrent de l’imprimerie mais
plutôt une alternative à l’écriture manuscrite. On parle encore une fois d’un
nouvel usage, lié à un nouvel outil, qui a créé son propre modèle de l’écrit.
En comparaison à l’imprimerie, la machine à écrire n’était pas capable d’espacement proportionnelle et le texte dactylographié était dépourvu de variations
graphiques (en graisse, en style, en taille). Pour des raisons d’économie du
nombre de touches et du coût, la quantité de signes disponibles a été réduite :
en plus des ligatures typographiques — qui sont effectivement devenues superflues pour une écriture mono-espace —, certains signes de ponctuation
(les doube-quotes ouvrantes et fermantes, les tirets de largeurs variées) ont été
économisés, et souvent même les chiffres 0 et 1 ont dû être substitués par les
lettres majuscules O et I respectivement. Pour les mêmes raisons, les machines
à écrire étaient le plus souvent unilingues car le nombre de touches n’aurait
jamais suffit pour servir plusieurs langues.
En arrivant à l’époque numérique, nous voyons qu’il existait déjà plusieurs
modèles de l’écrit en parallèle, chacun répondant à un usage particulier.
1.4 LES PREMIERS MODÈLES INFORMATIQUES DE L’ÉCRIT
Il y a un point commun entre tous les modèles de l’écrit qui ont précédé
l’ordinateur : le texte était lu et interprété directement par l’humain. Son décodage était un acte de passage du visuel au conceptuel, à partir d’un ensemble
de signes graphiques vers une extraction des différentes couches d’informations qu’ils véhiculent. Tout a changé avec l’arrivée de l’ordinateur : désormais, l’information textuelle n’était plus uniquement destinée à la consomma2
Le terme variable a été adopté à partir de la thèse de Gérard Blanchard sur la sémiologie
de la typographie [17].
23
tion humaine, elle est également devenue information à interpréter, à traiter, à
transmettre et à générer par la machine. Comme tant de fois déjà, l’apparition
d’une nouvelle technologie a fait émerger de nouveaux usages de l’écrit. La
situation était similaire à l’invention de l’imprimerie car, encore une fois, il a
fallu remodéler un système existant afin de l’adapter à un outil qui fonctionnait d’une manière complètement nouvelle. Cependant, lors de la création des
premiers modèles informatiques, l’ancien modèle typographique n’était pas
parmi les influences principales de leur conception. Ceci n’est pas surprenant
puisque le rôle des premiers ordinateurs n’était pas du tout une communication écrite subtile et élaborée avec l’humain que peut offrir la typographie3 ;
l’essentiel était plutôt de réaliser des calculs et de retourner des résultats numériques de manière la plus simple et claire possible. La machine, à bas niveau,
n’est capable de travailler qu’avec des valeurs numériques — par conséquent,
il était nécessaire de définir un codage des éléments textuels.
Dans le jargon informatique, ces « éléments (atomiques) textuels » se
nomment tout simplement caractères. Ce n’est pas par hasard que jusqu’ici
nous avons évité de généraliser l’usage du terme caractère en dehors du doL’ambiguïté du terme maine de l’informatique : ce que nous montrerons dans la suite est que le
caractère mot caractère est surchargé de significations et que celles-ci sont très souvent
employées de manière incohérente. Il serait cependant impossible d’éviter ce
mot à cause de son importance primordiale et son usage omniprésent même
dans les opérations informatiques les plus basiques. Au contraire, nous allons
voir que la définition du terme caractère est la question principale à travers
laquelle il devient possible d’appréhender la nature du texte informatique, car
la définition que l’on lui donne relève du modèle de texte de son choix. Dans
la suite, après un très court détour étymologique, nous présenterons les différents sens — et donc les différents modèles — dans lesquels l’informatique
a utilisé le terme caractère jusqu’à nous jours, pour finir par préciser le sens
dans lequel nous utiliserons nous-mêmes ce terme dans la présente thèse.
1.4.1 L ES
NOTIONS DE CARACTÈRE ET DE CODAGE
D’origine grecque, le sens initial de χαρακτ ήρ était marque gravée. Le
mot a ensuite gagné de nouvelles significations figurées (traits distinctifs d’une
personne, d’une personnalité). Dans la typographie française traditionnelle,
cependant, caractère pouvait signifier à la fois le bloc en métal individuel, son
empreinte, ou bien la police de caractères entière, c’est-à-dire l’ensemble de
signes qui partagent une charte graphique commune (par rapport à ce dernier
sens, voir par exemple [23]). La première édition du Dictionnaire de l’Académie française de 1694 [51] témoigne déjà de ces diverses interprétations :
CARACTERE . Empreinte, marque. Il £e prend particulierement
pour les figures dont on £e £ert dans l’e£criture, ou dans l’impre££ion. Gros caractere. petit caractere. caractere li£ible. bon caractere. mauvais caractere. e£crit imprimé en beau caractere. caractere d’Imprimerie neuf, u£é, poché, vieux. caracteres Grecs, Egyptiens, Arabes. caracteres hieroglyphiques. les anciens imprimoient
3
Autant plus que la transmission de l’information textuelle depuis l’homme vers la machine
se faisait pendant longtemps principalement par des cartes perforées.
24
FIG. 1.2 – La première version du codage de caractères ASCII, datant de 1963,
qui ne distingue pas entre majuscules et minuscules.
£ur le front des criminels & des e£claves certains caracteres.
C’est le sens de « signe individuel » du mot caractère qui a été repris dans
l’informatique, sans doute dû à une influence anglo-saxonne (puisque ce sont
les États-Unis qui étaient à la tête de la recherche et de la fabrication d’ordinateurs). Il n’était donc pas illogique d’appeler caractère l’élément atomique
textuel en informatique, et l’ensemble de caractères disponibles sur une plateforme donnée, avec leurs valeurs numériques, le codage de caractères ou jeu
de caractères.
Il y a cependant une différence fondamentale entre le caractère traditionnel (caractère métallique ou son empreinte, le signe imprimé par photocomposition ou par une machine à écrire) et le caractère informatique en tant
qu’élément de codage : ce dernier ne possède pas forcément d’image visuelle.
Lorsqu’un texte est communiqué à l’ordinateur par le moyen d’une carte perforée, la forme graphique des caractères transmis ne joue aucun rôle, elle peut
même être inexistante. Ceci est encore un nouvel usage de l’écrit où l’interprétation du signe se fait non pas par une reconnaissance visuelle d’une forme
mais, d’une part, par l’ensemble de conventions sémantiques que représente
la table de codage, et d’autre part, comme nous allons voir prochainement,
à travers le contexte que représente l’usage du texte en question. En d’autres
termes, le caractère informatique est un élément textuel a priori non visuel.
Afin de mieux comprendre l’affirmation précédente, prenons un exemple ASCII
concret de codage : la norme ASCII. À première vue, l’intérêt de normaliser les
codages informatiques paraît évident : la connaissance exacte des éléments du
codage utilisé — quel code numérique correspond à quel élément textuel —
est essentiel pour la compréhension de tout message échangé, et ceci est vrai
aussi bien pour la communication entre machine et homme qu’entre deux machines (la communication directe par codes numériques ou cartes perforées
étant relativement rare entre deux êtres humains). La norme ASCII, codage
sur 7 bits, est ainsi né en 1963 pour ensuite être réutilisé en tant que sousensemble d’un grand nombre d’autres codages du monde. En examinant la
version initiale du codage ASCII (voir figure 1.2), on remarque surtout l’absence de lettres latines minuscules et la présence de nombreux caractères
25
de contrôle. Ces deux propriétés démontrent le point soulevé ci-dessus que
l’usage de l’écrit pour communiquer avec l’ordinateur était très spécialisé et
non-visuel qui a fini par, en partie, redéfinir les éléments atomiques textuels.
Certains caractères de contrôle comme le SHIFT IN, le SHIFT OUT et l’ESCAPE
ont même pu donner des propriétés de programme informatique au texte car
celui-ci n’a pu être lu et interprété correctement que de bout en bout et par
un automate à états. En ce qui concerne les lettres minuscules, elles ont été
ajoutées au codage ASCII deux ans plus tard, en 1965.
1.4.2 U NE
TENTATIVE DE FORMALISATION DE LA NOTION
DE CARACTÈRE ET DU TEXTE INFORMATIQUE
Nous avons maintenant l’impression de comprendre que le rôle du codage
de caractères est de mettre en relation un ensemble de valeurs numériques —
les codes de caractère — avec un ensemble de « valeurs sémantiques » qui
correspondraient à des éléments textuels de bas niveau. Dans cette section,
nous ferons une tentative de définir ces notions de manière plus précise.
Supposons donc l’existence d’un ensemble S d’unités sémantiques textuelles. Il ne s’agit nullement, du moins pour le moment, de supposer que
cet ensemble S contienne toutes les unités sémantiques textuelles possibles
et imaginables : il serait, de toute manière, impossible d’énumérer celles-ci.
Plutôt, l’ensemble S représente un « choix pratique et restreint » — moins que
128 éléments dans le cas du codage ASCII — que nous allons indexer par des
codes de caractère. En formalisme mathématique : soit NC un entier naturel, le
code numérique maximal, et S un ensemble d’unités sémantiques textuelles
tel que |S| ≤ NC . Alors le codage C se représente comme une relation, de la
manière suivante :
C ⊂ {0, 1, 2, ..., NC } × S
Il faut remarquer que C n’est pas une relation quelconque ; nous arriverons
très bientôt aux restrictions qui s’y appliquent.
Le caractère, à son tour, est un élément de ce codage C :
c∈C
Analysons les propriétés de la relation C. Celle-ci est surjective car nous avons
choisi les éléments de S pour que celui-ci soit entièrement couvert. D’autre
part, dans certains codages il existe des codes soi-disant non définis auxquels
aucune valeur sémantique n’est associée (en d’autres termes, on permet que
|S| soit strictement inférieure à NC + 1) ; pour cette raison, C n’est pas forcément applicative. L’injectivité (qu’une unité sémantique soit référée par au
plus un code numérique) est un critère de non-ambiguïté et d’économie que
les codages de petite taille (tels que l’ASCII) arrivent à remplir sans difficulté.
Finalement, la propriété de fonctionnalité (qu’aucun code numérique ne réfère à plusieurs unités sémantiques) devrait éviter la « polysémie » au sein du
codage.
Il se trouve cependant que la polysémie est, en réalité, une propriété essentielle des premiers codages de caractères. Un exemple de caractère polysémique est l’apostrophe « ’ » qui prend tantôt le rôle d’apostrophe, tantôt
26
celui du guillemet britannique fermant, tantôt celui de l’accent aigu, et ainsi
de suite. Il ne s’agit pas d’un cas exceptionnel ou d’un abus de la norme. Au
contraire, la variation de la sémantique associée à un code donné est plutôt la
règle que l’exception ; pour s’en convaincre, il suffit de penser à l’utilisation
souvent divergente des signes de ponctuation dans les différents langages de
programmation. En effet, la sémantique d’un caractère dépend du contexte (de
l’application) dans lequel il est utilisé, plus généralement : de l’usage. Il n’est
même pas possible de parler d’un « sens d’origine » ou « traditionnel » éventuel
qui aurait été « supplanté » ou « surchargé » par d’autres usages : par exemple,
l’auteur ne connaît aucune règle précise qui puisse a priori définir la différence sémantique entre les crochets « [] » et les accolades « {} » : ceci dépend
entièrement du contexte d’usage dans lequel ces symboles sont utilisés.
En résumé, les codages de caractères — et surtout ceux antérieurs à Unicode, comme le codage ASCII — ne peuvent être considérés comme des correspondances un-à-un entre codes et unités sémantiques que dans un contexte
d’usage donné. En d’autres termes, les éléments de S sont des unités sémantiques approximatives, et c’est le contexte de leur usage qui fournit la précision
sémantique nécessaire. Dans ce sens, le codage C, tel que l’ASCII, n’est qu’un
cadre, une indication, qui restreint la polysémie et l’homonymie des caractères
à un niveau « acceptable » mais qui permet au contexte d’usage de préciser les
valeurs sémantiques exactes.
LA
DÉFINITION DU TEXTE INFORMATIQUE
En partant des définitions de codage et de caractère données ci-dessus,
il devient maintenant possible de préciser ce que l’on entend par texte informatique : il s’agit tout simplement d’une chaîne de codes de caractère
où chaque code représente un élément du codage C et s’interprète dans un
contexte d’usage U . La définition ci-dessus précise que le codage C ainsi que
le contexte U doivent être connus afin que, dans notre interprétation, une
chaîne de valeurs numériques puisse être appelée texte. Nous ferons une distinction entre chaîne de caractères et texte de la manière suivante :
DÉFINITION 1 (CHAÎNE
DE CARACTÈRES (DE CODES DE CARACTÈRE))
Soit Σ = {0, 1, ..., NC }, c’est-à-dire l’ensemble de codes du codage C. La
chaîne de caractères K est alors définie comme
K ∈ Σ∗ , autrement dit, K = c1 c2 c3 ...cn où ci ∈ Σ
Strictement parlant, K est une chaîne de codes de caractère ; les informaticiens
ont cependant tendance à employer le terme chaîne de caractères, même si
nous avons défini le caractère comme la correspondance d’une valeur numérique et d’une sémantique approximative.
Nous pouvons interpréter la chaîne de caractères ainsi définie comme une
structure algébrique, un monoïde libre, avec la concaténation comme opération, la chaîne vide comme élément neutre et Σ comme générateur libre4 , voir
à cet égard par exemple [21].
4
Le générateur libre est souvent appelé alphabet, terme plus parlant mais en même temps
trompeur dans un contexte multi-écritures ; pour cette raison, nous allons l’éviter.
27
DÉFINITION 2 (TEXTE)
Le texte se définit comme une chaîne de caractères K interprétée dans un
contexte d’usage, cette interprétation comprenant la désabiguïsation de la sémantique associée aux caractères individuels.
La non-définition La précision de la sémantique des caractères n’est donc qu’un seul parmi les
de la notion d’usage rôles du contexte d’usage. Nous considérons d’ailleurs que ce dernier est un
concept d’une complexité très importante, et pour cette raison nous préférons
ne pas en chercher la définition précise à ce point dans notre travail. Plutôt,
nous reviendrons à ce concept à plusieurs reprises, ainsi améliorant peu à peu
notre compréhension à son égard.
En conclusion, le premier modèle de texte informatique présenté consiste
en les ensembles Σ et S, la relation C, la concaténation comme opération
génératrice, et finalement le contexte d’usage qui complète l’interprétation du
codage C.
1.4.3 L’EXTENSIONNALITÉ DE
LA DÉFINITION PRÉCÉDENTE
La définition du caractère donnée ci-dessus se base sur la supposition qu’il
existe un ensemble vaste (et potentiellement inconnu) d’unités sémantiques
textuelles dont un sous-ensemble S bien délimité participe, à travers le codage, à la représentation informatique de texte. Plus précisément, afin de
contourner la barrière imposée par la taille extrêmement restreinte des premiers codages, les unités sémantiques dans S ont pu être réinterprétées en
fonction d’un contexte d’usage donné.
Deux questions qui se posent à cet égard : premièrement, peut-on donner
une définition précise de l’ensemble de toutes les unités sémantiques textuelles ? Deuxièmement, par quels critères choisir de cet ensemble les éléments qui feront partie de l’ensemble S, et donc du codage ?
La première question, de nature ontologique, peut être reformulée ainsi :
comment décider d’un signe s’il est de nature graphémique, s’il peut faire
partie intégrante de la suite (quasi-)unidimensionnelle de signes qu’est l’écrit ?
Ne devrait-on, au contraire, supposer que le choix des signes participant à une
œuvre textuelle doit appartenir à l’auteur et, selon la volonté de celui-ci, tout
signe a le potentiel de devenir signe d’écriture — comme n’importe quelle
porte au Pays fantastique peut devenir l’entrée du Temple des mille portes
dans l’Histoire sans fin de Michael Ende ?
Jusqu’aux années 1990, cette question n’avait pas d’actualité : le nombre
de codes disponibles dans les tables de codage était si restreint que l’idée
de créer un codage qui ne se limiterait pas à un nombre d’usages très petit
— par exemple, la couverture des lettres de base d’un ensemble très limité
de langues occidentaux — n’avait pas de réalité pratique. Il fallait forcément
faire des choix, mais selon quels critères ? La réponse se trouve dans le(s)
usage(s) que le codage est censé servir : les tâches à accomplir, les traditions,
la permissibilité technologique. Dans le pire des cas, le choix sera ad hoc ou
mal considéré [9], mais un choix pratique est toujours possible.
Quoi qu’il en soit, la définition d’un codage donné à travers l’énumération
(la dénotation) de ses éléments constitutifs relève d’une approche extensionnelle. En d’autres termes, le codage est auto-définissant : le digraphe « æ » est
28
un caractère parce qu’il fait partie du codage ISO 8859-1, l’« œ » n’est pas un
caractère parce qu’il n’est pas présent dans ce même codage. Dans la suite,
nous appellerons également cette approche extensionnelle principe énumératif car il s’agit d’énumérer, comme dans un alphabet ou dans un syllabaire,
l’ensemble de signes qui peuvent potentiellement être utilisés.
L’approche extensionnelle devient peu commode lorsque l’universalité est La difficulté
parmi les objectifs de la création d’un codage. Si le codage est censé couvrir d’un codage universel
la (quasi-)totalité des écritures (voire des systèmes notationnelles) du monde
sans que le nombre de points de code disponibles soit contraint — tel est le
cas du codage Unicode que nous présenterons en section 1.8 —, ou formellement, lorsque la taille de l’ensemble S augmente, alors la décision si un
signe donné doit être ou non considéré comme signe d’écriture devient un
problème important. Le principe énumératif n’est applicable facilement que
lorsque le nombre de signes est restreint. Un des objectifs de cette thèse est
de montrer qu’une méthodologie intensionnelle — qui, au lieu d’énumérer
les éléments du codage, s’intéresse plutôt à définir leurs propriétés pertinentes
— peut être plus précise et plus efficace dans la construction d’un tel codage
universel.
1.4.4 L ES
PREMIERS MODÈLES VISUELS
Le modèle de texte présenté précédemment peut être qualifié comme nonvisuel car il fonctionne sans être concerné par l’affichage des caractères, cet
aspect n’étant pas considéré comme pertinent. Cependant, l’ordinateur est
vite devenu capable de produire une trace visuelle des résultats de ses calculs
à l’aide d’une imprimante, puis, à partir des années 1970, sur des écrans.
On peut alors parler de la matérialisation visuelle du caractère, même si les
formes graphiques associées aux caractères sont au début circonstancielles
et sans importance au-delà d’une lisibilité primaire. De ce point de vue, il
y a similarité entre l’ordinateur muni d’un clavier et d’un écran (ou d’une
imprimante) et la machine à écrire : lorsque l’utilisateur entre un caractère
à travers son clavier et il (ou elle) voit apparaître l’image correspondante sur
l’écran (ou sur l’imprimante), une association mentale directe se crée entre
– la touche du clavier ;
– l’image visuelle qui apparaît ;
– une information sémantique a priori connue (comme par exemple une
lettre d’alphabet) ;
exactement comme lors de l’utilisation d’une machine à écrire. Dans le cas
de l’ordinateur, cependant, un quatrième élément entre en jeu : le code de
caractère. En effet, le caractère reste l’élément constitutif du texte et ce n’est
qu’au moment de l’affichage qu’à chaque caractère s’associe une image.
Les associations entre images et caractères étaient initialement constantes L’image gagne
(pré-définies) pour une plate-forme donnée. Ensuite, des imprimantes multi- de l’indépendance
fontes sont apparues où il était possible (souvent par intervention mécanique :
changement de tête d’impression) de choisir parmi un ensemble de fontes
pour l’affichage du texte. C’était le début d’une longue transition, à partir des
années 1970 jusqu’à nos jours, vers un nouveau modèle de texte où l’image
s’émancipe et devient un élément indépendant du modèle.
29
Afin de marquer la distinction du caractère vis-à-vis de l’image, le jargon
informatique moderne (depuis les années 1990) appelle cette dernière glyphe,
par un néologisme originaire de la langue anglaise.5 Nous allons revenir au
sujet de la dichotomie caractère-glyphe dans la section 1.8 ; pour le moment, il
nous suffira de préciser que par glyphe on entend l’image d’un signe d’écriture
tel qu’elle est contenue dans une fonte numérique. (Par ailleurs, l’usage du
terme est loin d’être cohérent aujourd’hui, il en existe plusieurs définitions
mutuellement contradictoires ; nous reviendrons à ce problème également.)
Fonte
Le concept de fonte a ses origines dans la typographie où sa signification
est assez claire ; dans la huitième édition du Dictionnaire de l’Académie Française d’entre 1932 et 1935 [52] on trouve sous l’entrée fonte, entre autres, la
définition suivante :
La notion de glyphe
FONTE. [...] En termes d’Imprimerie, il se dit de l’Ensemble de
toutes les lettres et de tous les signes composant un caractère complet de telle ou telle grosseur. Une nouvelle fonte. Une fonte de
petit romain, de cicéro, etc., ou de neuf, de onze, etc. Une fonte
de nouveaux caractères. Une fonte toute neuve.
Dans l’informatique, par contre, le concept de fonte a subi de nombreuses évolutions. Nous avons déjà évoqué qu’au début, une fonte — qui appartenait à
une imprimante — consistait en un simple ensemble d’images — de glyphes —
où chacune d’elles correspondait à un caractère du codage de la plate-forme
donnée. Formellement, une telle fonte peut être considérée comme un ensemble I d’images (de glyphes) et une fonction surjective f : {0, ..., NC } 7→ I
qui définit des correspondances entre codes de caractère et images (glyphes).
La fonction f , telle que nous l’avons définie, ne peut en général pas être considérée bijective pour l’unique raison que les caractères de contrôle, également
appelés caractères non imprimables, n’ont pas de glyphe dédié.
1.5
Un nouvel usage :
le traitement de texte
L’ÉVOLUTION DE LA FONTE
OU L’ÉMANCIPATION DU GLYPHE
Une fois de plus, c’est la convergence d’une évolution technologique et
d’un changement d’usage qui a fait émerger une nouvelle approche à la modélisation informatique de l’écrit. L’apparition des imprimantes graphiques et
puis des écrans graphiques a permis un contrôle du rendu visuel jusqu’alors inégalé. En même temps, la popularité du word processing, traitement de texte,
a créé un nouvel usage de l’ordinateur vis-à-vis de l’information textuelle : de
son rôle d’humble véhicule du résultat des calculs, le texte est devenu la raison
pour calculer, le but du jeu. Il était désormais question d’utiliser l’ordinateur
dans le seul objectif de produire du texte destiné à la lecture humaine, et par
ce fait, le texte produit a dû répondre à un nombre de nouveaux critères.
5
Jusqu’ici, nous avons évité d’employer le terme glyphe : il relève d’anachronisme de désigner l’image dans son état fortement lié au caractère par un terme qui, au contraire, a été adopté
dans la langue française afin de marquer l’indépendance de celui-ci. Malgré cette considération, pour des raisons de simplicité et en anticipation, nous allons désormais employer le mot
glyphe au lieu d’écrire image associée au caractère.
30
Le projet qui s’élève — par son approche scientifique à la composition
de texte et par ses résultats spectaculaires en termes de qualité — au-dessus
des nombreux logiciels de traitement de texte balbutiants de la fin des années 1970 est sans aucun doute le fameux système de préparation de document TEX, signé par D.E. Knuth et ses doctorants. Pour une présentation de
l’histoire (forte intéressante) derrière la conception de ce logiciel et de son
fonctionnement, cf. par exemple [42], une collection d’articles rédigés par
Knuth. Ce qui nous intéressera au présent sont les modèles de texte de TEX
et le fonctionnement de ses fontes. On parle de modèles de texte en pluriel
parce que TEX en possède, comme nous allons voir très bientôt, au moins
trois. Ces trois modèles correspondent aux formes représentationnelles d’un
texte, décrites avec beaucoup de clarté par Mittelbach et Rowley dans [49].
Ils considèrent que la fonction d’un système de préparation de documents est
d’exécuter une série de transformations textuelles, à partir d’une représentation d’échange jusqu’à une représentation finale, par l’intermédiaire d’une représentation interne transitionnelle. La section suivante nous permettra de voir
en détail comment TEX implémente et fait usage de ces trois représentations
distinctes. Si nous consacrons une section relativement longue à une description détaillée du modèle de texte de TEX, ce n’est pas uniquement grâce à ses
mérites historiques : cette description nous servira ensuite, en section 3.2, à
montrer l’intérêt d’avoir remplacé le modèle en question par le modèle plus
puissant que proposera cette thèse.
Les trois formes
représentationnelles
(modèles) de texte,
d’après Mittelbach et
Rowley
1.5.1 TEX
Le système TEX a été conçu avec l’objectif de reproduire par ordinateur les
conventions et la richesse visuelles propres à la typographie traditionnelle ; en
d’autres termes, il s’agit d’un logiciel typographe qui produit, à l’aide d’une
imprimante graphique, des pages imprimées de qualité comparable à celle de
la typographie au plomb.
MODÈLES
DE TEXTE D’ENTRÉE ET DE SORTIE
Nous avons vu que pour les ordinateurs de l’époque, le texte était synonyme de chaînes de caractères tirés d’une table de codage extrêmement
concise (telle que le codage ASCII) alors que la typographie traditionnelle
employait bien plus de signes (quotes, double-quotes, guillemets ouvrantsfermants, tirets de longueurs différentes, espaces à chasses variées, etc.). Selon
le principe de fonctionnement de TEX, l’utilisateur doit fournir un document
d’entrée n’utilisant que des caractères ASCII qui sera ensuite compilé afin de
produire un texte final entièrement composé de glyphes. La solution de TEX au
problème de signes non prévus par la table de codage de caractères consiste
à utiliser des combinaisons de caractères et des commandes pour entrer ces
signes et à générer en guise de sortie une représentation finale où les codes de
caractère sont remplacés par des codes de glyphe, c’est-à-dire des références Codes de caractère
vers des images. Au lieu d’identifier par le même code et le caractère et son et codes de glyphe
image, on est désormais en présence de deux codes indépendants : le code de
caractère, tiré d’une table de codage de caractères, et le code de glyphe, tiré
de la fonte utilisée dans le document. En théorie, il n’y a pas de rapport direct
31
entre code de caractère d’entrée et code de glyphe de sortie associé, même
si en pratique la plupart des caractères imprimables se trouvent aux mêmes
positions numériques que leurs glyphes correspondants.
TEX se retrouve alors avec deux ensembles de codes distincts et, en conséquence directe, avec deux types de documents : le document d’entrée, composé de caractères et de commandes (elles-mêmes composées également de
caractères), et le document formaté de sortie, composé de glyphes et d’informations sur leurs positions géométriques en deux dimensions. Autrement dit,
le modèle de texte de TEX comprend en réalité deux modèles distincts : le modèle d’entrée ou d’échange ou d’écriture et le modèle de sortie ou final ou de
lecture.
Deux modèles pour
La création de deux représentations parallèles pour ce qui est essentiellele même texte ment le même texte était le début d’une divergence croissante entre ce qui
est entré par l’utilisateur à travers le clavier et ce que l’ordinateur lui rend
sur papier, et ceci jusqu’au niveau textuel le plus bas, jusqu’aux unités de
base de l’écriture. Il existait désormais deux notations séparées : d’une part,
la notation « orientée ordinateur », héritière des systèmes de télécommunication (télégraphe, télex, etc.) et de la machine à écrire, et d’autre part, une
notation « orientée typographie », héritière de l’imprimerie traditionnelle correspondant à un usage inspiré des traditions typographiques. Le système TEX
devait répondre aux deux usages en même temps, malgré le fait que ni le
clavier de l’ordinateur, ni le codage de caractères utilisé ne soient adaptés à
un usage typographique. Dans le reste de ce chapitre, nous verrons les effets
considérables, à la fois positifs et négatifs, que la divergence des deux types
de notations textuelles a eu sur la compréhension et l’usage du texte informatique. Dans le chapitre suivant, un des objectifs du nouveau modèle de
texte que nous allons proposer est justement d’à nouveau faire converger les
différents usages textuels vers une représentation commune, tout en évitant
le piège de vouloir représenter l’intégralité des usages textuels par un seul
ensemble fermé de signes élémentaires.
LES
Manque de distinction
terminologique entre
caractère et glyphe
chez Knuth
FONTES DE
TEX
C’est la responsabilité des fontes de TEX d’établir la liaison entre les deux
modèles de texte par la conversion de codes de caractère en codes de glyphe.
Pour la plupart des caractères, il s’agit d’une transformation à l’identique car
les codes de glyphe ont été choisis de manière à être égaux aux codes de
caractère correspondants. Les signes ne correspondant à aucun code ASCII
sont entrés par des combinaisons de caractères (comme par exemple « --- »
pour le tiret cadratin « — » ou « fi » pour la ligature typographique « fi ») ou
bien par des commandes. Ainsi, à la manière des ligatures, plusieurs caractères peuvent être convertis en un seul glyphe, un phénomène remarquable
qui témoigne du fait que le glyphe dans le modèle de texte de TEX est en
effet très proche du caractère typographique, du bloc de métal dans le modèle de l’imprimerie traditionnelle. (C’est peut-être pour cette même raison
que Knuth, concepteur et développeur principal de TEX, n’a pas fait de distinction terminologique entre caractère d’entrée et glyphe de sortie : pour lui,
32
les deux concepts s’appelaient tout simplement caractère6 . Afin d’implémenter les conversions parfois complexes entre caractères et glyphes, les fontes de
TEX contiennent de véritables programmes, les programmes de ligaturage et
de crénage. C’est en exécutant ces programmes contenus dans les fontes que
TEX est amené à utiliser les glyphes de ligature et applique les déplacements
horizontaux des glyphes liés au crénage.
CODAGE
DE CARACTÈRES ET CODAGE DE GLYPHES
Nous arrivons à des questions théoriques de grande importance que TEX a
introduites par la conception particulière de son modèle de texte. Le fait que le
même contenu textuel peut être représenté de deux manières différentes, par
des caractères et par des glyphes, mérite une réflexion sur la similarité et la
différence entre les deux concepts. À première vue, le caractère et le glyphe,
tels qu’ils sont utilisés par TEX, sont des concepts quasi-identiques : il s’agit
dans les deux cas de codes représentés par des entiers naturels. Nous avons vu
que les deux notations correspondaient à deux usages différents, notamment à
un usage textuel de communication informatique ou d’échange d’informations
qu’offre par défaut le système d’exploitation de la plate-forme donnée à travers
le codage de caractères supporté, et à un usage typographique dont le nombre
de signes disponibles est souvent plus élevé.
En théorie, comme solution alternative, on pourrait imaginer un codage
de caractères étendu qui comprendrait également les signes utilisés principalement en typographie et qui, par ce moyen, permettrait d’avoir un seul codage La possibilité
commun pour les deux usages. À l’époque de la création de TEX, cette solu- d’un codage combiné
tion n’a pas été retenue, pour un nombre de raisons pratiques. Tout d’abord,
les ressources de stockage informatique limitaient sévèrement l’extension du
nombre de points de code ; et s’il était question d’étendre le codage interne
de 7 bits à 8, les signes typographiques n’étaient pas les seuls candidats pour
les nouvelles cases du tableau. Deuxièmement, le nombre de signes typographiques à ajouter au codage n’a pas de borne bien définie car il dépend
essentiellement de la nature des textes typographiques que l’on souhaite produire : par exemple, pour un ouvrage mathématique, plusieurs centaines de
symboles seraient nécessaires, y compris l’alphabet grec ; pour ne pas parler
d’un éventuel usage multilingue, voire multi-écriture.
Le problème le plus important qui résulterait de l’introduction de signes
typographiques dans le codage de caractères est un problème de cohérence :
cette manière de mélanger deux usages et par conséquent deux modèles de
texte conceptuellement différents résulte en un ensemble redondant de signes
où des concepts « similaires » sont représentés à la fois par plusieurs entités. Par
exemple, un « a » italique et un « a » gras, deux signes typographiques distincts,
représentent la même lettre déjà couverte par le caractère no 97 du codage
ASCII. De même, la ligature « fi » correspond à la même information textuelle
qu’un caractère « f » suivi d’un caractère « i ». De telles distinctions ne sont pas
pertinentes pour des usages non-typographiques et l’incohérence représentationnelle ainsi introduite a comme résultat de complexifier nombreux aspects
6
La citation « ...sets of related characters that are used in typesetting are traditionally known
as fonts of type », extraite du TEXbook [41], témoigne de ce double emploi.
33
La possibilité
d’un codage de signes
typographiques
analogue au codage
de caractères
du traitement textuel.
La distinction entre modèle de texte typographique ou formaté et modèle
d’échange d’informations textuelles était donc à la fin des années 1970 une
réalité pratique. Elle a permis d’élargir considérablement la gamme de signes
imprimables sans interférer avec, et même en se dissociant complètement des
normes de codage de caractères utilisées sur les différentes plates-formes. Il
y a cependant une nouvelle question soulevée par la solution ci-décrite : y
a-t-il besoin, comme dans le cas des caractères, d’un codage de signes à usage
typographique qui pourrait servir comme étiquetage sémantique des codes de
glyphe ?
Du point de vue de l’humain, l’association d’une image concrète visuellement reconnaissable avec le code de glyphe représente déjà une information
sémantique. Ce type d’information reste néanmoins inexploitable pour l’ordinateur7 qui ne serait pas capable d’interpréter une chaîne de codes de glyphes
si la seule indication associée au code était une image, comme il est capable
de traiter ou d’analyser une chaîne de caractères — dont le codage C est connu
— afin d’y distinguer lettres, chiffres, signes de ponctuation, etc.
Sans informations supplémentaires, le code de glyphe reste donc un
simple nombre entier, non interprétable par l’ordinateur. Face à ce problème8 ,
TEX a choisi l’approche de créer en quelque sorte sa propre norme, en définissant ses propres codages de glyphes : à chaque code de glyphe, TEX associe
une unité sémantique correspondant à un signe typographique. En comparant cette définition à celle du codage en général (section 1.4.2 sur page 26),
la particularité du codage de glyphes est alors le fait que, conformément à
son usage, ses unités sémantiques textuelles sont choisies parmi ce que l’on
appelle ici « signes typographiques ».
TEX définit plusieurs codages de glyphes, avec des ensembles de signes
typographiques disjoints. C’est la conséquence d’une contrainte de stockage :
un code de glyphe est représenté sur 8 bits, ce qui limite le nombre d’éléments
du codage (et de la fonte) à 256. Il en suit que le même code de glyphe peut
représenter plusieurs signes typographiques selon le codage utilisé. Le code de
glyphe de TEX ne peut être interprété sans spécifier le codage de glyphes utilisé
et, de même, ce code de glyphe ne peut se référer à une image visuelle qu’en
connaissant la fonte qui la contient. Dans le modèle de texte de TEX, le code
de glyphe représente donc deux concepts différents car il peut être couplé
soit avec une image contenue dans une fonte, soit avec une unité sémantique
représentée dans un codage de glyphes. Nous appellerons le premier couple
glyphe, le seconde signe typographique codé.
Il est d’autant plus important de distinguer entre l’image concrète (glyphe)
et le concept abstrait (signe typographique codé) que, nous verrons plus tard,
les deux notions sont très souvent confondues. De ce point de vue, la définition du terme glyphe donné par Haralambous dans [27] est en concordance
avec la nôtre : « [...] a glyph is “the image of a typographical sign” » : le glyphe
7
La reconnaissance optique reste une possibilité peu pratique, surtout dans les années 1970
et 1980.
8
À l’époque de la création de TEX et même jusqu’aux années 1990, ceci n’était pas un
véritable problème, le seul but de TEX étant la création d’un document destiné à l’impression
uniquement. Puisque le document de sortie de TEX n’avait aucune utilité à part être imprimé, un
manque de sémantique associé aux codes de glyphe n’aurait pas eu de conséquence pratique.
34
est l’image d’un signe typographique (et non pas le signe même).
Le lecteur a certainement remarqué la similarité de la définition du signe
typographique codé donnée ci-dessus à celle du caractère en section 1.4.2.
Dans les deux cas, on suppose la possibilité de choisir un ensemble restreint
d’éléments à partir d’un vaste ensemble d’unités sémantiques textuelles. Par
conséquent, le problème ontologique auquel nous faisons face par rapport
aux signes typographiques : comment décider d’un signe quelconque s’il est
« typographique » ou non ? Si ce genre de question était particulièrement dure
à répondre concernant les caractères, le cas des signes typographiques l’est
moins car on a la possibilité de s’appuyer sur les traditions d’usage et de définir
le signe typographique comme étant un signe abstrait, utilisé dans la typographie traditionnelle, correspondant aux signes gravés sur les poinçons. Même
s’il n’est pas tout à fait trivial de faire l’abstraction depuis les images portant
l’esthétique de leurs fontes vers le concept de signe typographique, grâce aux
expériences typographiques de cinq siècles, on a des idées relativement claires
sur l’ensemble de signes à travers lesquels se réalise la typographie.
C’est d’ailleurs par cette voie typographique « confortable », où l’abstrait
est saisi à travers le concret, que Tereza et Yannis Haralambous, toujours
dans le même article [27], tentent de proposer une définition alternative au
concept de caractère. Comme évoqué ci-dessus, selon leur proposition, le
glyphe est l’image d’un signe typographique et le caractère, à son tour, est
une classe d’équivalence de glyphes, basée sur une description logique ou
linguistique simple. Que faire lorsque l’écriture en question ne possède pas
d’histoire typographique significative, voire n’en possède aucune ? Les auteurs
de l’article mentionné suggèrent qu’en théorie la construction d’un modèle
typographique pertinent est possible pour toute écriture.
Il y a cependant une nouvelle question qui se pose, entraînée par la distinction conceptuelle entre caractère et glyphe que le modèle de texte de TEX a
introduite. Désormais, la distinction entre l’unité du modèle visuel (le glyphe)
et l’unité du modèle d’échange (caractère) permet une différence en granularité entre les deux modèles : une unité pertinente visuelle peut en théorie
représenter plusieurs unités pertinentes d’échange et vice versa. Ces types de
correspondances multiple-à-un, voire multiple-à-multiple, peuvent se manifester dans la typographie latine (ligatures, lettres accentuées composées) mais
aussi dans de nombreuses écritures orientales où les signes d’écriture peuvent
être assemblés à partir de traits élémentaires (un tel procédé est envisageable
pour l’arabe, le nastaliq mais aussi pour les caractères chinois). Cependant, un
tel écart entre modèle d’échange et modèle visuel n’est pas envisageable dans
le cadre du modèle de texte de TEX, et il n’est pas prévu non plus dans les définitions données par Haralambous et évoquées dans le paragraphe précédent.
C’est entre autres ce problème particulier qui mènera plus tard à la conception d’un nouveau modèle de texte où la séparation entre caractère et glyphe
devient encore plus prononcée, adopté par la norme de codage de caractères
Unicode et par la plupart de logiciels PAO modernes.
En résumé, ce que nous venons de démontrer dans la présente section
est que la distinction entre les concepts de caractère, de glyphe et de signe
typographique a une réalité à la fois théorique et pratique. En même temps
il paraît évident qu’une relation étroite existe entre les trois concepts, une
35
Comment décider
la « typographicité »
d’un signe ?
Dériver le caractère
à partir du signe
typographique
Correspondances
entre caractère(s) et
glyphe(s)
relation qui n’est cependant pas facile à circonscrire de manière précise. Un
des objectifs majeurs de la présente thèse est de concevoir une méthodologie
bien fondée et cohérente qui permette de définir de manière plus exacte les
concepts mentionnés ainsi que les traits qui les distinguent.
LE
« Boîtes » et « ressorts »
Le nœud
Types de nœud
La création des nœuds
de caractère
NŒUD
: UNITÉ
TEXTUELLE INTERNE DE
TEX
Le processus de formatage effectué par TEX ne peut bien évidemment pas
être réduit à une simple conversion de codes de caractère en codes de glyphe.
À l’intérieur de TEX, on trouve encore un nouveau modèle textuel, un modèle opérationnel à travers lequel le texte de sortie est généré. L’idée est de
représenter le texte par des boîtes connectées par des ressorts où les boîtes
correspondent aux mots (ou à des blocs quelconques) ayant une hauteur et
une largeur fixe (qui dépend de la taille des glyphes qui y sont contenus),
et les ressorts correspondent aux espaces inter-mots, inter-lignes, inter-blocs,
etc. Les ressorts (« glue » en anglais) se contractent et se dilatent, chacun selon
ses propriétés quantifiées, pour remplir une ligne, une colonne, un bloc, une
page, etc., de manière optimale. L’optimalité est quantifiée à l’aide de pénalités qui augmentent en fonction de la différence de contraction ou de dilatation
du ressort par rapport à son état neutre.
Au niveau implémentationnel, l’unité textuelle de ce modèle n’est ni le caractère, ni le glyphe, mais une sorte de conteneur général qui s’appelle nœud
et qui peut représenter une grande variété d’objets et d’informations textuelles
comme les boîtes mentionnées, les glyphes dans les boîtes, les ressorts et
les pénalités. Le nœud est une structure de données typée selon sa fonction
textuelle : un nœud de caractère contient un glyphe, un nœud de ligature
contient un glyphe de ligature et ses composantes, un nœud de boîte contient
une liste de nœuds (glyphes, ressorts, etc.) emboîtés, un nœud de glue correspond à un ressort inséré dans le texte entre deux boîtes, un nœud de pénalité
est une valeur de pénalité qui s’active si une ligne de texte est coupée à l’endroit où il se trouve, et ainsi de suite. Le texte consiste en une liste de nœuds
où les boîtes permettent l’imbrication de listes dans d’autres ; ainsi, la liste de
nœuds n’est pas linéaire, elle suit une structure arborescente.
Que se passe-t-il lorsqu’un texte en caractères est lu par TEX ? Après une
première étape d’interprétation des commandes dans le document d’entrée,
TEX construit les listes de nœuds sur lesquelles s’effectuera la grande majorité
des tâches de composition et de mise en page. Pour ce faire, TEX consulte
les fontes afin d’en retirer les codes de glyphe correspondant aux caractères.
Chaque nouveau glyphe est représenté par un nœud de caractère dont le nom
reflète, encore une fois, le fait que Knuth n’a pas fait de distinction terminologique entre caractère informatique et caractère typographique. Le cas des
ligatures (et ceci comprend tous les glyphes qui se composent à partir de plusieurs caractères, comme le tiret cadratin) est une exception : elles ont leur
propre type de nœud, le nœud de ligature.
Le nœud de caractère est une structure simple qui réfère au glyphe par un
identifiant de fonte et par un identifiant de glyphe à l’intérieur de cette fonte.
Les codes de caractère d’origine ne sont pas présents dans les nœuds de caractère. Pourquoi le seraient-ils ? TEX construit les listes de nœuds pour effectuer
36
du formatage typographique sur le texte, et pour ce faire, il fait recours à son
modèle de texte typographique basé sur les codes de glyphe uniquement.
DU
GLYPHE AU CARACTÈRE
: LA
CÉSURE
Il y a cependant une opération lors du traitement effectué par TEX qui ne
peut être considérée comme une opération purement typographique : la césure des mots. La césure est une opération principalement linguistique, même
si elle a également des aspects présentationnels. Lorsqu’un paragraphe est divisé en lignes, TEX a besoin de connaître les endroits où les mots peuvent être
coupés. Il s’avère cependant qu’un modèle de texte orienté à l’usage typographique, comme le modèle de TEX, n’est pas bien adapté à l’analyse linguistique
car les unités sémantiques que représentent les signes typographiques ne sont
pas toujours pertinentes du point de vue linguistique. Pour s’en convaincre,
il suffit de penser aux ligatures (un seul signe typographique représente plusieurs graphèmes) ou aux lettres accentuées qui sont modélisées dans TEX par
des glyphes séparés où le glyphe d’accent se positionne par rapport à la lettre
de base par des nœuds de déplacements horizontal et vertical insérés entre
les deux nœuds de caractère.
En même temps, il s’avère qu’un modèle de texte basé sur un codage de
caractères standard (comme ASCII) se prête mieux aux opérations linguistiques
car les entités sémantiques que représentent les caractères sont en pratique
plus proches des graphèmes linguistiques (car moins spécialisées à un usage
typographique), même si, comme nous avons vu en section 1.4.2, l’utilisation
d’un codage de caractères normalisé pour la représentation d’un texte (tel
qu’un corpus linguistique) en soi ne garantit pas l’indépendance d’application
et de plate-forme. (Par exemple, le codage ASCII ne contient pas de lettres
accentuées et, jusqu’à l’apparition de codages étendus, il n’existait pas de
moyen normalisé de les représenter. C’est d’ailleurs pour cette même raison
que TEX n’est pas capable de couper les mots accentués qui ont été introduits
dans un codage ASCII strict, par l’intermédiaire de commandes telles que \’a
pour « á », etc.)
Par conséquent, pour effectuer la césure, TEX aurait besoin de mémoriser
à partir de quels caractères les glyphes dans les nœuds de caractère ont été
générés. Pour la plupart des glyphes, TEX n’a pas besoin de procéder ainsi,
pour la simple raison que le codage de glyphes qu’il utilise est construit de
manière que les codes de glyphe soient égaux aux codes de caractère correspondants. Quant aux ligatures, TEX est capable de reconstituer les caractères
correspondants grâce au nœud de ligature qui pour chaque ligature stocke la
liste de caractères à partir desquels la ligature a été composée.
L’exemple de TEX nous montre de nouveau que l’information textuelle peut
être modélisée de différentes manières et que le modèle choisi dépend de
l’usage donné. Cependant, certaines tâches complexes comme la composition
et la mise en page typographique peuvent intégrer plusieurs usages (typographique, linguistique, etc.) et, par conséquent, nécessitent l’utilisation parallèle
ou alternée des différents modèles textuels correspondants. La coexistence et
l’utilisation de plusieurs modèles est donc une nécessité inévitable lorsque
les modèles individuels ne sont pas suffisants pour décrire l’information textuelle dans sa complexité. Dans la suite de cette thèse, la problématique de la
37
Le texte en caractères
convient mieux
aux opérations
linguistiques
que le texte en glyphes
Retour depuis le glyphe
vers le caractère
La complémentarité
du caractère et
du glyphe
concurrence de modèles de texte restera un de nos sujets majeurs. Dans le présent chapitre nous analyserons les difficultés de la conversion entre modèles
correspondant aux différents usages, alors que dans le chapitre suivant nous
verrons comment et jusqu’à quel point il est possible de concevoir un modèle
de texte unique qui soit capable d’accomoder plusieurs usages textuels à la
fois.
1.5.2 L E
LANGAGE ET LES FONTES P OSTS CRIPT,
LA NOTION DE NOMMAGE DE GLYPHES
L’émancipation du glyphe en tant qu’entité autonome par rapport au caractère a continué avec le développement du langage de description de pages
PostScript — et plus particulièrement de son modèle de texte — en 1984
[3]. Avec la hausse de popularité des imprimantes graphiques, d’abord matricielles, puis au laser et à jet d’encre, le langage PostScript s’est vite imposé
en tant que norme de description de pages intégré dans les imprimantes. La
raison de ce succès est claire : PostScript permet de décrire un document quelconque, qu’il s’agisse de texte ou de graphique, en tant qu’image vectorielle.
Grâce à cette description vectorielle, le même document PostScript peut être
imprimé sur n’importe quelle imprimante, indépendamment de sa technologie
(traceur, matricielle, laser, etc.) et de sa définition. Afin d’étendre sa portée à la
description de documents textuels, PostScript se sert du concept de fontes vectorielles où les glyphes individuels sont décrits à l’aide de courbes de Bézier.
En réalité, PostScript n’était pas le premier à proposer une description vectorielle de glyphes : aussi bien le système Metafont de Knuth qui accompagnait
TEX que le système IKARUS9 développé par la société URW avaient précédé
PostScript par au moins cinq ans. La véritable nouveauté de PostScript était
plutôt de devenir une norme de facto de l’impression et d’ainsi révolutionner
la création de documents électroniques.
NOMMAGE
DE GLYPHES
Dans la section précédente, nous avons distingué entre textes — et donc
entre documents — « d’entrée » et « de sortie », ces derniers étant orientés présentation. Les documents PostScript se situent du côté présentationnel. Le texte
contenu dans un document PostScript est composé d’une suite de glyphes positionnés sur un plan. Une des nouveautés introduites par PostScript est le système de nommage qui sert à identifier, de manière unique, les glyphes d’une
fonte par l’intermédiaire d’une chaîne de caractères : le nom de glyphe. Bien
que la famille de normes PostScript incorpore de nombreux formats de fonte,
la manière de coder les glyphes par l’intermédiaire du nom de glyphe leur est
commune (à l’exception des fontes CID).
Codage de glyphes
Le codage de glyphes contenu dans la fonte PostScript consiste à créer une
à travers les noms table de correspondances entre des nombres entiers et un sous-ensemble des
noms de glyphe parmi les glyphes disponibles dans la fonte. Une fonte PostScript peut contenir jusqu’à 65 536 glyphes (ressources vectorielles), chacun
9
Qui a apparemment été nommé ainsi grâce aux nombreux plantages qu’il a produit lors de
son développement initial.
38
d’eux associé à un nom de glyphe, mais une table de codage ne peut contenir que 256 entrées. En revanche, il est possible de définir plusieurs codages
pour la même fonte, ce qui permet non seulement l’adaptation de la fonte
à plusieurs situations linguistiques mais aussi l’accès à la totalité de glyphes
contenus dans la même fonte lorsque leur nombre dépasse 256.
L’intérêt d’étiqueter un glyphe par une chaîne de caractères au lieu d’une
valeur numérique arbitraire (comme dans les fontes TrueType, par exemple)
devient plus clair si l’on admet que le premier a plus de potentiel de servir comme identifiant sémantique du glyphe, autrement dit, d’interpréter le
glyphe en renvoyant vers un signe typographique (en tant qu’entité sémantique). En supposant l’existence d’une convention de nommage, d’un répertoire de noms défini indépendamment des fontes, un document PostScript devient capable d’associer une sémantique typographique au texte qu’il contient,
sans contraindre les codages des fontes utilisées (ce qui est un avantage par
rapport à TEX), à condition bien sûr que les noms de glyphe soient choisis de
manière pertinente.
TEX avait réalisé la « sémantisation » de ses codages de glyphes par l’emploi de codages « figés » où la sémantique (le signe typographique) associée à
chaque code numérique était fixée. Dans le cas de PostScript, c’est le nom de
glyphe et non pas le code numérique qui renvoie à la valeur sémantique. Les
deux solutions ne sont pas équivalentes pour les raisons suivantes.
– Une chaîne de glyphes en tant que suite de codes numériques ne « fait
sens » que lorsque le codage TEX est connu. Ce n’est pas le cas de PostScript où les codes ne portent aucun sens. Il en suit qu’un texte PostScript n’est interprétable que si la table de correspondances entre codes
et noms de glyphes est disponible.
– Dans TEX, l’ensemble de signes typographiques codés (et par conséquent, les signes que l’on peut utiliser dans ses documents) est un ensemble fermé défini par les codages de glyphes privés. L’utilisation de
nouveaux signes typographiques, inconnus par TEX, n’est possible qu’au
prix d’abandonner ces codages, ce qui amène à la « dé-sémantisation »
du texte. En revanche, PostScript permet d’assembler son propre codage
de fonte à l’aide des noms de glyphes.
– Les codages de TEX sont établis par convention, et l’extension du codage par de nouveaux signes n’est possible que par l’abandon de cette
convention. La même chose peut être dite de la convention de nommage, c’est-à-dire de l’ensemble de noms disponibles ; cependant, un
nom en tant que chaîne de caractères peut être schématisé, structuré, il
peut offrir des moyens plus souples de créer de nouveaux noms. Pour
prendre un exemple concret, le caractère « . » (point) est souvent utilisé comme séparateur entre la partie principale du nom et un suffixe :
le nom eacute.swash peut désigner une lettre é minuscule avec une
forme allongée, alors que eacute.narrow peut désigner la même lettre
avec une forme étroite. Suivant ce schéma, il devient possible de créer
un nouveau nom pour une nouvelle forme de la lettre « é » tout en indiquant dans la partie principale du nom devant le point qu’il s’agit bien
de la même lettre « é ».
– A priori, la taille d’un codage (le nombre de codes disponibles) est tou39
Le nom de glyphe
en tant qu’identifiant
sémantique
Le nom de glyphe peut
avoir une structure
jours bornée par des limitations techniques ou autres ; cette borne fait
partie de la convention mentionnée. L’ensemble de noms de glyphes
n’est limité par aucune borne pratique, il peut être étendu sans que
l’augmentation de noms disponibles cause le moindre problème technique.
ISO/IEC 10036 : UN
Efforts de normalisation
pour le codage
des signes
typographiques
Les raisons de l’échec
d’ISO 10036
NOMMAGE DE GLYPHES UNIVERSEL
La notion de nommage de glyphes proposée par PostScript, couplée avec
l’idée d’une convention de nommage globale et indépendante de fonte et de
format de document, avait donc tout potentiel de donner naissance à un codage de glyphes universel normalisé, permettant d’associer de la sémantique
typographique aux images graphiques contenues dans les fontes et dans les
textes informatiques formatés. Ceci aurait pu mener à un modèle textuel informatique à deux niveaux, avec d’un côté la représentation d’échange, basée
sur les caractères dont la sémantique est véhiculée par le codage de caractères
et le contexte d’usage (CU ), et de l’autre côté la représentation finale, basée
sur les glyphes dont la sémantique est définie par la convention de nommage.
Dans les années 1980, l’intérêt de créer des documents typographiés multilingues devenait de plus en plus grand, alors que les normes de codages
de caractères nationaux — qui venaient d’être créés, voir section 1.6.1 —
n’étaient en général pas adaptées à l’usage typographique. Le « climat était
donc favorable » à la normalisation d’un modèle de texte alternatif, basé sur le
signe typographique. Adobe, le concepteur de PostScript, a publié une proposition de convention de nommage appelé Adobe Glyph List (dont la version
la plus récente, qui date de l’an 2002, contient 4 283 noms de signes typographiques venant de diverses écritures du monde [4]). Un effort similaire, visant
à répertorier les signes typographiques, était la norme ISO/IEC 10036, créé
en 1993 [36]. Quant à cette dernière, l’inclusion de nouveaux signes dans
le répertoire se faisait sur simple demande d’enregistrement, une procédure
nettement plus simple que la moindre modification d’une norme de codage
de caractères. L’organisme initialement en charge de la gestion du répertoire
était nommé AFII (Association for Font Information Interchange). L’identification des signes typographiques se faisait à travers des identifiants numériques
uniques. Les noms PostScript des glyphes dans les fontes se construisaient en
se basant sur les mêmes identifiants, préfixés par « afii ».
Contrairement aux attentes, le nombre d’entrées dans le répertoire géré
par l’AFII n’a guère augmenté durant les années suivant la mise en place du
répertoire, signe d’un désintérêt général, mettant en doute l’utilité du principe
de nommage universel. Pourquoi l’idée d’un répertoire global de signes typographiques n’est-elle pas devenue populaire ? Le succès du modèle de texte
basé sur le répertoire global d’ISO 10036 dépendait de son adoption ou non
par l’industrie, y compris les créateurs de logiciels de traitement de texte ainsi
que les créateurs de fontes ; or,
– la technologie PostScript n’était pas le seul prétendant du marché, et
les adversaires tels que Microsoft et Apple, développeurs du format de
fonte TrueType, ont choisi de ne pas adopter un modèle de texte basé
40
sur le nommage de glyphes10 ;
– Adobe n’a jamais eu l’intention de supplanter les noms contenus dans
sa Glyph List par les identifiants AFII (à part environ deux cent entrées
pour le cyrillique, l’hébreu et l’arabe) ;
– les créateurs de fontes, majoritairement artistes plutôt qu’ingénieurs, ne
voyaient pas d’intérêt à compliquer leur travail en s’obligeant de donner
aux glyphes dessinés des noms aussi peu parlants et pénibles que les
identifiants AFII.
Le coup de grâce à ISO 10036 a été délivré par le codage de caractères ISO 10036 contre
Unicode, apparu en 1990-1991 (deux ans avant ISO 10036), qui a permis de Unicode
surmonter la barrière de la pénurie de points de code disponibles et qui a
proposé pour de nombreuses écritures un moyen de représentation textuelle
jusqu’alors impossible. En théorie, Unicode et ISO 10036 étaient censés servir
deux objectifs bien distincts, notamment de définir les atomes textuels des représentations d’échange pour l’un et de formatage pour l’autre. La raison d’être
de la normalisation des signes typographiques était justement le principe selon lequel l’aspect graphique des signes ne doit pas concerner le codage de
caractères, ce dernier n’étant intéressé que par leurs aspects sémantiques. Cependant, le Consortium Unicode ne s’est jamais montré sévère vis-à-vis de
l’inclusion dans la norme des caractères non conformes à cette règle, surtout
que la distinction entre aspects graphiques et sémantiques s’est avérée souvent
très ambiguë. (Nous allons élaborer ce problème dans une section dédiée à
Unicode.) Avec l’inclusion de de plus en plus de caractères dans Unicode,
l’intérêt de maintenir un répertoire sémantique parallèle s’est diminué [68]. Le
cas des caractères « logographiques »11 du chinois, du japonais et du coréen
est un bon exemple de ce phénomène : le répertoire logographique d’Unicode est en expansion constante, et avec l’inclusion de chaque nouveau caractère, son clone d’ISO 10036 devient obsolète. Néanmoins, dû à la nature
ouverte de l’ensemble des signes logographiques — de nouveaux caractères,
qui très souvent dénotent des noms propres, peuvent apparaître du jour au
lendemain —, le processus lent et complexe de l’extension d’Unicode met en
évidence la nécessité d’une méthode alternative de représentation normalisée
de signes typographiques. Ce n’est pas par hasard que la gestion du catalogue
d’ISO 10036, après la dissolution de l’AFII, a été reprise par GLOCOM, un
organisme japonais.
LE
NOM DE GLYPHE EN TANT QUE RÉFÉRENCE AU CARACTÈRE
La montée en importance d’Unicode en tant que moyen unique de repré- Le caractère comme
senter le contenu textuel a entraîné l’abandon de l’idée d’une sémantisation porteur exclusif
alternative du texte à travers les noms de signes typographiques. Par consé- de sémantique
quent, l’usage des noms de glyphes PostScript a également changé d’objectif :
10
Certes, le format TrueType permet d’associer des noms PostScript aux glyphes mais pour
l’unique but de rester compatible avec les pilotes PostScript des imprimantes.
11
« Caractère » est le terme le plus souvent utilisé dans un contexte non-informatique pour
désigner les signes d’origine chinoise. Puisqu’il y a danger de confondre ce sens spécial avec
celui du caractère informatique, nous préférerons le terme logogramme, même si l’usage de
celui-ci est également fortement débattu [26, p. 111] à cause de son imprécision descriptive
vis-à-vis de la relation sémiotique représentée par les éléments de l’écriture chinoise.
41
FIG. 1.3 – À gauche : le logogramme chinois zhào se décompose en trois composants (soleil, lune, ciel) qui, à leur tour, peuvent être décomposés davantage,
même jusqu’aux traits élémentaires. À droite : une décomposition possible de
la lettre arabe noun médian en deux traits élémentaires et un lozenge.
dès lors, le nom servait non pas à identifier un signe typographique tel quel
mais à faire référence au (ou aux) caractère(s) informatique(s) représenté(s)
par le signe. La sémantique vers laquelle renvoie un nom (par exemple, le
nom f_i) n’est donc pas principalement un signe typographique particulier
(une ligature fi romaine) mais plutôt un caractère ou une suite de caractères
(un caractère f suivi par un caractère i). Pour prendre un exemple plus à
jour par rapport aux usages actuels, le nom de glyphe uni0644.fina précise
qu’il s’agit d’un glyphe correspondant au caractère lam arabe, codé en position hexadécimale 0644 par le codage Unicode (section 1.8). Le suffixe fina
peut éventuellement donner une information supplémantaire — dans notre
cas, qu’il s’agit de la forme finale de la lettre lam — mais l’information contenue dans le suffixe reste inexploitable en pratique, comme nous verrons toute
à l’heure.
Cet usage particulier du nommage de glyphes n’est devenu important que
depuis la fin des années 1990, sa cause principale étant l’apparition d’Unicode et des documents interactifs dont nous parlerons en détail en sections 1.8
et 1.7 respectivement. Il faut néanmoins se rendre compte que cet usage du
nom de glyphe représente un choix conceptuel de grande envergure : la sémantique explicitement portée par les éléments d’un texte électronique formaté se limite désormais à la sémantique portée par un codage de caractères.
En d’autres termes, l’ordinateur ne peut plus interpréter un texte PostScript
qu’à travers la chaîne de caractères qui a servi à le créer. Même si en théorie,
comme dans l’exemple ci-dessus, il reste possible de représenter de multiples
informations dans le suffixe du nom de glyphe, il n’existe cependant aucune
norme ni convention aujourd’hui pour décrire l’interprétation de ces informations. Par conséquent, elles sont ignorées par les applications dans la majorité
des cas.
Un problème inhérent
La méthode qui permet d’établir des correspondances un-à-un (cas tydu nom de glyphe pique) et un-à-multiple (cas des ligatures) entre glyphes et caractères à travers
qui réfère au caractère les noms de glyphe souffre également d’un autre problème conceptuel : elle
n’est pas capable d’exprimer des correspondances multiple-à-un, c’est-à-dire
42
où plusieurs glyphes représentent un seul caractère. C’est le cas lorsqu’une
lettre accentuée est décomposée en glyphe de base et glyphe de marque. De
manière plus générale, rien ne garantit que l’ensemble des signes élémentaires
d’un modèle typographique appliqué à une écriture donnée possède la même
granularité que l’ensemble de caractères de cette même écriture. Dans le cas
des écritures comme le chinois, l’arabe ou plus particulièrement le nastaliq,
il existe des solutions typographiques où les unités naturelles et intuitives de
l’écriture — auxquelles correspondent les caractères informatiques — sont assemblées à partir de composants élémentaires (voir figure 1.3) ; ou en d’autres
termes, l’unité pertinente graphique est plus petite que l’unité pertinente linguistique. Lorsqu’un glyphe représente une telle unité inférieure et peut potentiellement participer à la construction de plusieurs signes, il ne correspond
en soi à aucun caractère précis, et pour cette raison ne peut être identifié par
un nom de glyphe renvoyant vers un caractère.
Les exemples ci-dessus nous ouvrent la perspective vers des considérations
qui dépassent les cadres établis par l’histoire occidentale de l’informatique :
avec l’adoption de l’ordinateur au monde entier, le besoin de communiquer
à travers l’ordinateur dans sa propre langue, en utilisant sa propre écriture est
devenu de plus en plus important. D’une part, le codage de caractères ASCII
n’était capable de représenter qu’une petite fraction des langues du monde.
D’autre part, les fontes et les logiciels qui effectuaient des opérations textuelles
n’étaient pas adaptés aux particularités des écritures non-alphabétiques. Face
aux nouveaux usages, il était à nouveau question de reconsidérer les modèles
de texte utilisés.
1.6 L’ASPECT MULTILINGUE DU TEXTE INFORMATIQUE
L’utilisation de l’ordinateur ne s’est bien évidemment pas répandue en
même temps et à la même échelle dans le monde, non seulement à cause
des différences de niveau de développement technologique entre pays mais
aussi à cause de raisons culturelles, linguistiques, économiques et même politiques. Notamment, un problème particulier qui a souvent ralenti l’adoption
de certains usages des systèmes informatiques dans un pays par rapport à un
autre était l’incompatibilité de l’écriture de ce pays avec le modèle informatique (le codage de caractères, le fonctionnement des fontes, etc.) proposé par
les systèmes faits sur mesure pour la langue anglaise uniquement. Du point
de vue technique, c’étaient peut-être les pays de l’Europe de l’Ouest qui ont
eu le moins de mal à adapter leurs plates-formes informatiques aux besoins de
leurs propres langues et écritures, grâce à l’alphabet latin commun.
Avant d’examiner des exemples concrets, énumérons les composants d’un
système12 informatique concernés par la modélisation textuelle :
– le clavier à travers lequel on introduit le texte ;
– le codage de caractères employé par le système ;
– les fontes disponibles et leur fonctionnement ;
12
Il s’agit bien de systèmes informatiques car on ne peut pas parler d’adaptation à une langue
ou écriture donnée sans que chaque composant du système n’y soit adapté.
43
Le clavier
Le codage de caractères
La fonte
Le logiciel
– les méthodes de formatage de texte à plusieurs niveaux d’usage (affichage simple, traitement typographique, etc.).
Dans les cultures alphabétiques, l’adaptation du clavier de l’ordinateur n’a
en général pas posé de soucis particuliers grâce à la tradition des machines
à écrire. Très souvent, l’organisation des touches des machines à écrire traditionnelles a été reprise à l’identique pour l’ordinateur, étendue par quelques
touches supplémentaires (dont la fonction était plutôt le contrôle de l’ordinateur que l’introduction de nouveaux signes). Le revers de la médaille est
que la gamme de signes disponibles sur les claviers des machines à écrire
était très restreint, et le clavier de l’ordinateur a hérité de cet inconvénient.
(Pour prendre l’exemple du clavier français, pensons au manque de lettres
comme œ, Œ, les guillemets, pour ne pas mentionner les signes typographiques comme les tirets variés.)
L’adaptation du codage de caractères à l’écriture d’une langue donnée est
un problème délicat de plusieurs points de vue. Tout d’abord, le codage de
caractères étant un moyen d’échange d’informations textuelles, il est essentiel
pour tout codage de caractères d’être normalisé à un niveau géographique
le plus large possible, étant donné l’importance de l’interopérabilité entre
systèmes informatiques, même entre pays différents. Lorsque de nombreuses
langues sont forcées de se faire la concurence pour un nombre très restreint
de points de code disponibles (ce qui était le cas, entre autres, des pays de
l’Europe de l’Ouest et le codage ISO 8859-1), parfois les rapports de force et
la diplomatie peuvent prévaloir sur les conventions nationales linguistiques et
typographiques [9]. Les véritables difficultés pour définir un codage de caractères bien adapté à une écriture ou même à une langue donnée sont cependant scientifiques et technologiques. Nous aborderons ce sujet en détail dans
la section 1.6.1.
Historiquement, la fonte est un concept de la typographie au plomb traditionnelle. De plusieurs points de vue, les fontes informatiques des années
1970, 1980, voire 1990, imitaient le fonctionnement et les propriétés des
fontes traditionnelles ; par conséquent, elles étaient tout aussi inadaptées à
la composition d’écritures non-alphabétiques (telles que l’arabe) que leurs antécédents mécaniques. Nous consacrerons à ce sujet la section 1.6.2.
Finalement, ayant modifié les normes et les ressources, il faut adapter le
logiciel, y compris les systèmes d’exploitation et les applications, sur tous leurs
niveaux concernés par la gestion de données textuelles.
1.6.1 CODAGES DE
CARACTÈRES NATIONAUX
La première tentative d’internationaliser le codage ASCII — irrémédiablement latino- et anglocentrique — était la norme ISO 646 [28] qui consistait à
remplacer, pour une poignée de langues, quelques 18 caractères de l’ASCII par
des caractères spécifiques à chacun des langues. Les 7 bits de l’ASCII étaient
cependant trop serrés pour une couverture complète des langues concernées,
et pour cette raison les codages ISO 646 n’ont pu être qu’une solution temporaire. Similairement, la norme ISO 2022, qui permet la création pratiquement
illimitée de nouveaux codages ainsi que de basculer entre ces codages dans
le même texte à l’aide de séquences d’échappement [28, p. 33-34], a égale44
ment été destinée à l’abandon à cause des difficultés techniques qui lui étaient
caractéristiques (l’impossibilité de décider la sémantique d’un caractère sans
parcourir et interpréter la chaîne entière, l’irréalité qu’un système informatique
supporte la totalité de codages adressés par la norme).
À partir de 1986, l’ISO a défini un ensemble de codages internationaux
à 8 bits. L’ajout du huitième bit a rendu disponibles 128 nouveaux points de
code dont 96 ont été associés à de nouveaux signes d’écriture (le reste étant réservé pour des caractères de contrôle). 16 différentes tables de codage ont été
définies par l’ISO, nommées ISO 8859-1 jusqu’à ISO 8859-16, pour les écritures latine, cyrillique, arabe, hébreu, grec, thaï. La couverture de ces écritures
est souvent très rudimentaire (voir [28, p. 34-41] pour un résumé des défauts
et omissions majeures), en partie parce que les 96 points de code disponibles
(128 moins 32 points de code réservés pour des caractères de contrôle) ne
sont pas toujours suffisants pour représenter la richesse des écritures en question, en partie à cause d’éventuelles choix discutables entre signes compris et
non-compris dans la norme.
Pour comprendre l’ampleur des obstacles contre lesquels l’ISO a dû se
heurter, rappelons-nous que les premiers modèles textuels informatiques ont
été conçus en Occident, fortement inspirés d’usages antérieurs comme la typographie à plomb, la machine à écrire, les technologies de télécommunication
telles que le télégraphe, le télex, et ainsi de suite. Du point de vue linguistique, le concept de caractère — tel qu’il est utilisé par les codages ASCII et
ISO 8859 — reflète les particularités de l’écriture latine et des usages mentionnés : il est conceptuellement similaire au graphème de la linguistique occidentale, qui à son tour est (directement ou indirectement) lié au phonème13 .
D’autre part, d’un point de vue graphique, les graphèmes de l’écriture latine se
prêtent facilement à une approche par découpage « atomiste » du texte car ils
se distinguent facilement à force d’être graphiquement séparés. Ces trois particularités — historique, linguistique et graphique — font que la conception
d’un codage de caractères pour l’écriture latine s’est réalisée de la manière
dont on le connaît aujourd’hui.
Or, les particularités mentionnées ci-dessus ne sont pas forcément partagés par toutes les autres écritures du monde. Dans l’histoire de nombreuses
écritures, les traditions typographiques — qui pourraient suggérer des segmentations potentielles — ont été moins importantes (c’est par exemple le cas de
l’arabe). Une approche linguistique à la segmentation d’une écriture donnera
des résultats remarquablement différents pour des écritures phonographiques
(latin, grec, cyrillique, etc.), consonantiques (arabe), syllabiques (les kana japonais), alphasyllabiques (les écritures indiennes) ou morphémiques (chinois) :
le nombre de segments linguistiques unitaires peut varier entre une vingtaine
et des centaines, voire des dizaines de milliers pour le chinois14 . D’ailleurs, si
l’on prend en considération les diverses variantes de la même écriture adaptées à de différentes langues, le nombre de segments se multiplie davantage.
13
Nous écartons ici, juste pour ce propos, la considération des signes de ponctuation et
d’autres signes non-phonémiques.
14
Le nombre de logogrammes chinois nécessaires pour la communication écrite dépend bien
évidemment de nombreux facteurs ; par conséquent, souvent on exprime ce nombre en fonction du pourcentage de la totalité d’usages possibles : par exemple, quelques 7 000 caractères
couvrent 99,99% des usages [26, p. 264].
45
ISO 8859
Le caractère est
un concept occidental
Différences
conceptuelles entre
écritures
En même temps, la segmentation graphique de certaines écritures connectées (comme l’arabe ou le nastaliq, écriture traditionnelle de l’Iran) est loin
d’être évidente d’un point de vue typographique, même si, bien entendu, leurs
lecteurs distinguent leurs éléments constitutifs très facilement. Ou bien, pour
prendre l’exemple du chinois où la séparation graphique entre les éléments
de l’écriture est très nette, il est loin d’être clair que cette segmentation intuitive soit la plus efficace dans un contexte informatique, par rapport à une
segmentation plus fine en composantes, voire en traits élémentaires.
Ces considérations mettent en évidence le fait que le modèle informatique
extrêmement simple conçu pour l’écriture latine, où une touche de clavier
correspond à un caractère qui est équivalent à un graphème de l’écriture, ne
peut être automatiquement appliqué à toutes les autres écritures du monde.
Le (ou les) modèle(s) informatique(s) doivent être étendus pour que des correspondances un-à-multiple, multiple-à-un et même multiple-à-multiple entre
frappes de clavier et caractères stockés, puis entre caractères et glyphes affichés, soient possibles. (Ce dernier est d’ailleurs également nécessaire pour
une composition typographique de bonne qualité pour l’écriture latine, notamment pour les ligatures, les lettres accentuées, etc.)
Les avantages
En même temps, il faut admettre que la simplicité d’introduire, de traiter
d’une modélisation et d’afficher chaque élément textuel de manière indépendante est un grand
simple avantage du point de vue de l’interface homme-machine, alors qu’un mo-
dèle textuel qui établit des correspondances plus complexes entre touches de
clavier, caractères et glyphes affichés pose forcément des difficultés non pas
seulement pour le développeur d’une application quelconque qui est censée
afficher le moindre fragment de texte, mais aussi pour l’utilisateur qui, afin
de comprendre le fonctionnement du système, doit être capable d’adopter un
regard abstrait et analytique sur sa propre écriture. Traduire cette complexité
inhérente du modèle de texte en une interface utilisateur de saisie et de manipulation simple et conviviale est un véritable défi conceptuel. Nous n’aborderons pas cet aspect de la modélisation dans cette thèse ; néanmoins, nous
tenons à remarquer que, même si les traits majeurs des interfaces de haut niveau sont dépendants du modèle de texte de bas niveau, cette dépendance
peut être rendu indirecte par la conception des premières.
Dans la section suivante, mais toujours dans un contexte multilingue et
multi-écritures, nous allons nous intéresser aux modèles visuels dont le but
est de décrire le texte dans sa forme de représentation finale (ou formatée).
À travers des exemples d’écritures non-latines, nous allons voir comment le
texte en caractères se transforme en texte en glyphes. Lors du chapitre suivant,
ces exemples nous serviront également pour voir comment le modèle de texte
que nous proposons s’adapte aux particularités des différentes écritures par
rapport au modèle caractère-glyphe, généralement adopté aujourd’hui.
Pour des raisons historiques et de similarité conceptuelle entre le modèle
typographique traditionnelle et les modèles visuels informatiques, il ne relève
Qui dit visualisation pas d’imprécision de parler de typographie au lieu de visualisation : toute
dit typographie visualisation informatique de texte, qu’elle soit simple ou élaborée, relève
forcément d’une approche typographique.
46
1.6.2 T YPOGRAPHIE ET TRAITEMENT DES
NON - ALPHABÉTIQUES
ÉCRITURES
Nous avons déjà évoqué le fait que les différentes cultures ont eu des traditions typographiques plus ou moins importantes dans leur histoire. Très souvent, les réserves de la part d’une culture envers l’adoption d’une technologie typographique gutenbergienne — qui consiste donc à modéliser l’écriture
en la segmentant en signes typographiques individuels — étaient dues à l’incompatibilité entre ce modèle et les particularités graphiques de l’écriture en
question. Tel était le cas, entre autres, de l’arabe, une écriture connectée aux
tendaces très calligraphiques qui, par conséquent, ne se laissait pas facilement
diviser en signes typographiques élémentaires. Tel était également le cas du
chinois, mais pour une raison complètement différente : là, c’était le nombre
élevé de logogrammes qui a rendu impratique l’approche typographique.
L’arrivée de l’ordinateur a donné une nouvelle chance à ces écritures, une L’ordinateur bouleverse
nouvelle possibilité de s’approprier un modèle typographique plus proche les pratiques
de leurs propriétés graphiques, une fois libérées des contraintes matérielles typographiques
propres à la technologie au plomb. (Ce qui ne veut bien évidemment pas dire
que l’ordinateur ne leur a pas imposé d’autres types de contraintes technologiques.) Le potentiel était présent mais inexploité jusqu’aux années 1980,
voire 1990, pour de nombreuses raisons dont la dominance technologique de
l’Ouest n’est peut-être pas la moins importante. Avec la « démocratisation » de
l’informatique et l’apparition du PC et de ses clones partout dans le monde
(au début, sans le moindre effort de la part des producteurs de localiser les
logiciels et les dispositifs), des solutions locales au problème d’informatiser
les différentes écritures ont commencé à émerger, plus souvent de manière
bottom-up, grâce à des développeurs individuels, que dans le sens inverse. La
technologie que les développeurs de ces solutions ont due exploiter comprenait des claviers, des codages de caractères et des formats de fonte adaptés à
l’écriture latine et aux langues occidentales. Dans ces conditions, et faute de
normes nationales ou internationales, les solutions étaient ad hoc et mutuellement incompatibles (voir par exemple l’étude de cas concernant le khmer
dans [60]), souvent développées par des entreprises pour le fonctionnement
d’un logiciel précis, pour ensuite faire partie de la multitude de normes de
facto présentes sur le marché.
Dans le cadre de la présente thèse, il n’est malheureusement pas possible
de fournir une analyse exhaustive des particularités inhérentes aux différentes
écritures du monde, ni même pour une seule. L’approche que nous adoptons
consiste à présenter quelques exemples qui illustrent par la pratique les besoins auxquels est censé répondre un modèle de texte qui se veut global.
L’ÉCRITURE
ARABE
Du point de vue linguistique, l’arabe est une écriture consonantique qui
prévoit cependant l’indication des voyelles à l’aide de marques au-dessus ou
au-dessous des consonnes [19]. Du point de vue graphique, l’arabe est une
écriture connectée qui se lit de droite à gauche. En partie à cause de sa nature Contextualité
connectée, les lettres possèdent plusieurs allographes selon leurs positions
dans les mots (initial, médian, final, isolé) ; suivant l’usage terminologique
47
courant dans l’informatique, nous appellerons celles-ci formes contextuelles
Dynamique arabes. Une autre conséquence de la cursivité de l’écriture est la liberté d’al-
longer les lettres même jusqu’à plusieurs fois leur largeur par défaut à des fins
d’égalisation de lignes [38] ou, surtout dans les textes religieux, pour une mise
en évidence sémantique. L’arabe emploie également un très grand nombre
de ligatures15 , dont certaines qui sont obligatoires et d’autres, optionnelles
Marques et de nature plutôt esthétique. Pour parler enfin des marques diacritiques de
l’arabe, celles-ci sont le plus souvent omises ; elles peuvent cependant être
présentes lorsque la non-ambiguïté du texte doit être assurée par le marquage
des voyelles (textes religieux, apprentissage de la langue arabe, désambiguïsation). Certaines parmi elles servent comme aide rhétorique dans les textes
religieux. De par usages très différents des marques de l’arabe par rapport
aux accents de l’écriture latine, leur abondance potentielle dans le texte et,
une fois de plus, la cursivité de l’écriture, il s’avère que le positionnement
des marques arabes par rapport aux lettres de base s’effectue de manière plus
souple, et donc plus complexe algorithmiquement, que le positionnement des
accents latins [13].
Parmi les propriétés mentionnées, une grande partie reste incompatible
avec les technologies basées sur les modèles de texte occidentaux :
Codage et fontes
– le codage de caractères arabe ISO 8859-6 (en partie héritier du modèle de la machine à écrire arabe) est un codage créé selon des principes à prépondérance linguistique (à l’opposition des principes typographiques) ; ainsi chaque consonne est représentée par un seul caractère, indépendamment de sa forme contextuelle. Par conséquent, lors de
la visualisation du texte, quatre glyphes différents peuvent correspondre
au même caractère, un phénomène que les mécanismes standard de
codage des formats de fonte PostScript et TrueType ne sont pas capables
de décrire.
Connexions curvilignes
– La dynamique de l’allongement des lettres et des connexions curvilignes
(kachidé) entre lettres est particulièrement difficile à imiter par le modèle typographique occidental qui divise l’écrit en atomes graphiques figés (les poinçons), disposés sur une ligne unidimensionnelle. Les fontes
classiques peuvent inclure des glyphes alternatifs à chasses variées et
des glyphes d’allongement (rectilignes et non curvilignes) mais, d’une
part, ceci ne peut donner qu’une approximation de la dynamique de
l’écriture arabe et, d’autre part, le même problème de codage se pose
par rapport aux glyphes alternatifs que par rapport aux formes contextuelles. Une solution différente est l’emploi de fontes dynamiques dont
le seul exemple de format existant est le Type 3 de PostScript. Celuici propose de décrire les glyphes à l’aide de programmes PostScript,
permettant ainsi des calculs complexes à la volée (lors de l’affichage),
y compris les calculs nécessaires pour produire des connexions curvilignes et des allongements adaptés aux formes des lettres adjacentes. À
ce propos, voir notamment les travaux d’Azzedine Lazrek [44] ou de
15
Notons que le terme ligature est surtout employé dans un contexte typographique, car il
s’agit, encore une fois, d’une propriété naturelle de l’écriture connectée, notamment de former des liaisons bidimensionnelles entre des signes élémentaires pour des raisons esthétiques,
traditionnelles ou encore d’économie d’espace.
48
Daniel Berry [59]. Malheureusement, le support du format Type 3 aux
niveaux matériel et logiciel (pilotes, systèmes d’exploitation, applications) reste très limitée, avec peu de chances d’évolution car le format a
été de facto abandonné par Adobe, son créateur.
– Lorsque la disposition d’un ensemble de lettres adjacentes ne suit pas Ligatures
strictement la ligne de l’écriture (par exemple, quand elles s’empilent
verticalement ou elles changent de forme), alors l’approche typographique consiste à représenter cet ensemble de lettres par une ligature.
Dans une fonte informatique, une ligature est un glyphe comme les
autres, sauf qu’elle correspond non pas à un seul mais à plusieurs caractères à la fois. Le système de composition doit être capable de reconnaître les ligatures présentes dans une fonte donnée et de les employer en remplaçant automatiquement les chaînes de caractères par
les ligatures qui leur correspondent. Puisque ce n’était pas le cas général jusqu’à l’apparition des formats de fonte dites intelligents au début
des années 2000 (à l’exception de quelques systèmes comme TEX), la
solution était souvent d’associer dans la fonte le glyphe de ligature, de
manière ad hoc, à un code de caractère arbitraire, ce qui a bien évidemment rompu le lien entre la valeur sémantique correspondant à ce code
et celle, différente, de la ligature affichée.
– À cause de l’abondance de marques diacritiques dans l’arabe et de la Diacritiques
cursivité de l’écriture, la pratique occidentale de créer des glyphes (des
poinçons) où la lettre de base est pré-composée avec son accent ne peut
pas être suivie : pour produire toutes les combinaisons lettre-marques
(plusieurs marques peuvent être associées à la même lettre) dans tous
les contextes possibles, y compris les ligatures diacritées, des milliers et
des milliers de glyphes devraient être dessinés. Alternativement, un modèle typographique informatique pour l’écriture arabe doit être capable
de positionner les marques de manière dynamique, suivant le contexte
textuel et les propriétés graphiques des fontes [13].
LES
ÉCRITURES LOGOGRAPHIQUES
Ce que nous appelons écritures logographiques est une famille d’écritures
qui se servent des logogrammes chinois : les écritures chinoises (traditionnelle
et simplifiée), le japonais et le coréen. En effet, il n’est pas possible de parler
d’un ensemble commun de logogrammes chinois pour les pays les ayant adoptés car le sous-ensemble des caractères employés dans chaque pays, ainsi que
leurs significations et leurs graphies exactes, montrent une forte dépendance
culturelle. Si l’on ajoute à ce propos les différentes voies de développement
technologiques et même politiques de ces pays, il n’est pas surprenant que
chacun d’eux a développé ses propres normes de représentation textuelle,
notamment au niveau des codages de caractères. Ce qui est commun est la
nécessité d’un codage multi-octets : au moins 13 bits sont nécessaires pour
une couverture à 99,99% des usages courants [26, p. 264]. Pire, lorsque l’on
tente de viser la couverture « totale » des logogrammes chinois, on se heurte
de nouveau à la problématique de circonscrire la portée de la notion de caractère (informatique). Nombreux sont les cas où deux signes qui sont graphiquement très similaires et qui se réfèrent essentiellement au même concept se
49
L’impossiblité
d’un codage
de caractères définitif
pour les écritures
logographiques
distinguent néanmoins par leur usage et même par leur sens, pour des raisons
historiques ou autres. Le besoin de distinguer ou non entre deux signes en
leur accordant deux points de code séparés est toujours fonction des usages
auxquels le codage de caractères est destiné. Quel que soit donc l’approche
par laquelle on construit un codage donné, il pourra y avoir des logogrammes
non-couverts ou au contraire, couverts de manière redondante, selon l’usage
actuel. De plus, l’invention de nouveaux logogrammes est un phénomène
constant, notamment pour créer de nouveaux prénoms mais aussi pour divers
autres objectifs (comme par exemple l’humour : le jeu de mot japonais ,
« femme + monter + descendre », est prononcé « erebētā gāru » et censé signifier « liftière » (elevator girl) [58, p. 158]). Pour cette raison, il n’est pas possible
de créer un codage de caractères définitif pour le chinois selon le principe
énumératif (où le codage s’établit à travers l’énumération de ses éléments).
Synthèse de caractères
Or, l’analyse de la structure graphique des logogrammes chinois démontre
et de glyphes chinois qu’ils s’assemblent à partir de composants de niveau inférieur : de radicaux
(comme indiqué dans la figure 1.3 en page 42), voire de traits élémentaires.
Alors que ces derniers sont des unités purement graphiques (liées aux mouvements du pinceau du calligraphe), les radicaux et en général les composants
de logogramme jouent souvent un rôle linguistico-sémantique, même si ce
rôle reste en général très indirect. Ainsi, la grand majorité des logogrammes
chinois se construit à partir d’un composant phonétique et d’un composant
sémantique où le premier indique (souvent très vaguement) la prononciation
et le dernier (aussi très vaguement) le sens du logogramme [26, p. 139]. De
nombreuses solutions de description de caractères et de synthèse de glyphes
ont été proposées, celles-ci exploitent cette propriété analytique de l’écriture
chinoise : un du début des années 1980 [70], puis Unicode proposent leurs
propres caractères de description idéorgraphique [28, p. 146] ; voir aussi le
système CDL [16] et [69]. Ces solutions présentent cependant d’autres types
de difficulté [28, p. 147]. En particulier, jusqu’à très récemment, les difficultés liées à la visualisation de l’écriture chinoise ont été pour la plupart plutôt pratiques que conceptuelles. Dans son histoire, le chinois s’écrivait (et
s’écrit toujours) dans des directions diverses (verticalement, horizontalement),
et l’orientation de certains signes (parenthèses, le signe japonais d’élonga», etc.) devait s’adapter à la direction courante. Les formats de fonte
tion «
numériques adoptés en Extrême-Orient sont essentiellement les mêmes qu’en
Occident (PostScript, TrueType et leurs variantes). Nous avons déjà démontré
que le fonctionnement de ces formats de fonte reflète le modèle de texte visuel
de l’Occident, notamment par la disposition linéaire et indépendante (à part
le crénage) de glyphes consécutifs. Lorsque cette approche est appliquée aux
écritures logographiques, une conséquence logique est la nécessité de créer
un dessin unique et séparé par logogramme, ayant comme résultat des milliers
de glyphes contenus dans une fonte donnée (et nécessitant l’extension du format PostScript de type 1 au format CID afin de surmonter la barrière de 256
glyphes codés).
Le choix de l’unité de représentation informatique de l’écriture chinoise
est donc un problème non-trivial ; des raisons théoriques et pratiques peuvent
être formulées pour ou contre une représentation au niveau logographique ou
à un niveau inférieur (composants, traits élémentaires) :
50
– des raisons conceptuelles : en acceptant l’unidimensionnalité comme
propriété inhérente de toute écriture, le logogramme s’impose comme
unité constitutive, car à l’intérieur d’un logogramme la composition est
bidimensionnelle (c’est ce même principe que Richard Sproat appelle
principe de localité dans [58, p. 42] dans le but de définir la Small
Linguistic Unit comme étant la limite supérieure de toute composition
bidimensionnelle) ;
– des raisons linguistiques : même si les composants d’un logogramme
montrent une certaine corrélation sémantique ou phonétique avec le
logogramme entier, cette corrélation n’est probablement pas suffisamment forte pour présenter un intérêt pratique quelconque ;
– des raisons d’économie : en choisissant comme unité le composant ou
le trait élémentaire, le nombre d’unités constitutives de l’écriture se réduit de plusieurs dizaines de milliers à des centaines ou seulement à
des dizaines ;
– des raisons d’extensibilité : une approche constructiviste rend plus facile
l’utilisation de logogrammes non prévus ;
– des raisons de complexité implémentationnelle : les formats de fonte
traditionnels (TrueType, PostScript) ne permettent pas la construction
bidimensionnelle et intelligente de glyphes.
Le niveau de représentation pertinent dépend sans doute de l’usage du
texte en question ; il est donc envisageable d’employer un modèle de texte à
deux niveaux où la représentation d’échange (le caractère) et la représentation
finale (le glyphe) correspondent à deux niveaux différents.
LE
HANGÛL CORÉEN
Le hangûl est l’écriture syllabique coréenne. Selon son point de vue, on
peut également la considérer alphabétique car les syllabes se décomposent,
suivant leur structure vocalique, en éléments phonétiques correspondant à
l’attaque, au noyau et au coda de la syllabe. Chacun de ces éléments (ou
jamos) possède son propre signe graphique, et la syllabe se construit par l’assemblage bidimensionnel des jamos [19].
Choisir l’élément représentationnel informatique pertinent pour le hangûl
est un problème similaire au cas des écritures logographiques. L’unidimensionnalité de l’écriture se présente au niveau inter-syllabe (ou plus précisément
inter-graphème correspondant à la syllabe), et par ce fait, la syllabe est l’unité
d’écriture « intuitive ». D’autre part, vue la régularité avec laquelle les syllabes
se construisent à partir de leurs composants phonétiques, une modélisation
alphabétique est également envisageable, surtout pour des raisons d’économie représentationnelle (quelques dizaines d’unités élémentaires contre une
dizaine de milliers).
Une telle approche analytique n’est cependant possible que si les technologies informatiques sont en mesure de gérer les modèles de texte nécessaires
à son implémentation. Ainsi, l’assemblage graphique bidimensionnel de la
syllabe à partir de ses trois composants alphabétiques requiert une technologie de fontes plus évoluée que ce que les formats PostScript ou TrueType
classiques ne peuvent offrir. D’autre part, en supposant que la représentation
finale du texte soit basée sur les syllabes entières (c’est-à-dire que la fonte com51
L’unité
de représentation
pertinente du hangûl
L’approche
alphabétique
est contrainte
par les technologies
informatiques
prend des glyphes pré-composés) pendant que la représentation d’échange (le
codage de caractères) suit l’approche alphabétique, alors c’est la correspondance multiple-à-un entre caractères et glyphes qui doit être correctement gérée par le système informatique, ce qui dépasse encore une fois les capacités
des formats de fonte mentionnés.
1.7
Le traitement de texte
WYSIWYG
L’interactivité
du document formaté
LE DOCUMENT INTERACTIF ET LE WEB
Un grand nombre de logiciels de préparation de documents, comme par
exemple TEX ou troff, suivent une logique opérationnelle décrite dans l’article
de Mittelbach et de Rowley [49] : ils « convertissent » un document depuis sa
forme représentationnelle d’échange en une représentation finale, en passant
par une représentation interne transitionnelle.
TEX est peut-être l’exemple qui incarne le plus parfaitement ce principe :
à partir du document source .tex, un document .dvi de sortie est généré
qui, après conversion en PostScript, est destiné à l’impression. Si l’usage des
documents textuels créés par les divers outils de traitement de texte des années 1970 et 1980 était très similaire à ce modèle, le principe du WYSIWYG,
par contre, consiste à fusionner les représentations d’échange et transitionnelle en une seule représentation interne, cachée à l’utilisateur qui ne voit
à tout moment que la représentation finale du texte. L’unité textuelle de la
représentation interne est le caractère alors que celle de la représentation finale, bien entendu, le glyphe. Cependant, alors que dans TEX le passage d’un
modèle à l’autre est une fonction à sens unique (à l’exception de l’opération
de césure), le paradigme WYSIWYG nécessite des passages incessants entre
les deux représentations : lorsque l’utilisateur place son curseur entre deux
glyphes pour y insérer un troisième, les deux caractères correspondants sont
identifiés, puis le troisième caractère inséré dans la représentation interne du
morceau de texte en question, et finalement le morceau entier est recomposé pour mettre à jour la représentation finale. Similairement, une opération
de copier-coller comprend l’identification des caractères correspondant aux
glyphes sélectionnés, le dépôt de la sélection dans le presse-papiers en un ou
plusieurs formats (texte brut ou balisé, etc.), et finalement le ré-affichage du
texte dans un environnement potentiellement nouveau, ce qui nécessite bien
évidemment un nouveau passage des caractères aux glyphes.
Dû à ces propriétés interactives du document formaté — en d’autres
termes, que le document peut être manipulé à plusieurs reprises —, les modèles de texte employés par les logiciels impliqués doivent être capables de
gérer les conversions entre représentations d’échange et finale dans les deux
sens. Les formats de document existants peuvent en gros être divisés en deux
catégories majeures par rapport à la solution qu’ils offrent au problème de passage entre représentations. La première solution (adoptée par les formats tels
que RTF ou HTML) consiste à stocker le texte dans sa représentation d’échange
(en caractères) et de n’effectuer la conversion en représentation finale qu’au
moment de son affichage. Cette approche rend le document plus convenable
aux usages liés à l’échange d’information mais elle rend également sa présentation plus dépendante du logiciel d’affichage. L’autre solution consiste à
stocker le texte dans sa représentation finale, de manière que celle-ci soit figée
52
(cas des formats PDF et SVG). L’inconvénient de cette approche est la difficulté occasionnelle de revenir à la représentation d’échange car souvent la
conversion de la chaîne de glyphes en chaîne de caractères n’est pas triviale.
Nous allons voir que le modèle de texte proposé dans le chapitre suivant
permet de profiter des avantages des deux approches par l’unification des représentations d’échange et finale.
1.7.1 L E
FORMAT DE DOCUMENT
RTF
Microsoft a développé le format Rich Text (RTF) [48] en 1987 pour servir
comme représentation d’échange et en même temps comme sérialisation de
la représentation interne du traitement de texte Word. Puis, RTF est devenu
une sorte de norme de facto de format d’échange de texte enrichi — principalement par des données de formatage — sur la plate-forme Windows, utilisée
entre autres dans la communication à travers le presse-papiers. RTF est un format en caractères ASCII uniquement, en partie inspiré du format d’entrée de
TEX. Le texte y est représenté en tant que chaînes de caractères Unicode ou
par d’autres codages historiques16 alors que les informations de formatage y
sont ajoutées à l’aide de commandes et de groupes, très similairement à TEX.
Ainsi, dans les traitements de texte WYSIWYG tels que Word ou OpenOffice.org les représentations d’échange et transitionnelle reposent essentiellement sur un modèle textuel en caractères uniquement, la représentation finale
étant mise à jour à chaque instance de visualisation, en fonction des informations de formatage incluses dans le texte mais aussi des réglages et des
capacités typographiques du logiciel de composition. L’aspect visuel du texte,
depuis le micro-niveau jusqu’à la pagination, dépend toujours de ces dernières
propriétés, et la pratique montre que deux visualisations du même document
par deux instances de logiciels ne sont que rarement identiques, notamment
s’il s’agit de logiciels ou de versions différents.
Le choix de tels modèles était, bien entendu, une conséquence de nouveaux usages : lorsque les manipulations comme la recherche ou le copiercoller sont appliquées au texte formaté, ce sont les fonctions d’échange du
texte qui gagnent de l’importance, il est donc facile à comprendre qu’une représentation par caractères, à l’opposé d’une représentation par glyphes ou
signes typographiques, soit à la base du modèle textuel choisi.
1.7.2 HTML ET
LE
WEB
Depuis 1990, c’est-à-dire que le Web existe, les aspects interactifs du document (à l’opposition du document destiné uniquement à l’impression) sont
devenus encore plus importants. Il n’est donc pas surprenant que, similairement à RTF, le format HTML repose sur un modèle où le texte est composé
de caractères uniquement. Certains motifs de chaînes de caractères forment
des balises qui ajoutent de l’information structurelle et présentationnelle au
« texte brut ». Suivant de nombreuses années d’évolution depuis son existence,
16
Les caractères ne sont pas codés par une représentation Unicode (telle que UTF-8) proprement dite : plutôt ce sont les codes numériques des caractères qui apparaissent textuellement.
53
la norme HTML s’est lentement mais sûrement appropriée le principe de séparation de contenu et de présentation : les balises HTML sont censées servir à
marquer le contenu et la structure du document alors que des feuilles de style,
logiquement ou physiquement séparées, sont censées être les seules porteuses
d’informations liées à la présentation.
Entre contenu et présentation, HTML a toujours été fortement orienté vers
le premier, son objectif principal étant de décrire de l’information à prépondérance textuelle, et ceci de façon adaptable aux particularités des différents
supports et logiciels de visualisation (navigateurs) qui tournent sur des dispositifs très variés. La présentation du document est mise à jour à chaque instance
d’affichage, en fonction des paramètres mentionnés, et c’est pour cette raison
également qu’un modèle textuel basé uniquement sur le caractère a été choisi.
À travers l’imbrication des éléments HTML, un document HTML s’organise
dans une structure arborescente. Les informations attachées à un élément s’appliquent en principe à la totalité du sous-arbre entre les balises ouvrante et fermante : par exemple, dans la chaîne « <b>gras <i>et italique</i></b> »,
le caractère « t » est affecté aussi bien par « <b> » que par « <i> ». Cette particularité n’est pas unique au format HTML : entre autres, les documents RTF
et TEX ont des structures d’imbrication de style similaires. Ce qui distingue cependant le format TEX de HTML et de RTF est que l’usage de ces deux derniers
formats s’inscrit dans un contexte interactif : ils se prêtent à des opérations
Recherche, telles que la recherche, le copier-coller ou l’indexation (par un moteur de recopier-coller, indexation cherche). En particulier, ces deux formats servent très souvent comme formats
d’échange de données textuelles contenues dans le presse-papiers de l’interface des systèmes d’exploitation courants17 .
HTML et RTF sont donc des formats orientés échange de données textuelles et par conséquent, la présentation réelle de tels documents dépend de
multiples paramètres de l’instance du logiciel chargé de la composition et de
la mise en page (les navigateurs pour HTML, les traitements de texte pour RTF).
En revanche, pour les formats de document orientés représentation finale, se
situant à l’autre bout du processus de formatage, l’usage prioritaire est la description précise et figée de la présentation du document plutôt que l’échange
de contenu textuel entre logiciels. Cependant, dans l’ère du Web, les usages
liés à l’échange d’informations sont également devenus indispensables, usages
que le format PostScript (décrit en section 1.5.2) n’était pas capable de satisfaire. La naissance de formats très répandus comme PDF (1993) et SVG (2001)
visait en partie à répondre à ces besoins.
Séparer contenu
et présentation
1.7.3 PDF
PDF adopte une forme simplifiée du modèle graphique de PostScript, notamment par l’exclusion de commandes qui font de ce dernier un langage de
programmation. En même temps, PDF permet une structuration logique et une
extension du document par un ensemble (toujours grandissant) de fonctionnalités non directement graphiques (métadonnées, hyperliens, annotations,
17
D’après les expériences de l’auteur, du texte copié à partir du logiciel Acrobat est déposé
dans le presse-papiers en format RTF, alors que dans le cas de Mozilla Firefox, le format utilisé
est, sans surprise, de l’HTML.
54
contenu textuel non-visuel, formulaires, signature numérique, etc.). Le texte
formaté dans un document PDF se représente, comme en PostScript, comme
une chaîne d’identifiants numériques de glyphes contenus dans des fontes. Ce
qui est nouveau par rapport à PostScript est la possibilité d’associer du contenu
à la présentation, plus précisément, de désigner les caractères auxquels correspondent les glyphes du document : pour les usages interactifs comme la
recherche ou le copier-coller, ces informations sont indispensables.
Notons que, par le principe de nommage de glyphes, les fontes PostScript
permettent déjà l’association d’un ou de plusieurs caractères aux glyphes
contenus dans le document, de la manière décrite en section 1.5.2, page 41.
Cependant, comme nous l’avons déjà prouvé, cette solution est sous-optimale
pour un nombre de raisons, principalement parce que rien n’oblige le créateur
d’une fonte d’étiqueter les glyphes par des noms pertinents (et conformes aux
normes imposées par Adobe et par d’autres sociétés comme FontLab). PDF, en
plus de cette méthode, en offre deux autres pour définir les correspondances
entre caractères et glyphes.
La première méthode consiste à établir les correspondances à travers une
table ToUnicode CMap (depuis PDF v1.2, voir [6, p. 472]) incluse dans le dictionnaire de fonte qui définit le code de caractère Unicode associé à chaque
identifiant de glyphe. De point de vue fonctionnel, cette méthode est équivalente au nommage de glyphes : ToUnicode ne permet pas non plus les
correspondances multiple-à-un entre glyphes et caractères ; en addition, son
inclusion dans le dictionnaire de fonte reste nécessaire. La seule différence
conceptuelle de ToUnicode par rapport au nommage de glyphes est que ce
premier représente plus clairement l’idée d’une approche « bipolaire » à la modélisation textuelle où les glyphes sont des éléments purement présentationnels et l’interprétation sémantique du texte s’effectue à travers les caractères
uniquement.
L’opérateur ActualText [6, p. 944] de PDF permet de définir des correspondances entre glyphes et caractères au niveau du texte (donc des instances
de glyphes), à l’opposé des deux méthodes précédentes qui les définissent
au niveau de la fonte. Initialement, cet opérateur a été conçu dans l’objectif de permettre l’accessibilité des documents PDF aux personnes malvoyantes : n’étant pas capables d’un décodage visuel des images — y compris des glyphes — par la lecture, on peut lire le texte à l’aide d’un système
de synthèse vocal. Cependant, l’identifiant numérique de glyphe n’est en général pas caractéristique du phonème, d’où une fois de plus le besoin de
préciser les correspondances caractères-glyphes. En plus de ceci, ActualText
est capable d’associer des interprétations (c’est-à-dire, des chaînes de caractères) à des artefacts graphiques telles qu’une lettre ou un symbole représenté
par une image qui ne provient pas d’une fonte et, par conséquent, n’est pas
codé et ne peut renvoyer vers aucun caractère, mais aussi dans des situations
où il y a divergence entre contenu textuel et présentation, comme dans le
cas de la césure dite non-standard de certaines langues comme l’allemand
ou le hongrois : le mot játssza (« qu’il joue ») doit être coupé comme játszsza, mais pour la synthèse vocale, la recherche ou le copier-coller, c’est le
mot original et non pas la version coupée qui est pertinent.
D’une manière générale, ActualText permet de définir des associations au
55
Caractères et glyphes
dans le document PDF
ToUnicode CMap
ActualText
niveau des chaînes d’instances de glyphes, au lieu de les définir au niveau
des glyphes individuels en tant qu’éléments d’une fonte. Ceci permet notamment d’indiquer des correspondances multiple-à-multiple entre glyphes et caractères ; ainsi, l’opérateur ActualText devient la solution la plus générale et
la plus puissante qu’offre le format PDF dans le but de « sémantiser » le texte
formaté. Ce potentiel n’est que très rarement exploité en pratique par des applications, une exception étant le système expérimental Ω2 dont la capacité
de produire des documents PDF ainsi « sémantisés » a été développée par l’auteur et que nous présenterons en section 3.2. Quoi qu’il en soit, l’existence
de l’opérateur mentionnée prouve que le problème de passage du domaine
des glyphes à celui des caractères ne peut être résolu dans sa généralité au
niveau des signes en tant qu’entités abstraites mais seulement au niveau du
texte en tant que chaîne d’instances de ces entités. C’est cette même approche
que prend le modèle de texte que nous allons proposer.
Mentionnons finalement qu’en 2007 Adobe a annoncé une mise à jour
majeure du format PDF : le successeur de celui-ci s’appellera Mars, il sera
entièrement XMLisé et intégrera du support pour la norme SVG, un langage de
description vectorielle de graphiques et de documents [2]. SVG, similairement
aux formats PostScript et PDF, possède son propre modèle de texte que nous
présentons dans la section suivante.
1.7.4 SVG
SVG offre
une représentation
textuelle « hybride »
Composition prise
en charge par le moteur
SVG
Le format SVG (Scalable Vector Graphics) de description vectorielle de documents et d’images est une recommandation W3C depuis 2001, et en même
temps une alternative moderne au langage PostScript, basée entièrement sur
XML [22]. Les plus grands industriels (Adobe, Microsoft, Apple, IBM, HP, Macromedia, etc.) ont participé à sa conception, assurant qu’il est sur la voie de
devenir un des deux formats18 de graphique vectorielle supportés par Mars, le
successeur de PDF [2].
SVG est avant tout un format graphique mono-page ; ce qui nous permet
néanmoins de l’appeler format de document est le fait qu’il possède un modèle textuel élaboré. Nous allons voir que, contrairement aux formats de documents présentés jusqu’ici, SVG a plus de mal à trouver sa place parmi les
catégories proposées par Rowley et par Mittelbach (représentations d’échange,
transitionnelle ou finale). D’une part, SVG étant un format avant tout orienté
vers la présentation, il permet forcément une description graphique précise de
ses éléments, ce qui signifie pour le texte la définition exacte des positions
et de toutes les propriétés graphiques des glyphes. SVG permet ainsi d’exercer un contrôle total sur l’aspect visuel du texte. En même temps, SVG ne
se contente pas de décrire la présentation du texte, il souhaite également y
associer la sémantique du texte en question, d’en définir le contenu textuel.
Et puisque SVG est basé sur la syntaxe XML, il n’est pas surprenant que son
interprétation du contenu textuel soit conforme à celle proposé par XML : à
savoir du « PCDATA », feuille de l’arborescence.
Dans le cas le plus général, le texte se définit sous SVG à l’aide de l’élément <text>, de la manière suivante :
18
L’autre format étant PostScript.
56
<text font-family="Centaur MT" font-size="10"
x="200" y="100" stroke="black">hello, world</text>
où le texte « hello, world » est donné en caractères PCDATA. C’est au visualiseur SVG de retrouver les glyphes correspondants dans la fonte Centaur MT
et de composer le texte en corps 10, couleur noir, à partir du point (200, 100).
À l’aide d’un élément <text> (ou <tspan>) pour chaque caractère, le créateur
du document SVG a également la possibilité de préciser les coordonnées de
chaque glyphe séparément s’il souhaite que l’apparence de son document soit
exactement identique sur toutes les plates-formes :
Composition manuelle
prise en charge
par le créateur
du document
<text x="200" y="100">h</text><text x="225" y="100">e</text>...
Les glyphes à choisir pour chaque caractère peuvent également être précisés Choix directe
des glyphes
à l’aide des éléments <altGlyph>. Dans l’exemple suivant,
<text x="200" y="100">
h<altGlyph xlink:href="#e_swash">e</altGlyph>llo, world
</text>
le glyphe « e » est remplacé par un glyphe alternatif ayant l’identifiant unique
e_swash. Le caractère « e », contenu de l’élément <altGlyph>, est le contenu
textuel associé au glyphe référé, utile entre autres pour les usages interactifs
(recherche, copier-coller) ou pour la synthèse vocale. La référence peut se faire
de plusieurs manières, notamment par identifiants numériques lorsque la fonte
utilisée est de format TrueType ou OpenType. Il est important de noter que
les correspondances multiple-à-multiple sont permises : on peut placer plus
d’un caractère entre les balises altGlyph (cas des ligatures), et d’autre part,
l’identifiant référé par xlink:href peut référer à plusieurs glyphes. Ainsi, le
rôle et l’usage d’altGlyph sont similaires à celui de l’opérateur ActualText du
format PDF19 .
Un document SVG vise donc à être représentation d’échange et finale
en même temps, la première à travers le contenu textuel véhiculé par des
PCDATA en caractères, et la deuxième à travers la possibilité de figer toutes
les propriétés graphiques du texte, y compris le choix de glyphe. La manière
exacte d’identifier un glyphe dépend de la fonte utilisée : faute de précisions
dans la spécification d’SVG, nous supposons qu’il s’agit de valeurs numériques
pour TrueType/OpenType, du nom de glyphe pour Type 1, et ainsi de suite.
Il y a cependant des aspects de la représentation d’échange autres que le
simple accès au contenu textuel en caractères : comme le démontre Raph
Levien dans son article informel mais clairvoyant [45], la modification du
contenu textuel dans le document SVG entraîne bien évidemment la mise
à jour nécessaire de nombreux paramètres graphiques (longueurs de lignes,
positions de glyphes, etc.) à l’intérieur du document. Tout comme dans PDF,
un document SVG en général n’est modifiable qu’à un degré restreint et, du
moins en pratique, qu’à l’aide d’un outil qui assure la cohérence de divers
paramètres présentationnels avec les modifications effectuées sur le contenu
textuel.
57
Correspondances m-à-n
entre caractères
et glyphes
SVG en tant que
représentation
d’échange
SVG et Unicode
En réalité, le format SVG avec son modèle de texte à deux facettes20 est le
produit d’une ère différente que celle qui a vu naître PostScript, PDF, RTF ou
TEX. C’est un format bâti sur le principe de séparation entre contenu et présentation — caractères et glyphes — au sein du même document. Ce principe, tout
en ayant une universalité qui ne restreint pas son application à l’information
textuelle uniquement (et encore moins aux atomes du texte), est depuis l’introduction de la norme Unicode devenu une idée organisatrice fondamentale
de la représentation du texte.
1.8
LE CODAGE DE CARACTÈRES UNICODE
1.8.1 L ES
PROBLÈMES AYANT MENÉ À LA CRÉATION D ’U NICODE
À ce point, il est peut-être judicieux de résumer les problèmes majeurs
liés à la représentation textuelle par ordinateur qui ont mené au début des
années 1990 à la création d’Unicode et en particulier à celle de son modèle
de texte :
– le besoin de nouveaux caractères afin de couvrir des écritures jusque-là
non supportées et d’étendre le support des écritures déjà couvertes (voir
section 1.6.1) ;
– l’utilisation de documents multilingues et multi-écritures, difficile à
cause des différences entre les codages associés à chacune de ces
langues ou écritures (section 1.6.1) ;
– l’incohérence et la redondance entre les codages définis dans différents
pays pour des ensembles de signes non-disjoints, voire essentiellement
les mêmes (signes logographiques chinois-japonais-coréens, etc., section 1.6.1) ;
– l’incompatibilité entre codages dédiés à des plates-formes précises ;
– le manque de clarté vis-à-vis de ce que l’on entend par caractère : sans
donner une définition précise à ce terme, il ne sera pas possible d’établir
un modèle de texte cohérent (sections 1.4.1, 1.4.3 et 1.5.1) ;
– une conséquence du problème précédent est la difficulté de construire
un modèle de texte informatique, et donc un codage de caractères, pour
une écriture donnée car il n’est pas clair selon quels critères les éléments d’un tel codage devront être sélectionnés. Faute de définitions et
de principes conducteurs, les décisions ne peuvent être prises que de
manière ad hoc (section 1.6.2).
Certains de ces problèmes sont de nature pratique (comme le manque de
points de code ou l’incompatibilité entre codages), d’autres plutôt de nature
théorique (comme la définition de la notion de caractère). Ce que nous tenterons de démontrer dans cette section est le fait que les solutions apportées
par Unicode répondent essentiellement aux problèmes pratiques, laissant de
côté les considérations théoriques sur la nature du caractère et du codage.
19
Il faut mentionner qu’au moment de rédaction de la présente thèse, aucune implémentation de moteur SVG sous Linux, connue par l’auteur, ne supporte l’utilisation des glyphes
alternatifs.
20
Nous avons choisi de nous méfier de la formule « à deux vitesses » afin d’éviter les sousentendus politiques...
58
Cette omission de la part d’Unicode mène inévitablement à de nouveaux problèmes dont l’analyse et la résolution éventuelle sont des sujets majeurs de la
présente thèse.
1.8.2 L ES
PRINCIPES FONDAMENTAUX D ’U NICODE
Bien que nous « accusions » Unicode d’être motivé principalement par des
considérations pratiques — ce qui est loin d’être surprenant connaissant ses
origines industrielles —, cela ne signifie pas que la norme soit complètement
dépourvue de fondements théoriques. Notamment, Unicode part de dix principes de conception [63, chapitre 2] dont certains ont des motivations plutôt
pratiques (efficacité, convertibilité, stabilité21 , etc.), d’autres plus abstraites ;
cependant, il ne serait pas sage de départager ainsi les dix principes en deux
catégories distinctes : nous verrons que les considérations qui semblent purement pratiques peuvent cacher des préconceptions théoriques et vice versa,
une idée théorique peut avoir des conséquences pratiques. Parmi les dix principes, ceux qui nous intéresseront particulièrement sont les suivants :
– « universalité », l’objectif de couvrir la totalité des écritures du monde ;
– « caractères et non glyphes » réfère au principe de séparer contenu et
présentation ;
– « sémantique » réfère au souhait d’associer une valeur sémantique précise à chacun des caractères de la norme ;
– « texte brut » qui en réalité incarne l’objectif de simplicité ;
– « unification », en d’autres termes : économie, un principe a priori purement pratique mais qui entraîne des conséquences très importantes.
1.8.3 U NIVERSALITÉ
Il s’agit de réunir dans un seul codage la totalité des signes d’écriture employés dans le monde. Cependant, le fait que le nombre de codes disponibles
ne limite pas en pratique le nombre de signes couverts par le codage ne signifie pas que le choix d’y inclure ou non un signe donné devienne plus facile.
Faute de pouvoir justifier l’exclusion d’un signe du codage par des raisons
pratiques d’économie, les responsables de la norme Unicode sont dès lors
obligés de justifier leurs décisions par des critères théoriques bien fondés.
Nous avons déjà mentionné en section 1.4.3 qu’une approche purement
extensionnelle à la définition du codage (c’est-à-dire par la simple énumération des caractères compris) n’est plus suffisante lorsque le codage vise l’universalité. En effet, « être universel » signifie « être exhaustif », ce qui suppose
que l’on a réussi à donner une définition adéquate de ce que l’on entend par
unités sémantiques textuelles (p. 26), à circonscrire cet ensemble. Or, selon
Gottlob Frege, connaître un ensemble est possible soit par la dénotation de
ses éléments — que l’on appelle l’extension de l’ensemble —, soit par l’appréhension de son sens à l’aide de l’ensemble de ses propriétés — que l’on
21
La stabilité de la norme — ce qui signifie l’impossibilité de toute suppression ou rectification, avec des conséquences discutables [31] — ne fait en vérité pas partie des dix principes,
elle est en quelque sorte l’onzième principe d’Unicode.
59
L’universalité entraîne
inévitablement
une approche
intensionnelle
appelle son intension — qui décrivent ce qui est commun parmi les éléments22
[24].
Dans le cas du codage Unicode, l’approche extensionnelle consisterait à
choisir par dénotation (à travers le principe énumératif) les unités textuelles
qui le constituent à partir du vaste ensemble de signes textuels qui existent
et qui ont existé depuis l’invention de l’écriture. Connaître tous les éléments
de cet ensemble serait bien évidemment irréalisable ; indépendamment de ce
fait, il faut comprendre qu’afin de pouvoir décider pour chaque élément s’il a
sa place ou non dans le codage Unicode, il est indispensable de se fixer un
nombre de critères bien définis. Ceci n’est possible que s’il est sous-entendu
que l’on possède déjà des connaissances sur ces éléments en forme de propriétés : une approche dite intensionnelle — qui procède justement par l’analyse
d’un élément à travers ses propriétés — ne peut donc être évitée. En réalité,
lorsque dans notre première définition du codage et du caractère (p. 26) nous
avons restreint l’univers d’éléments aux unités sémantiques textuelles, cette
restriction était déjà en effet une tentative de filtrage des éléments possédant
la propriété « sémantique », même si celle-ci n’a pas vraiment été définie de
manière précise à ce point-là.
Nous comprenons mieux maintenant pourquoi Unicode, contrairement
à ses prédécesseurs, se soucie de déclarer ses dix principes de conception :
ceux-ci donnent le cadre pour formuler des critères intensionnels. Parmi ceuxci, le critère peut-être le plus important est celui selon lequel Unicode utilise
des « caractères et non des glyphes » et qui permet de restreindre de manière
significative les signes candidats à considérer pour inclusion dans Unicode.
Cependant, nous allons voir qu’Unicode n’arrive pas à formuler de critères
rigoureux quant à la distinction entre ce qui est un caractère et ce qui est
un glyphe. Dans le cadre de notre modèle de texte proposé, nous tenterons
d’établir dans le chapitre suivant une méthodologique qui enfin permettra de
formuler des définitions précises quant à ces deux notions.
1.8.4 C ARACTÈRES ET
Rappel sur les notions
de caractère, de glyphe
et de signe
typographique
NON GLYPHES
Unicode n’était pas la première norme informatique à formuler le principe
de séparer contenu et présentation. Il n’était pas non plus le premier à employer le terme glyphe en opposition avec le terme caractère pour distinguer
l’unité textuelle graphique de l’unité textuelle logique. Ce qu’Unicode tente
donc d’exprimer avec ce principe est que la norme n’est pas concernée par les
aspects présentationnels du texte mais uniquement par la « sémantique » que
portent les signes représentés par les caractères.
Arrêtons-nous ici pour clarifier les propos du paragraphe précédent. Qu’entend-on par unités textuelles « graphiques » et « logiques » ? Comment définit-on
la « sémantique » portée par un caractère et comment la distingue-t-on des « aspects présentationnels » ? Quelles définitions Unicode attribue-t-il aux notions
de caractère et de glyphe ? Quel est le rapport entre ces deux notions et celle
que nous appelons signe typographique ?
Dans les premiers modèles textuels informatiques des années 1960 et 1970,
22
Nous présenterons ces idées plus en détail au début du chapitre suivant, comme bases du
modèle que nous y proposerons.
60
les correspondances entre codes de caractères et glyphes contenus dans les
fontes étaient bijectives. Il n’y avait donc aucune raison pratique pour distinguer les deux concepts, et en effet, aucun informaticien ne parlait à l’époque
de glyphes. Depuis l’existence des systèmes tels que TEX et des formats de
fonte tels que TrueType, les significations du code de caractère et du code de
glyphe ont commencé à diverger. D’après notre tentative de définition, p. 24,
le caractère est un élément de codage qui représente une « unité sémantique
textuelle ». Quant au glyphe, jusqu’ici nous avons utilisé ce terme dans un sens
pratique pour désigner l’image contenue dans la fonte (p. 30). Cette distinction simple et pratique était suffisante pour comprendre l’intérêt d’une double
représentation textuelle où l’unité constitutive de la représentation d’échange
est le caractère et celle de la représentation finale est le glyphe. En même
temps, un troisième concept, différent aussi bien de celui du caractère que de
celui du glyphe, nous a été utile : le signe typographique (p. 34). Ce dernier
incarne une abstraction de l’image — du glyphe — par la mise en évidence de
ses propriétés typographiques proprement dites.
Une telle approche ne peut pas convenir à la norme Unicode car elle est Caractères et glyphes
censée fournir une méthodologie qui serve à construire l’ensemble de carac- dans l’interprétation
tères, autrement dit, qui soit capable de décider d’un signe quelconque s’il a d’Unicode
sa place ou non dans l’ensemble de caractères Unicode. La règle « caractères
et non glyphes » étant la principale indication dans ce sens, des définitions
précises des termes caractère et glyphe sont désormais indispensables.
Or, il s’avère que la norme Unicode ne fournit aucune définition digne
de ce terme. Voyons d’abord le « Glossaire de termes Unicode » à l’entrée
caractère ; on y trouve non moins de quatre définitions séparées23 :
CARACTÈRE
1. le plus petit élément d’une langue écrite pourvu d’une valeur
sémantique au niveau du sens ou de la forme abstraite plutôt
que d’une forme particulière (Cf. également Glyphe) [...] ;
2. synonyme de caractère abstrait ;
3. l’unité de base utilisée par le codage de caractères d’Unicode ;
4. le nom français des éléments idéophonographiques d’origine
chinoise.
Commençons à partir de la fin de cette liste. La quatrième définition réfère à une signification en dehors de notre contexte. La troisième définition,
malgré son air insignificatif, représente l’approche extensionnelle qui définit
l’ensemble par le principe énumératif (est caractère ce qui est codé par la
norme Unicode). La deuxième définition précise que dans le modèle de codage d’Unicode, on fait la distinction entre signes effectivement codés (auxquels des codes numériques ont été associés) et les concepts abstraits représentés par les signes. Le caractère abstrait d’Unicode est de toute apparence
un concept équivalent à ce que nous avons appelé en section 1.4.2 « unité
sémantique textuelle »24 .
23
Traduction par P. Andries.
La relation entre code numérique et caractère abstrait peut être considérée comme analogue aux relations sémiotiques entre signifiants et signifiés.
24
61
La définition
du caractère dans
le glossaire d’Unicode
La première définition est la plus intéressante : d’après elle, les caractères
– sont les plus petits éléments d’une langue écrite [critère d’atomicité] ;
– sont pourvus d’une valeur sémantique [critère sémantique] ;
– cette valeur sémantique relève du sens ou de la forme abstraite plutôt
que d’une forme particulière [critère d’abstraction].
Le problème majeur de cette définition est le flou qui entoure chacun des
trois principes mentionnés : qu’entend-on par « valeur sémantique » ? Dans
quel sens, dans quel contexte et par rapport à quel usage le caractère est-il
l’élément « le plus petit » ? S’agit-il du graphème, le plus petit élément du texte
écrit tel qu’il est interprété par la linguistique ? Du moins, c’est ce que la mention de la « langue écrite » nous suggère. Et finalement, comment distingue-t-on
entre « forme abstraite » et « forme particulière » ? Ces questions, nous verrons,
ne sont pas répondues de manière cohérente par Unicode, ni par les considérations théoriques avancées dans le texte de la norme, ni à travers la pratique
suggérée par l’exemple des caractères codés actuels.
CARACTÈRE
ET GRAPHÈME
Le caractère et le graphème sont, selon Unicode, deux concepts différents ;
ce dernier étant interprété par le même glossaire de la manière suivante25 :
GRAPHÈME. (1) Plus petite unité distinctive et significative de
l’écriture, dans le contexte d’un système d’écriture particulier. Par
exemple, « p » et « s » sont des graphèmes distincts au sein du système d’écriture français puisque les mots pot et sot sont des mots
différents. Par contre, une lettre minuscule italique « a » et une
lettre minuscule romain « a » ne sont pas des graphèmes distincts
puisque aucun mot ne diffère sur la base de ces deux formes différentes de cette même lettre. (2) Ce que l’utilisateur considère être
un caractère.
On voit ici une définition classique, à orientation linguistique, du concept
de graphème. Ce qui rend cette définition plus claire que la précédente sont
d’une part la restriction du contexte dans lequel celle-ci est interprétée à celui de la linguistique (à l’opposition de la typographie, de l’informatique ou
d’autres usages), d’autre part la précision que le choix de l’unité la plus petite
sera toujours fonction du système d’écriture modélisé. Cependant, le caractère
Unicode n’est et ne peut être l’analogue du graphème linguistique, d’abord
parce qu’il englobe des signes auxquels la linguistique ne s’intéresse qu’accessoirement ou pas du tout (signes de ponctuation, signes typographiques,
chiffres, pictogrammes, etc.), puis, comme le suggère la deuxième partie de
la définition du graphème, Unicode même nie l’équivalence des deux termes.
Car en section 3.4, on trouve :
Un caractère abstrait ne correspond pas nécessairement à ce
que l’utilisateur imagine être un « caractère », il ne doit pas non
plus être confondu avec un graphème.
25
Traduit de l’anglais par l’auteur, ayant pris comme base la traduction de Patrick Andries
d’une version antérieure de la même définition.
62
Une interprétation possible de l’entrée du glossaire d’Unicode pour le
terme caractère est la suivante : alors qu’un texte écrit peut être décomposé
en signes individuels (par exemple, en lettres alphabétiques) qui à leur tour
peuvent également être décomposés en traits, courbes ou d’autres sous-composantes, ces traits ou courbes ne sont jamais reconnus comme porteurs de
sens par rapport au texte en question. Le signes entiers, par contre, semblent
avoir un tel rapport. De plus, certaines variations au niveau des signes —
comme entre un « a » italique et un « a » droit — ne contribuent apparemment
pas à la « sémantique » du signe élémentaire, d’où l’exclusion de cette différenciation de la norme Unicode : par le principe de « caractères et non glyphes »,
selon Unicode « a » et « a » sont deux glyphes représentant le même caractère.
L’AMBIGUÏTÉ
DU CRITÈRE SÉMANTIQUE
Cependant, l’italicité d’un signe, qui est une propriété traditionnellement
typographique, est très souvent porteuse de sémantique en rapport au texte
(elle peut indiquer l’emphase, la citation, l’ironie, et ainsi de suite), certes au
niveau sémantique (et non pas graphémique, morphologique ou syntaxique)
du texte. La nécessité formulée dans le glossaire de faire abstraction de la
forme du signe pourrait nous guider à laisser tomber la propriété d’italicité et
de n’inclure dans le codage qu’un seul caractère « a minuscule », mais alors,
pourquoi ne pas autant faire abstraction de la propriété de casse également et
ne plus distinguer entre « a » et « A » ? Pourquoi le caractère est-il censé représenter l’information syntaxique portée par la casse (la distinction entre noms
communs et noms propres, entre noms et autres éléments de la phrase en
allemand, ou l’indication du début de phrase) mais non l’information sémantique portée par l’italicité ? Les articles [27] et [31] de Yannis Haralambous
contiennent de nombreux exemples qui démontrent le manque de principes
clairs d’Unicode par rapport à la distinction entre informations sémantiques et
présentationnelles.
Appréhender la sémantique représentée par un signe donné dans le but
de décrire26 un caractère Unicode est une tâche très difficile car la notion
de sémantique même, ou du moins son usage dans na norme Unicode, est
ambiguë. Rappelons-nous l’importance du contexte par rapport à la désambiguïsation de la polysémie des caractères (ce que l’on a noté par l’indice α
en section 1.4.2) : souvent c’est le contexte — qui est défini par l’usage et
qui, par conséquent, ne peut que difficilement être pris en compte lors de la
construction de la norme Unicode — qui fournit le rôle d’un caractère. Ceci
étant dit, comme nous allons le voir en section 1.8.5, la considération de certains usages pratiques s’avère parfois plus pertinente que le respect du critère
sémantique.
L’AMBIGUÏTÉ
DU CRITÈRE D’ATOMICITÉ
Le critère du « plus petit élément », critère d’atomicité, n’est pas moins
vague. Si encore dans l’écriture latine l’atome linguistique — au-dessous du26
Il peut être question de décrire l’usage correct d’un caractère (comme par exemple la
différence entre l’apostrophe droit informatique et l’apostrophe typographique) ou encore de
décider d’un signe s’il a sa place ou non parmi les caractères Unicode.
63
quel aucune valeur linguistique ne peut être distinguée — semble être reMême l’atomicité lativement facile à repérer, certaines choix sont loin d’être triviaux : faut-il
de la lettre latine considérer accents et autres diacritiques comme atomes indépendants ou au
n’est pas triviale contraire, forment-ils des atomes attachés à leurs lettres de base ? En français,
Les logogrammes
chinois ne sont pas
des atomes
Le double codage
du hangûl
« e » et « é » représentent deux graphèmes distincts alors qu’en espagnol il s’agit
de la forme écrite du même phonème car l’accent aigu indique l’accentuation
du mot et non la valeur phonétique de la voyelle27 . Ou encore : les lettres « l·l »
catalane et « c’h » bretonne, sont-elles des atomes ?
Lors de la modélisation des écritures de la famille logographique chinoise,
Unicode a choisi le logogramme comme unité de codage, même si celuici est loin d’être indivisible : d’un point de vue graphique, il est construit de
composants dont la sémantique ou la phonétique sont, pour la grande majorité
des logogrammes, directement ou indirectement liées à celles du logogramme
entier. (Voir à ce propos l’exemple donné en figure 1.3, p. 42, « le soleil et la
lune sont en même temps sur le ciel », et aussi [26, chapitre 5].) Le caractère
n’est donc en général pas l’élément le plus petit ayant une valeur sémantique,
et pourtant, Unicode a fait le choix de coder à la fois les logogrammes entiers
et les composants individuels.
De même sorte que logogrammes chinois, le hangûl coréen a subi un codage à double approche : toutes les syllabes pré-composées ont été codées
(une dizaine de milliers) ainsi que les segments alphabétiques (les jamos) à
partir desquels celles-ci sont assemblées. Dans l’objectif de permettre le choix
entre les modélisations textuelles syllabique et alphabétique, Unicode a décidé de ne prononcer ni le segment syllabique ni le jamo comme unité atomique du hangûl. De plus, Unicode permet une conversion facile entre les
deux représentations grâce à l’organisation particulière des tables de codage.
La « formule magique » suivante permet de retrouver la syllabe correspondante
à un groupe de trois jamos donnés et vice versa :
code pré-composé = [(jamoattaque ×588)+(jamonoyau ×28)+jamocoda ]+44032
Il ne s’agit pas ici de critiquer la cohérence de la norme Unicode ni le
non-respect de son propre principe d’atomicité. Les incohérences théoriques
d’Unicode — qui sont souvent la conséquence de considérations pratiques
— ont déjà été démontrées moultes fois et la norme même les admet volontiers. Le fait que les logogrammes et les composants logographiques, les
lettres latines, les accents et les lettres accentuées, ou les segments syllabiques
et les jamos du hangûl sont tous des caractères Unicode nous montre que le
principe d’atomicité — tel qu’il est présenté par Unicode — n’a vraiment de
fondements ni théoriques ni pratiques, ou du moins qu’il doit être modulé en
fonction d’un ensemble de critères qui dépendent de l’écriture, des usages, et
ainsi de suite.
Si tel est le cas, c’est-à-dire si l’atomicité d’un signe d’écriture donné est
toujours dépendante de l’usage du texte auquel il participe, alors nous ne
pouvons que saluer la prévoyance d’Unicode d’avoir intégré non pas un seul
mais plusieurs niveaux représentationnels de la même écriture.
27
Même si la présence ou l’absence de l’accent peut, dans de rares cas, faire une différence
sémantique : este signifie ce, éste signifie celui-ci, esté signifie soit.
64
FIG. 1.4 – Quatre strates de l’écriture arabe : à droite, le graphème (la lettre
abstraite) bâ représentant le phonème « b », dans le modèle Unicode elle correspond au caractère. Puis ses quatre formes contextuelles, deux styles (naskh
et koufique) et finalement à gauche trois variantes graphiques venant de fontes
différentes.
L’AMBIGUÏTÉ
DU CRITÈRE D’ABSTRACTION
Finalement, nous arrivons au critère par lequel Unicode exige que la valeur
sémantique du caractère relève « du sens ou de la forme abstraite plutôt que
d’une forme particulière ». Or, nous avons vu qu’il était parfois difficile de trancher entre propriétés graphiques qui relèvent du sens et celles qui soi-disant
sont purement présentationnelles. La lettre « a » minuscule est plus abstraite —
car moins définie — que la lettre « a » minuscule italique mais moins abstraite
que la lettre « a » (minuscule ou majuscule). D’une manière similaire, dans
l’écriture arabe, en partant de la forme concrète d’une lettre « bâ » telle qu’elle
apparaît sur l’écran, c’est par de nombreux niveaux d’abstraction que l’on arrive jusqu’au graphème (qui représente le phonème « b »). D’abord on ignore
la taille et la couleur (pour obtenir l’image contenue dans la fonte), puis la
forme graphique propre à la fonte (pour obtenir une forme parmi un des styles
courants comme le naskh ou le koufique), puis le style (pour obtenir ce que
l’on appelle dans le jargon informatique la forme contextuelle — initiale, médiane, finale ou isolée), et finalement la forme contextuelle pour obtenir enfin
le graphème. (Voir figure 1.4.)
Dans le cas de l’écriture arabe, Unicode a choisi comme niveau d’abstraction ce dernier, c’est-à-dire le niveau graphémique. Ce choix particulier
semble fort pratique pour un grand nombre d’usages informatiques du texte
arabe (comme par exemple la recherche dans un document). Il est très facile de trouver d’autres exemples de caractères Unicode où le choix du degré
d’abstraction paraît moins logique, voire erronné : par l’inclusion de diverses
espaces typographiques (espace cadratin, demi-cadratin, espace fine, espace
insécable, espace fine et insécable, etc., on trouve en effet plus d’une vingtaine d’espaces dans le codage), Unicode semble avoir oublié son principe de
favoriser le contenu à la présentation.
Encore une fois, il ne s’agit pas de critiquer la cohérence d’Unicode mais
plutôt de démontrer qu’il ne fournit pas de méthodologie bien établie pour
décider pour un signe donné s’il est suffisamment dépourvu d’aspects présentationnels et s’il est suffisamment atomique ou encore pour bien définir la
valeur sémantique qui lui appartient. Sans une telle approche rigoureuse, le
choix ne peut être fait que de manière ad hoc, ce qui entraîne inévitablement
l’incohérence de l’ensemble de caractères couverts.
Un des objectifs de la présente thèse est justement de proposer un cadre
65
scientifiquement fondé qui ensuite permet l’établissement d’une méthodologie rigoureuse dans le but de construire un modèle de texte plus cohérent et
plus puissant que celui proposé par Unicode.
1.8.5 COHÉRENCE THÉORIQUE CONTRE USAGES PRATIQUES
Le caractère :
un concept
« fourre-tout » par
conception ?
Espaces
Bien entendu, « un cadre scientifiquement fondé » et « une méthodologie
rigoureuse » sont toujours les bienvenus ; cependant, sont-ils réellement nécessaires pour définir un codage de caractères ? Il n’est pas évident qu’un codage
universel qui obéit à des principes théoriques soit en pratique plus utile, plus
puissant, plus convivial, plus adaptable, etc., qu’un autre, incohérent et dépourvu de tels principes mais construit suivant des considérations pratiques
d’usage. De nombreux aspects des langues naturelles en tant que systèmes
communicatifs manquent de cohérence et de logique, cependant les linguistes
hésiteraient sans doute d’affirmer que ce manque de logique nuise à l’expressivité des langues en question ; et justement, le contraire semble être le cas :
l’incohérence est souvent considérée comme une richesse. Pour éviter d’entrer dans des considérations linguistiques ou philosophiques qui mènent très
loin, nous tenterons d’aborder ce problème d’un point de vue pratique, à travers une série d’exemples. Les questions auxquelles nous souhaitons répondre
sont les suivantes : une définition scientifique et rigoureuse du concept de
caractère est-elle réellement nécessaire ? Ne faut-il tout simplement la considérer comme un concept « fourre-tout », intentionnellement sous-défini et par
conséquent suffisamment souple, s’adaptant facilement aux particularités de
différentes écritures, langues, usages et contraintes techniques ?
L’analogie avec les langues naturelles est d’autant plus intéressante qu’elle
met en évidence les dangers d’une approche non-structurée : ce qui peut du
point de vue de l’humain être considéré comme une richesse devient un fardeau presque insurmontable du point de vue du traitement automatisé. En
connaissant les difficultés extrêmes auxquelles se heurtent les technologies de
traitement automatique de langues naturelles, on souhaite éviter à tout prix
que ce genre de problèmes réapparaissent au niveau textuel le plus élémentaire, au niveau des caractères. Une approche algorithmiquement claire et suffisamment simple doit donc être de rigueur, il n’y a pas de doute là-dessus.
L’objectif de certains principes d’Unicode (caractères et non glyphes, texte
brut, sémantique, unification) est justement de garantir une telle approche.
En même temps, le respect de certains autres principes (compatibilité avec
les codages anciens, stabilité) et de contraintes venant des usages souvent
contradictoires va parfois à l’encontre de toute tentative de structuration. Le
résultat est un compromis, avec, d’une part, un grand nombre de caractères
dont l’usage est officiellement découragé à cause de leur non-respect des principes théoriques, et d’autre part, des caractères qui adhèrent strictement aux
principes mais dont l’utilité pratique est fortement réduite. Dans la suite, nous
citerons quelques exemples qui démontrent la difficulté d’équilibrer les approches structurelle et pratique.
Il s’agit donc d’une multitude d’usages qui sont, de plus, souvent contradictoires : la typographie emploie de nombreux types d’espaces textuelles
(espace fine, demi-cadratin, cadratin, insécable, etc.) où chaque type d’espace
66
peut posséder de multiples valeurs sémantiques28 . Cependant, les différences
visuelles et sémantiques entre ces espaces sont négligées dans d’autres usages
comme par exemple la recherche textuelle.
Pour prendre un autre exemple, d’après [37], dans Unicode il existe au
moins 33 différent caractères qui représentent le chiffre « 1 », dont des variantes correspondant aux différentes écritures (dévanagari, laotien, logographique, etc.), des variantes graphiques (U+2780 DINGBAT CIRCLED SANS SERIF
DIGIT 1) ou autres comme le chiffre 1 en tant que numérateur d’une fraction
(U+215F FRACTION NUMERATOR ONE). Sans doute, est-il toujours possible
d’associer des valeurs sémantiques distinctes à chacun de ces caractères et
ainsi de justifier leur présence dans Unicode ; l’utilité pratique de ces caractères dépendra cependant des usages des textes dans lesquels ils apparaissent.
D’une part, si un utilisateur fait une recherche sur le chiffre 1, très probablement il ne s’intéresse pas aux variations graphiques de celle-ci ; de ce point de
vue le codage des variantes comme le dingbat ou le numérateur en fraction en
tant que caractères distincts n’est pas souhaitable. D’autre part, si l’on prend
l’exemple du chiffre romain « I » (U+2160 ROMAN NUMERAL ONE), la distinction entre celui-ci et la lettre I majuscule (U+0049 LATIN CAPITAL LETTER I),
avec laquelle il est par définition graphiquement identique, est parfois pratique (car une recherche sur une valeur numérique ne devrait pas retourner
les lettres « I » du document en question), parfois impratique (dans la quasitotalité des documents un nombre romain comme « VIII » est introduit par
l’intermédiaire de lettres majuscules « V » et « I »).
En page 64, nous avons mentionné le codage des écritures logographiques
par Unicode comme un contre-exemple de son principe d’atomicité. Le logogramme chinois en tant qu’unité intuitive et aussi unité de codage, ne peut
pas être considéré comme unité indivisible, ni du point de vue graphique, ni
du point de vue phonologique, ni du point de vue sémantique. Le fait que
malgré ceci Unicode a choisi de prendre le logogramme comme unité de
base au lieu des composants ou des traits élémentaires était un choix motivé
principalement par des raisons pratiques : la compatibilité avec les codages
existants d’une part et la simplicité relative du modèle textuel d’autre part.
Aurait Unicode pris l’approche de prendre comme unité de codage non pas
le logogramme mais ses composants, le nombre de caractères codés aurait
été réduit à quelques centaines (cf. [26, pp. 140-141]) au lieu des dizaines de
milliers, au prix d’une complexification du traitement textuel (qui aurait dû
constamment gérer les problèmes de composition-décomposition).
Le cas de l’alphasyllabaire éthiopien est similaire : Unicode a décidé de
coder autour de quatre cent syllabes entières au lieu de coder voyelles et
consonnes séparément, dont le nombre ensemble ne dépasse pas la trentaine.
Ce choix se justifie par le fait que la syllabe est composée par une liaison
graphique entre la ou les consonne(s) et la voyelle, phénomène que les fontes
et les systèmes de composition classiques qui supposent une correspondance
un-à-un entre caractère et glyphe ne sont pas capables de modéliser. Encore
une fois, une représentation phonétique plus précise et plus détaillée ainsi que
28
Par exemple, l’espace insécable peut avoir un rôle typographique lorsqu’elle connecte un
signe de ponctuation à un mot en français mais aussi un rôle linguistique lorsqu’elle connecte
deux morphèmes en vietnamien.
67
Chiffres
Chiffres romains
Logogrammes
L’éthiopien
Formes
de présentation :
l’arabe, l’hébreu,
le grec
l’économie de caractères de base ont été sacrifiées en faveur d’un modélisation textuelle simplifiée.
C’est également pour un grand nombre de raisons pratiques (cette fois-ci
en heureuse coïncidence avec les principes théoriques) qu’Unicode a choisi
comme unité de base de l’écriture arabe le « graphème abstrait », au lieu de ses
allographes (ou formes contextuelles, voir page 65). Par contre, on ne retrouve
pas le même degré de cohérence pour l’écriture hébraïque, ni pour le grec.
Ces deux écritures possèdent également des formes de lettres contextuelles
(même si pour le grec le phénomène se limite à la seule lettre sigma « σ — ς »)
mais celles-ci ont été codées dans Unicode comme des caractères distincts.
Il s’agit encore une fois de raisons pratiques : grâce au nombre très limité de
formes alternatives, il était possible dès le début (c’est-à-dire dès l’existence
des machines à écrire) de faire apparaître celles-ci sur les claviers ; par conséquent, les utilisateurs se sont habitués à introduire les formes contextuelles
directement.
En résumé, il semble évident que la construction d’un système de codage universel tel qu’Unicode ne peut être faite qu’en équilibrant les approches théorique et pratique. Notamment, l’influence des usages textuels sur
la construction du modèle de texte doit de nouveau être prise en compte.
Cependant, le concept de codage universel suppose l’utilisation d’un codage
unique, un principe en contradiction avec l’existence indéniable d’usages mutuellement exclusifs. Par conséquent, la définition d’un caractère donné relèvera toujours d’un compromis entre les besoins contradictoires des différents
usages, ce qui veut dire que les codages de caractères tels qu’Unicode seront
inévitablement plus adaptés à certains usages qu’à d’autres.
Finalement, notons que l’approche non-théorique est également mise en
évidence dans le rapport technique ISO/IEC TR 15285:1998 (An operational
model for characters and glyphs) qui décrit les fondements théoriques de la
norme Unicode — et que nous présenterons plus en détail en section 1.8.7
— de la manière suivante :
In many cases, the criterion for either inclusion or exclusion
has not been articulated but is based on informal opinion about
appropriateness.
1.8.6 L A
BASE DE DONNÉES D ’U NICODE
Conscient de cette limitation et aussi de l’encombrement causé par un système de codage à plus de 100 000 caractères — dont le support est forcément
inévitable pour tout logiciel ayant accès à des informations textuelles —, Unicode propose une base de données librement accessible et téléchargeable qui
classifie ses caractères suivant de nombreux critères. C’est grâce à cette base
de données qu’il devient possible, entre autres, de distinguer lettres, chiffres,
ponctuation, idéogrammes, symboles, espaces, de savoir à quelle écriture appartient un caractère, et ainsi de suite. La base de données peut être exploitée
entre autres par des algorithmes de transformation de chaînes de caractères
qui ont comme objectif d’adapter le texte aux différents usages. Par exemple,
un algorithme de pré-traitement peut projeter la vingtaine de caractères d’espacement différents présents dans Unicode au seul caractère U+0020 avant
68
une opération de recherche.
La base de données Unicode et les divers algorithmes de transformation29 La propriété
de caractères repose sur la notion de propriété de caractère. La base de don- de caractère
nées d’Unicode n’est en réalité qu’un ensemble de correspondances entre
caractères et propriétés : une propriété peut être considérée comme une fonction entre codes de caractère et valeurs de propriété [63, UTR23]. (« At its most
general, a property can be considered a function that maps from code points to
specific property values. ») La propriété fait partie intégrante de la sémantique
du caractère et donc de la norme Unicode. (« The semantics of a character are
determined by its identity, normative properties, and behavior. »)
En reprenant le formalisme introduit en page 26, les propriétés permettent
de mieux structurer l’ensemble S, en d’autres termes, de faire un premier
pas vers une définition formelle de ce que l’on entend par « unité sémantique
textuelle » ou « caractère abstrait » (ce dernier étant un terme introduit par Unicode) :
S=
N n
[
j=0
o
(Ij , pj,1 = vj,1 , pj,2 = vj,2 , ..., pj,n = vj,n )
où N est le nombre de caractères Unicode, Ij est l’identité de l’unité sémantique j et pj,i et vj,i sont ses clés et ses valeurs de propriété associées.
Ce qu’Unicode entend par identité d’un caractère reste dans le vague mais il
s’agit sans doute de la même entité que celle définie dans Unicode par le nom
de caractère, par exemple « LETTRE MAJUSCULE LATINE A ». L’interprétation du
caractère abstrait donnée dans le Technical Report on Character Encoding
Model [63, UTR17] : « Le mot abstrait signifie que ces objets sont définis par
convention »30 porte également sur cette même identité.
Après nos résultats qui montrent la nécessité d’une approche intension- La BD d’Unicode
nelle à définir un codage universel (voir page 60), il n’est pas surprenant de incarne une approche
voir que la norme Unicode n’a pu éviter de compléter sa méthode de construc- intensionnelle
tion extensionnelle avec une description intensionnelle réalisée par la base
de données Unicode. L’acceptation que les propriétés sont intrinsèques à la
définition du caractère représente clairement un déplacement de méthodologie depuis l’extensionnel vers l’intensionnel. Vu les difficultés rencontrées par
Unicode de reconcilier les approches théorique et pratique à la conception
du codage, la base de données est un palliatif qui devient absolument nécessaire pour l’automatisation des traitements textuels même les plus simples
comme la conversion de casse, l’extraction de données numériques, le tri lexicographique ou l’identification des endroits où un retour à la ligne est permis.
Néanmoins, malgré tous ses aspects circonstanciels, l’introduction de la BD
d’Unicode représente sans doute le premier pas d’une transition depuis la
modélisation par un simple répertoire de données (la table de codage) vers
une approche qui s’inscrit dans le domaine de la représentation des connaissances. Cette dernière suppose d’une part une articulation plus fine dans la
manière de représenter des ressources — les signes d’écriture dans notre cas
29
On pourrait également dire « projection » ou « pliage » pour employer le terme proposé par
la norme Unicode (character folding).
30
Phrase traduite par l’auteur.
69
—, d’autre part une description des mêmes ressources non seulement dans
leur individualité mais également à travers les éventuelles relations qu’elles
peuvent entretenir. La présente thèse tentera de développer davantage cette
approche, en appliquant certaines notions de la représentation des connaissances à la modélisation textuelle.
La BD en format XML
D’ailleurs, et un peu dans le même esprit, très récemment (avril 2007), un
format XML de la BD d’Unicode a été sorti dans le cadre du rapport technique
no 42, où chaque caractère (ou groupe de caractères) est représenté par un élément XML et ses propriétés par les attributs de celui-ci. Le document XML est
même extensible par de nouveaux attributs, pourvu que ceux-ci soient clairement séparés des attributs Unicode officiels à l’aide d’espaces de nommage.
Par rapport à la forme précédente de la BD — une collection de fichiers texte
à formats variés —, sa mise à disposition en XML représente un pas en avant,
vers une formalisation plus rigoureuse des propriétés de caractères.
Nous avons vu que la nécessité d’intégrer une base de données dans la
norme Unicode était la conséquence de l’existence de multiples usages textuels. Unicode ne prétend — et ne peut prétendre — cependant pas prévoir
tous les usages possibles, il doit donc forcément en choisir ceux qu’il considère les plus importants ou les plus courants. Les usages non prévus ou prévus mais non couverts par la norme se confrontent à un ensemble immense
et à peine ordonné de caractères ; en d’autres termes, Unicode s’impose ses
propres limitations d’usage. En revanche, le modèle de texte que nous allons
proposer permettra, à travers la généralisation de l’utilisation des propriétés,
de multiplier les usages simultanés du même texte, tout en évitant les problèmes de passages à l’échelle qui sont le fléau des modèles extensionnels
tels qu’Unicode.
1.8.7 U NE
TENTATIVE DE RENFORCEMENT THÉORIQUE :
LE RAPPORT TECHNIQUE ISO/IEC TR 15285:1998
Nous avons vu en section 1.8.4 que la manière dont la norme Unicode
tente de préciser ce qu’elle entend par caractère se base sur une mise en
opposition avec le concept de glyphe. Face à l’ambiguïté de la norme à ce
propos (que nous avons montrée dans la même section), un rapport technique
ISO (ISO/IEC 15285:1998, [37]) a été rédigé afin de clarifier la différence des
deux concepts et la méthodologie d’Unicode en général. Dans la présente
section il sera question de commenter critiquement ce rapport qui reste le
document le plus sérieux et le plus formel à notre connaissance qui traite de
ce sujet.
Nous avons évoqué l’insuffisance descriptive de la dichotomie que l’on
trouve dans certaines définitions du glossaire d’Unicode : les catégories de
caractère en tant qu’unité abstraite du contenu textuel et de glyphe en tant
que signe concret visuel sont censées représenter deux partitions de la totalité
des signes qui peuvent potentiellement apparaître dans un texte écrit. Malgré
le titre du rapport technique en question (An operational model for characters
and glyphs), celui-ci présente un modèle plus articulé (par la reprise des définitions de base des normes ISO/IEC 9541-1:1991 et ISO/IEC 10036:1996 [36]),
notamment par la distinction entre caractère, glyphe, image de glyphe (glyph
70
image), représentation de glyphe (glyph representation) et forme de glyphe
(glyph shape) :
CHARACTER.
A member of a set of elements used for the organisation, control, or representation of data. (ISO/IEC 10646-1:1993)
GLYPH. A recognizable abstract graphic symbol which is independent of any specific design. (ISO/IEC 9541-1: 1991)
GLYPH IMAGE. An image of a glyph, as obtained from a glyph
representation displayed on a presentation surface. (ISO/IEC 95411:1991)
GLYPH REPRESENTATION. The glyph shape and glyph metrics
associated with a specific glyph in a font resource. (ISO/IEC 95411:1991)
GLYPH SHAPE. The set of information in a glyph representation
used for defining the shape which represents the glyph. (ISO/IEC
9541-1:1991)
La distinction entre ces cinq concepts correspond bien à nos propos
concernant la différence entre glyphe et signe typographique mais aussi
concernant les différents degrés de l’abstraction d’un signe donné (voir p. 65).
Ainsi, la définition du glyphe ci-dessus semble équivalente à notre signe typographique31 , la forme de glyphe à notre glyphe et l’image de glyphe est
la manifestation visuelle la plus concrète possible d’un signe (l’image telle
qu’elle apparaît sur un dispositif donné)32 .
Le rapport technique mentionne deux domaines de représentation textuelle : le domaine de traitement et le domaine de présentation.
Character information has two primary domains [. . .]. The first
pertains to the processing of the content, that is, the meaning or
phonetic value of the character information. [. . .] The second pertains to the presentation of the content of the character information
[. . .].
Le modèle de texte décrit par le rapport technique se base donc sur la supposition qu’il existe deux types majeurs d’opérations textuelles : celles liées
au traitement du contenu et celles liées au traitement de la présentation. En
même temps, on ne nie pas l’existence d’opérations qui ne trouvent leur place
dans aucune de ces deux catégories :
[...] processes that perform transformations from one domain
to the other are aware of both the content and appearance of characters. [...] a paragraph-level hyphenation process is an example
of a layout process that requires content information.
Les remarques qui suivent cette observation sont très importantes :
31
Il faut noter que cette incohérence terminologique par rapport à l’usage du terme glyphe est
omniprésente dans la littérature : même la norme Unicode l’emploie de manière contradictoire
vis-à-vis du rapport technique en question qui pourtant est censé la complémenter.
32
En faisant peut-être abstraction (encore une fois !) de phénomènes aléatoires comme la
diffusion d’encre.
71
It is not possible, in general, to code data in such a way as to
optimize one process without reducing the performance of other
processes. Even within the content domain, the nature of the character coding employed for textual data affects the type or types
of processing to be performed on the data; no single coding can
optimize more than a few such potential processes.
Raph Levien, dans son critique du format SVG [45], formule essentiellement
la même idée :
Balancing semantics and presentation is considered a very difficult problem. There are certainly no easy answers; the systems
that have acheived both well have done so only because of considerable effort.
L’avis formulé dans ces deux documents est donc qu’il est très difficile,
voire impossible, de créer un modèle de texte générique qui serve de multiples usages textuels. Même en restant dans le domaine du traitement de
contenu (en écartant donc toute considération de formatage), le codage de caractères employé devra toujours être adapté par des transformations aux usages
spécifiques.
Nous partageons également l’avis selon lequel un modèle de texte universel, ayant la même puissance descriptive pour tout usage, ne peut pas exister.
Avec la présente thèse, nous avons cependant comme objectif de démontrer
qu’il est possible de concevoir des modèles de texte qui s’approchent de cet
idéal davantage que le modèle représenté par Unicode et par le rapport technique ISO 15285.
SÉMANTIQUE
EN CONTEXTE
Le rapport technique mentionne également l’importance du contexte de
l’usage dans l’interprétation de la sémantique d’un caractère donné (un point
d’exclamation signifie autre chose dans un roman que dans une formule mathématique). Il affirme qu’Unicode n’est pas concerné par cet aspect de la
sémantique de ses caractères :
What [Unicode] does not do—and this is perhaps the most important point of this annex—is formally define the data or units of
information that graphic characters are supposed to represent; that
is, no formal semantics are specified to assist in the task of interpreting the so-called data supposedly being represented by a character. Instead, [Unicode] assumes that the semantics of a character is
either (1) self-evident or (2) subject to conventions adhered to by
the user of the character, namely, the application.
Sémantique inhérente
L’affirmation ci-dessus serait entièrement vraie pour les codages histoou sémantique riques tels que ASCII ; elle l’est nettement moins pour Unicode. D’une part,
contextuelle ? Unicode montre une certaine volonté de désambiguïser, de décontextualiser
la sémantique de ses caractères par la création de doublons : il suffit de penser aux exemples comme la lettre majuscule « I » et le chiffre romain « I »,
le point-virgule et le point d’interrogation grec, les alphabets entiers latin et
grec dupliqués en guise de signes mathématiques, et ainsi de suite. D’autre
72
part, les propriétés de caractère définies dans la base de données Unicode
sont également porteuses d’une sémantique indissociable de l’identité du caractère. Unicode s’est éloigné de l’approche historique qui ne précise guère
l’information portée par le caractère codé, tout en réalisant qu’il serait probablement impossible d’éviter complètement la polysémie parmi les caractères
du codage, car cette polysémie découle non pas de l’imprécision des définitions données par la norme mais des pratiques d’utilisation.
1.8.8 L E
PRINCIPE ( OU LE MYTHE ) DE TEXTE BRUT
Dans la présente section nous souhaitons examiner la notion de texte brut
afin de saisir ce qui distingue celui-ci d’autres formes textuelles. Ce qui justifie notre intérêt à cet égard est que le texte brut, lieu commun de l’ingénierie
informatique, semble bénéficier d’une perception privilégiée comme étant le
format de document le plus simple que possible qui a en addition la propriété
d’être lisible par l’humain. Grâce à cette simplicité perçue, le texte brut sert
comme format d’échange textuel de base entre les logiciels et systèmes les
plus variés. Dans la suite, nous souhaitons mettre en question le statut particulier du texte brut Unicode en démontrant que derrière la simplicité apparente
se cache une complexité considérable. Cette démonstration servira ensuite
à justifier notre position qui relativise l’importance du modèle de texte brut
comme format textuel de base en faveur d’un modèle plus complexe en apparence mais probablement plus clair et logique en réalité.
LE
TEXTE
UNICODE : S’AGIT-IL
DE TEXTE BRUT ?
Le principe de texte brut d’Unicode affirme que la norme n’est concernée que par le contenu d’un document, à l’opposition de sa structure, de sa
présentation, de son support, etc. Dans le glossaire on trouve la définition
suivante33 :
DÉFINITION 3 (TEXTE
BRUT SELON LA DÉFINITION D’UNICODE)
Texte informatique qui ne comprend que des suites d’unités de stockage d’une
norme donnée sans contenir d’autres informations de formatage ou de structure. On utilise fréquemment l’échange de texte brut entre ordinateurs qui ne
partagent pas un même protocole de niveau supérieur.
Seules les chaînes de caractères Unicode qui ne contiennent pas d’informations de formatage ou de structure sont considérées donc, selon cette définition, comme du texte brut. Par conséquent, les documents HTML ou XML HTML et XML :
ne sont pas de documents en texte brut car ils ont une structure non-linéaire texte brut ou non ?
(arborescente) et/ou une présentation définies à un niveau plus haut que celui des caractères individuels, notamment au niveau du balisage. Paradoxalement, d’un autre point de vue, ces documents restent néanmoins de simples
chaînes de caractères Unicode et sont lisibles par l’humain, à part une poignée
de caractères tels que « < > / & ; » qui s’interprètent de manière différente par
rapport à leur sémantique « par défaut ».
33
Traduction par P. Andries.
73
D’autre part, tout texte, qu’il soit composé de caractères Unicode ou non,
contient forcément des informations de structuration. Tout d’abord, une structure textuelle conventionnelle est véhiculée par des signes de ponctuation tels
La structure inhérente que l’espace, les parenthèses, les tirets, le point, la virgule, les guillemets, etc.,
au texte pour ne pas mentionner le caractère de retour à la ligne dont le rôle principal
est de séparer les paragraphes. D’un point de vue fonctionnel, il s’agit de véritables balises : le caractère de retour à la ligne est équivalent à la balise HTML
<p>34 , alors que ‘« ’ et ‘ »’ sont équivalents à <quote> et </quote>. Avoir à
disposition et employer ces caractères au lieu du balisage explicite correspondant relève tout simplement d’une convention. Dans certaines écritures (thaï,
chinois, etc.), il n’est pas habituel de séparer les « mots » par des espaces.35 Si
pour une raison particulière (par exemple, l’aide au traitement automatique)
on choisit de séparer les mots chinois ou thaï dans un texte, cette action doit
sans aucune doute être vue comme une action de structuration, que la séparation soit faite par des espaces ou par des balises. Il n’y a donc pas de raison
scientifique ou linguistique autre que les conventions historiques, d’associer
certains types de ponctuation au contenu textuel (et donc de niveau inférieur)
et d’autres à la structure (et donc de niveau supérieur) du même document.
CARACTÈRES
CONTRE BALISAGE DANS LE TEXTE
UNICODE
Le rapport technique no 20 d’Unicode, « Unicode in XML and other Markup Languages », traite (entre autres) du choix entre représenter l’information
en tant que caractère, élément d’une chaîne unidimensionnelle, ou bien en
tant que balise, nœud d’une structure arborescente :
Encoding text as a sequence of characters without further information leads to a linear sequence, commonly called plain text.
Character follows character, without any particular structure. Markup, on the other hand, defines a hierarchical structure for the
text or data. In the case of XML and most other, similar markup
languages, the markup defines a tree structure. [. . .] Operations
that are easy to perform on trees are often difficult to perform on
linear sequences and vice versa. By separating functionality between character encoding and markup appropriately, the architecture becomes simpler, more powerful and longer-lasting.
La linéarité
Deux remarques doivent être faites à ce point. Premièrement, il existe de
du texte brut Unicode nombreux cas où une telle séparation fonctionnelle entre les types d’informan’est qu’une apparence tion linéaire et hiérarchique devient ambiguë. Prenons l’exemple d’un chiffre
en exposant : « 5 ». « Être en exposant » est une propriété présentationnelle (qui
est à la fois, bien évidemment, porteuse de sémantique, indicatrice de structure, et ainsi de suite) associée à un signe individuel (ce qui n’exclut pas la
possibilité d’avoir plusieurs signes successifs ayant cette même propriété). La
propriété d’être en exposant est une information qui se rattache à un signe
donné et qui n’a donc pas d’existence indépendamment d’un signe visuel.
34
La spécification HTML n’oblige pas l’utilisation de la balise de fermeture </p>.
Par conséquent, il n’est même pas possible de parler de mots dans le cas des langues
correspondantes, du moins dans un sens équivalent à celui des langues occidentales.
35
74
Texte
RLE
gauche-à-droite
LRE
droite-à-gauche PDF g.à.d. PDF d.à.g.
FIG. 1.5 – Imbrication hiérarchique de texte dans une chaîne Unicode à l’aide
de « caractères balises ».
FIG. 1.6 – Autre exemple de structure hiérarchique à l’intermédiaire de caractères Unicode d’annotation japonaise : le caractère U+FFF9 marque le début
de l’annotation, le caractère suivant est le kanji annoté (hito, homme), l’annotation (en hiragana) suit le caractère U+FFFA, la fin de l’annotation est marquée
par U+FFFB.
Puisque ceci relève d’une organisation hiérarchique de l’information, sa représentation adaptée d’après le rapport technique ci-dessus serait du balisage.
En même temps, l’existence du caractère Unicode U+2075 SUPERSCRIPT FIVE
— en opposition flagrante avec les recommandations du rapport technique
— peut également être justifiée par le fait qu’il s’agit d’une propriété isolée
associée à un signe isolé qui peut pour cette raison être représentée comme
de l’information appartenant au texte brut. Chacun de ces deux niveaux de représentation a ses propres avantages et inconvénients. Dans la présente thèse,
nous allons cependant proposer un niveau représentationnel intermédiaire
entre caractère et balisage qui allie les avantages théoriques et pratiques des
deux approches.
Deuxièmement, il existe de véritables caractères balises dans Unicode Caractères balises
qui permettent de définir une imbrication hiérarchique dans le texte. Sur la (RLE, LRE, roubi)
figure 1.5, des caractères non-imprimables RLE et LRE (imbrication droite-àgauche et gauche-à-droite) permettent d’indiquer explicitement la direction
du texte suivant jusqu’à un caractère PDF (dépilement de formatage directionnel). En figure 1.6, les trois caractères roubi (annotation japonaise des kanji par
des hiragana), U+FFF9, U+FFFA et U+FFFB, servent à attacher de l’annotation
à un caractère donné. Dans les deux cas, il s’agit de données structurées en
arbre, même si cette structure est « déguisée » en un flot linéaire de caractères,
et même si dans le seconde exemple l’arbre ne possède que deux niveaux car
l’imbrication récursive des caractères d’annotation n’est pas permise.
CLARIFICATION
SUR LA NOTION DE STRUCTURE( S ) D’UN DOCUMENT
Une dernière remarque doit être faite concernant la citation ci-dessus, ti- Un document possède
rée du rapport technique « Unicode in XML and other Markup Languages ». de multiples structures
Tout en admettant l’importance de bien équilibrer les niveaux représentationnels des documents, nous contestons l’idée que ces deux types de structures
soient suffisantes. En général, nous contestons toute affirmation parlant de la
structure de tel ou tel document car nous considérons qu’aucun document
ne peut être décrit par une seule structure. Nous employons ici la notion de
structure comme le synonyme de celle d’organisation : il s’agit d’un ensemble
de relations entre éléments d’information. Pour comprendre pourquoi un do75
cument possède non pas une mais des structures multiples, il suffit de réaliser
que les relations (et donc la structure) observées dépendent de notre choix
d’ensemble de base. Si l’on choisit le caractère comme unité d’information, la
structure observée aura une prépondérance linéaire. Si l’unité de structuration
est le syntagme liguistique, on observera très probablement une structure arborescente. À un niveau supérieur, le paragraphe peut être considéré comme
une unité structurelle d’un discours écrit à partir duquel sont constituées les
sections qui à leur tour forment des chapitres, etc. Cette arborescence sera
cependant différente de l’arborescence syntaxique, rhétorique ou présentationnelle du même texte (cette dernière étant composée de lignes, de pages,
etc., qui ne sont nullement des unités discursives, rhétoriques ou syntaxiques).
Document 6= arbre
Une fois cette conception acceptée, la pauvreté d’une structure arborescente « à la XML » ayant comme feuilles des chaînes Unicode, comparée à la
description de l’ensemble des informations qui constituent un document, paraît évidente. C’est à partir d’une direction légèrement différente — celle de
l’indissociabilité du contexte des éléments de tous les niveaux du document
—, que l’article « Characters are not simply names, nor documents trees » de
Rowley et Plaice [55] arrive à la même conclusion de l’insuffisance de la modélisation du document textuel en tant que chaînes Unicode organisées dans
une structure arborescente. Néanmoins, ces considérations sortent du cadre
de la présente thèse qui se restreint à la modélisation du texte de niveaux
inférieurs à celui du paragraphe (qui d’ailleurs semble être une des rares unités structurelles à la fois sémantiques, discursives et présentationnelles, ce qui
était une des raisons de l’avoir choisi comme une sorte de frontière naturelle
de la portée de nos études). Comme annoncé au début de cette thèse, nous
nous intéressons uniquement aux structures — en pluriel — des niveaux inférieurs à celui du paragraphe.
UNE
DÉFINITION ALTERNATIVE DE LA NOTION DE TEXTE BRUT
Nous avons vu que le texte brut Unicode — qui consiste donc en une
chaîne de caractères Unicode qui adhère à la norme — peut très bien contenir
de l’information structurelle ou présentationnelle, implicitement ou explicitement, sans le moindre recours à un protocole de niveau supérieur (comme
par exemple le format XML). Ainsi, il nous paraît utile de présenter une définition alternative du texte brut, plus précise que celle donnée dans le glossaire
d’Unicode. Cette nouvelle définition — qui ne sera, bien entendu, qu’une
seule parmi les définitions possibles — nous conviendra mieux dans l’objectif
d’exiger de la part du texte brut une certaine « simplicité ».
La notion de texte brut
L’idée qui mène à cette nouvelle définition est la suivante : la qualification
est liée à celle ou non d’un document comme du texte brut est tout d’abord une question
de l’usage pratique qui dépend principalement de son usage. Par exemple, un logiciel
d’édition de texte primitif (sans coloration syntaxique, sans correcteur d’orthographe, etc.) peut très bien considérer un document HTML comme étant un
flot de caractères Unicode simple et uniforme. Ceci n’est plus le cas lorsque
cet éditeur intègre un correcteur d’orthographe qui doit savoir distinguer entre
noms de balises et attributs HTML d’une part et contenu textuel d’autre part,
pour ne corriger que ce dernier. On peut voir que le même document peut,
selon le contexte d’usage, être qualifié ou non de texte brut.
76
Il est donc évident que la notion de texte brut ne peut être définie sans
recourir à celle d’usage. La définition correcte d’un concept si complexe que
celui d’usage nécessite des préparations considérables, même si nous nous
permettons à nous restreindre à un contexte de manipulation informatique
d’une chaîne d’éléments textuels. Pour cette raison, nous ne chercherons pas Une interprétation
ici à le définir de manière précise ; plutôt, nous allons considérer que l’usage approximative
comprend — sans être limité à — un ensemble d’opérations textuelles que l’on de la notion d’usage
peut appliquer à une chaîne de caractères.
Si l’on reprend le formalisme algébrique introduit en section 1.4.2, l’ensemble Σ∗Uni de chaînes de codes Unicode peut être regardé comme un
monoïde libre avec la chaîne vide comme élément neutre et la concaténation comme opérateur. (Rappelons que ΣUni = {0, ..., NUni }, NUni étant le
code de caractère maximal.) Une opération textuelle serait ainsi une fonction
f : Σ∗Uni 7→ Σ∗Uni .
Il faut remarquer cependant que le langage de textes Unicode valides,
LUni , est plus restreint que Σ∗Uni (autrement dit, LUni ⊂ Σ∗Uni ) car il est possible de créer des chaînes de caractères non conformes à la norme Unicode
(par exemple, en mettant un caractère combinant tel qu’un accent en début
de chaîne, sans caractère de base).
Nous allons maintenant procéder à la (re)définition de la notion de texte
brut à l’aide de celle de l’usage36 :
DÉFINITION 4 (TEXTE
BRUT)
Un texte K = c1 c2 ...cn est texte brut par rapport à un usage donné s’il existe au
moins une transformation dans le cadre de cet usage qui ne respecte aucune
relation entre les éléments textuels constituant K au-delà du fait que ceux-ci
forment une séquence.
Le sens de cette nouvelle interprétation du texte brut est que, dans le Le sens de la définition
contexte d’un usage donné, une chaîne peut être considérée comme telle
dans l’unique cas où elle est composée d’éléments indépendants au-dessus
desquels aucune structure n’est définie, ou en d’autres termes, qui n’entretiennent aucune relation (de « dépendance » ou autre) entre eux. Par exemple,
le texte Unicode sur la figure 1.6 n’est pas de texte brut par rapport à l’usage
« affichage » (ou « composition ») car la sous-chaîne des deux hiragana entre les
FF
caractères FF
FA et FB s’affiche de manière différente lorsqu’elle est composée
seule que lorsqu’elle est composée comme faisant partie de l’annotation.
Une telle définition du texte brut est pertinente parce que la « simplicité »
perçue d’un document textuel, aussi bien pour l’humain qui l’interprète en
le lisant que pour des algorithmes de traitement automatique, dépend essentiellement du nombre de « règles » dont la connaissance est nécessaire afin de
réussir à interpréter correctement le texte. Bien entendu, le critère formulé par
notre définition n’est ni suffisant ni nécessaire pour garantir la lisibilité d’un
texte ; néanmoins, on peut affirmer avec certitude qu’un texte qui ne se qualifie pas comme du texte brut par rapport à un usage possède une certaine
complexité qui rend son interprétation plus difficile.
36
J’exprime ma gratitude envers M. Chris Rowley pour avoir apporté des précisions par rapport à cette définition.
77
INTERACTIONS
ENTRE CARACTÈRES
UNICODE
ADJACENTS
Grâce à leur simplicité, les chaînes de caractères codées suivant des
normes historiques (telles que ASCII ou les codages ISO) peuvent réellement
être considérées comme du texte brut — une suite uniforme de caractères indépendants — par rapport à un grand nombre d’usages : afficher ou manipuler
une chaîne ASCII a pendant longtemps été le b-a-ba de la programmation de
l’ordinateur. Ce n’est plus le cas des chaînes Unicode, à cause de la complexité inhérente à la norme37 . En théorie comme en pratique, les caractères
d’une chaîne Unicode peuvent entretenir des relations entre elles, relations
qui doivent être prises en compte lorsque la chaîne est affichée ou traitée. Les
exemples en sont abondants ; en addition aux « caractères-balises » dont nous
avons présenté quelques exemples en page 75, voici quelques phénomènes
où des caractères Unicode adjacents entretiennent de telles relations entre
eux :
– Lorsqu’un caractère est suivi par un ou plusieurs caractères combinants
(e+´=é), ces derniers doivent être considérés comme étant inséparables :
– lors de l’affichage, un saut de ligne ne peut intervenir entre eux ;
– lorsque la chaîne de caractères est inversée, l’ordre base-combinant
doit être gardé (Le´on 7→ noe´L) ;
– lorsque le nombre de caractères dans une chaîne est calculé, pour
certains usages les caractères combinants ne comptent pas comme
des caractères individuels.
– Lorsqu’un caractère CR (retour-chariot) est suivi par un caractère LF (passage à la ligne), les deux doivent toujours rester inséparables et comptent
comme un seul caractère de terminaison.
– Lorsqu’un caractère ZWJ (connecteur à chasse nulle) ou NBSP (espace
insécable) se trouve entre deux autres caractères, ces deux derniers ne
peuvent pas être séparés par un saut de ligne.
– etc.
En résumé, si l’on admet que le terme texte brut est censé véhiculer une
idée de simplicité de lecture et d’interprétation (pour l’humain et pour l’ordinateur), conformément à la définition que nous venons d’établir, nous devons alors conclure que le texte en caractères Unicode ne possède en général
pas cette simplicité. Les caractères d’une chaîne Unicode, adjacents ou non,
peuvent entretenir des relations entre eux de sorte que même certaines opérations textuelles élémentaires doivent les prendre en compte afin de rester
conformes à la norme Unicode. Dans le cadre de cette norme, être texte brut
n’est plus garantie de simplicité.
1.8.9 R ÉSUMÉ DES
PROBLÈMES THÉORIQUES
LIÉS AUX PRINCIPES D ’U NICODE
L’importance d’Unicode
Notre examen détaillé de la norme Unicode était nécessaire principalement à cause du statut particulier de celle-ci : codage de caractères à la fois
37
Ici nous faisons bien évidemment abstraction de toute considération de représentation
comme les mécanismes de sérialisation (Character Encoding Scheme) et les formes naturelles
de caractères (Character Encoding Form).
78
global (car il tente de couvrir la totalité des écritures du monde, mais aussi de
nombreux autres systèmes de notation) et unique (car il est censé supplanter
tous les autres codages sur toutes les plates-formes), il devient indispensable
en tant que modèle de représentation textuelle. Le texte en caractères étant
le format d’échange textuel de loin le plus courant aujourd’hui — un statut
qui ne changera probablement pas dans l’avenir proche —, le modèle de texte
que propose Unicode représente une influence extrêmement importante sur
la capacité représentationnelle de tout texte numérique ou numérisé. L’informatique a élargi les usages potentiels du texte — la recherche automatique,
l’indexation, le traitement de texte, les hyperliens n’en sont que les exemples
les plus évidents — mais en même temps les usages disponibles ainsi que leur
puissance et leur convivialité sont très dépendants des modèles informatiques
qui les rendent opérationnels. Étant donnés les usages existants mais aussi
ceux dont une future invention est fonction des modèles d’aujourd’hui, est-ce
que le modèle de texte offert par Unicode — avec son immense répertoire de
caractères, sa base de données de propriétés et sa vision du texte brut — est
un modèle avec suffisamment de puissance et de potentiel ?
Vis-à-vis de la situation chaotique d’innombrables codages nationaux des
années 1980 et 1990 et des difficultés dans la création de documents multilingues, Unicode représente un saut qualitatif indéniable. Au-delà de ses avantages évidents, dans cette section de la thèse nous avons essayé de mettre à
l’examen ses fondements théoriques. Notre objectif n’était pas de contester
l’appartenance ou l’omission de tel ou tel caractère de la norme : pour une
base de données d’une si grande taille l’incohérence est probablement inévitable. Nous avons cependant contesté :
– l’approche même d’Unicode concernant la modélisation de texte : la Les points
notion de caractère en tant qu’unité atomique textuelle et en tant que problématiques
simple code numérique ;
– les principes informels selon lesquels Unicode décide d’un signe s’il a
sa place dans la norme ou non ;
– la possibilité de désigner un niveau d’abstraction unique et non-ambigu
où un signe est suffisamment « abstrait » pour devenir atome d’une représentation textuelle d’échange ;
– d’une façon similaire, nous avons contesté la possibilité même théorique de choisir a priori un niveau de précision sémantique pour un
caractère donné qui convienne ensuite à tout usage ultérieur de celuici ;
– l’aspect pratique de l’usage d’un répertoire énorme de signes qui ne
cesse de croître et que la base de données d’Unicode n’est capable
d’ordonner et d’interpréter que partiellement ;
– l’effort de maintenir l’apparence d’un modèle simple — le texte brut
— malgré la complexité ad hoc de certains aspects de la norme ;
– finalement et en somme, nous avons contesté l’approche fondamentalement extensionnelle à définir un modèle de texte, à travers la simple
énumération de l’ensemble de base de ses éléments constitutifs.
Un des objectifs majeurs de la présente thèse est de démontrer que tous Les problèmes sont liés
les problèmes que nous venons de recenser ont une origine commune, notamment la nature atomique du caractère : être indivisible signifie que le caractère
79
La solution, en forme
embryonnaire : la BD
d’Unicode
Un premier pas
vers la représentation
des connaissances
se définit par lui-même. Modifier ou compléter cette définition afin de rendre
plus abstraite ou plus concrète la description d’un caractère — description
qui peut porter aussi bien sur sa sémantique que sur sa présentation — n’est
possible que de deux manières : soit par l’introduction d’un caractère complètement nouveau dans la norme, soit en sortant du cadre du modèle de texte
brut d’Unicode en faveur de modèles étendus (comme par exemple PDF ou
SVG).
L’association de propriétés aux caractères à travers la base de données
d’Unicode était tout à fait nécessaire pour rendre le modèle utilisable. C’est
uniquement grâce à cette base de données que les opérations même les plus
primitives de traitement automatique textuel sont aujourd’hui possibles. Si
l’approche intensionnelle que représente la base de données (cf. page 60)
sauve Unicode d’une « anarchie sémiotique », cette approche reste sousemployée, d’une part, à cause de l’utilisation limitée des propriétés normatives, d’autre part, à cause de certaines vieilles habitudes de programmation
qui font que la seule clé d’identification et d’interprétation de l’élément textuel
reste toujours le code de caractère.
Plus généralement, la conception de la base de données d’Unicode se
doit à la réalisation de la nécessité d’une approche plus rigoureuse envers
la gestion des connaissances liées aux éléments textuels de bas niveau, aussi
bien dans leur individualité que dans les rapports qu’ils entretiennent. La BD
d’Unicode est un premier pas — certes hésitant et peut-être même inconscient
— dans cette direction, vers la refonte des bases de la modélisation textuelle
en s’appuyant sur des principes de la représentation des connaissances.
Unicode prend délibérément ses distances du monde de la présentation
textuelle, de la composition, de la mise en page, de la typographie. Il n’adresse
pas les problèmes de celles-ci et en tant que norme internationale, il n’est
possible non plus d’envisager dans la pratique son extension éventuelle dans
cette direction. Les systèmes informatiques de composition et de mise en page
possèdent leurs propres modèles de texte qui sont des modèles à orientation
typographique. Bien que l’unité textuelle de ces modèles visuels soit le glyphe
et non le caractère, les enjeux majeurs des deux types de modèles sont de la
même nature : nous verrons que, tout comme le modèle en caractères, les
modèles visuels adoptent de plus en plus l’approche et les idées de base des
divers systèmes de représentation des connaissances.
1.9
L A NOTION DE « PROPRIÉTÉ »
DANS LES FORMATS DE FONTE INTELLIGENTS
Introduction
L’amélioration des logiciels de composition de texte — en termes de quaet historique lité typographique dans un contexte multilingue — est entrée dans une nou-
velle ère au début des années 1990, à peu près en parallèle avec l’émergence
d’Unicode. Ceci n’est pas dû au hasard : l’idée qui a permis la conception
de modèles de texte plus puissants était celle de séparer les représentations
d’échange et finale où la première correspond au texte Unicode et la dernière
au texte en glyphes. L’intérêt de séparer le modèle d’échange en caractères du
modèle visuel en glyphes était de rendre le texte en caractères indépendant
80
des technologies et des applications de mise en page qui, de leur côté, ont
pu se développer à travers des technologies propriétaires sans bouleverser le
modèle d’échange textuel déjà établi. Nous rappelons que nous utilisons le
terme glyphe pour désigner l’image contenue dans une fonte mais aussi, pour
des raisons de simplicité, le code numérique qui est associé à l’image.
Entre la conception du modèle et les résultats pratiques, il y a eu cependant dix ans de travail de développement. Le plan ambitieux que se sont fixés
les boîtes informatiques les plus puissantes (Adobe, Apple, Microsoft) était de
passer des traitements de texte primitifs des années 1980 à des systèmes capables de reproduire algorithmiquement les résultats qualitatifs qui avaient été
lieux communs de la typographie au plomb mais aussi les propriétés complexes des écritures traditionnellement manuscrites telles que l’arabe ou les
écritures indiennes. Cela a requis des projets de développement à long terme.
Au centre des efforts de développement étaient de nouveaux formats de Pourquoi « intelligents »
fonte dits « intelligents ». Pour résumer ce qui les distingue des formats de fonte
traditionnels, voici les trois points majeurs :
1. leur conception prévoit l’emploi simultané de multiples langues et écritures dans le même document et à l’aide de la même fonte ;
2. leur reconnaissance de l’indépendance du caractère et du glyphe, et plus
particulièrement des correspondances multiple-à-multiple qui peuvent
exister entre caractères et glyphes ;
3. la possibilité de définir des manipulations sur les glyphes qui prennent
en compte le contexte du glyphe en question que représentent les
chaînes de glyphes précédente et suivante ainsi que les diverses propriétés de ces glyphes.
Vu d’un autre angle, il s’agit néanmoins encore une fois d’un déplace- Fonte intelligente =
ment du principe organisateur depuis l’extensionnel vers l’intensionnel. Avec fonte intensionnelle
la multiplication drastique d’écritures et de langues à prendre en charge, le
nombre de signes typographiques s’est également multiplié. Il ne suffisait
plus de considérer la fonte comme un simple répertoire de glyphes : il a
fallu décrire ceux-ci, d’abord les catégoriser par écriture et par langue, puis
décrire leur utilisation. De ce point de vue, les règles de trasformation que
contiennent les fontes intelligentes font partie de l’intension des glyphes.
Nous n’allons donner ici ni une introduction ni une présentation détaillée
des différents formats existants : l’ouvrage [28] les a déjà faites. Nous n’allons
pas non plus analyser et comparer en profondeur la puissance de ces différents
formats car ceci a déjà été fait en longueur dans l’article [14] de l’auteur. Notre
intérêt se restreindra à ce qui est le plus pertinent pour cette thèse : les modèles
de texte associés aux fontes intelligentes.
1.9.1 L E
MODÈLE DE TEXTE COMMUN AUX DIFFÉRENTS FORMATS
INTELLIGENTS
Le principe de base du processus de formatage n’a pas changé depuis TEX :
il s’agit de passer depuis une représentation textuelle d’échange à une représentation finale, par l’intermédiaire d’une (ou de plusieurs) représentation(s)
81
transitionnelle(s). Ce processus comprend au moins un changement de modèle à un certain moment de la composition : il s’agit du passage du modèle
en caractères au modèle en glyphes. Les fontes intelligentes sont capables de
décrire des correspondances multiple-à-multiple entre caractères et glyphes,
ce qui permet non seulement l’emploi automatisé de ligatures mais aussi une
différence de granularité entre les deux représentations ; par exemple, dans
le texte coréen en caractères l’unité pertinente peut être le jamo (le segment
alphabétique) alors que les glyphes définis dans la fonte correspondent aux
syllabes. Dans ce dernier exemple, il s’agit d’une correspondance trois-à-un,
voire quatre-à-un.
LA
PROPRIÉTÉ
La propriété
Dans le modèle de texte caractère-glyphe, la propriété est considérée
en tant que supplément comme une information qui s’ajoute à l’élément textuel. Nous avons pu voir,
de l’élément textuel par exemple, qu’Unicode distingue entre l’identité du caractère d’une part, et
L’indice de glyphe
en tant qu’abréviation
de l’ensemble
des propriétés
de celui-ci
Propriétés invariantes
Une distinction
purement pratique
La structure identique
de la chaîne
de caractères
et de la chaîne
de glyphes
ses propriétés d’autre part. La fonte s’organise selon le même principe : l’indice de glyphe renvoie non seulement à une image mais aussi à un ensemble
d’informations qui la décrivent, telles que des propriétés métriques, le système
d’écriture, des instructions ou hints, le comportement contextuel, etc. Ainsi,
l’indice de glyphe est en quelque sorte un référencement, une abréviation de
l’ensemble d’informations qui décrivent le glyphe38 .
Les propriétés attachées aux caractères par l’intermédiaire du standard Unicode ou aux glyphes par l’intermédiaire des fontes restent, par conséquent,
invariantes au long de la chaîne. D’autres propriétés, comme la position horizontale ou verticale, le corps, la couleur, s’associent plutôt aux instances
des éléments textuels (à des positions dans la chaîne). Cette distinction entre
propriétés invariantes et propriétés d’instance n’est, en réalité, qu’une considération pratique d’implémentation : pour des raisons d’économie de stockage,
il est toujours souhaitable d’éviter la réplication illimitée d’une information
qui ne change pas. Puisqu’une propriété invariante est constante pour chaque
instance d’un caractère ou d’un glyphe dans un texte, même s’il n’existe pas de
différence conceptuelle entre propriétés d’instance et propriétés invariantes, il
n’est pas surprenant que les deux types de propriété peuvent représentées de
deux manières indépendantes dans les modèles d’implémentation des différents logiciels de composition de texte. Ainsi, le format de fonte Graphite distingue entre propriété de glyphe (en tant qu’élément de la fonte) et propriété
de case (en tant qu’instance de glyphe dans la chaîne).
Structurellement parlant, le texte en caractères et le texte en glyphes s’organisent donc d’exactement la même manière : il s’agit de chaînes d’indices
numériques où à chaque position dans la chaîne on peut associer un ensemble
de propriétés39 . Cet ensemble de propriétés se complète par les propriétés invariantes, référencées indirectement à travers les codes de caractère ou les
indices de glyphe.
38
Plus précisément, puisque l’unicité du code de glyphe est restreinte à la fonte — deux
glyphes distincts venant de deux fontes différentes peuvent avoir le même identifiant interne
—, c’est le couple (indice de glyphe, fonte) qui doit être considéré comme identifiant unique.
39
Souvent on associe la propriété à un intervalle d’éléments textuels ; il ne s’agit pas là d’une
différence conceptuelle mais tout simplement d’une mesure d’optimisation de stockage.
82
CORRESPONDANCES
ENTRE LA CHAÎNE DE CARACTÈRES
ET LA CHAÎNE DE GLYPHES
Nous n’avons pas encore mentionné un aspect important du modèle de
texte caractère-glyphe : il s’agit du besoin de maintenir des correspondances
entre éléments de la chaîne de caractères d’entrée et éléments de la chaîne de
glyphes de sortie. Pour plusieurs raisons, il est primordial pour tout système
de composition de texte de suivre les correspondances entre caractères du
texte d’entrée et glyphes du texte composé. D’une part, pendant le processus
de composition même, il arrive un moment où le texte d’un paragraphe déjà
composé doit être coupé en lignes. Cependant, certaines opérations comme
la césure s’effectuent sur des mots, c’est-à-dire sur des chaînes de caractères
alors que le paragraphe composé est essentiellement une suite de glyphes et
d’autres informations visuelles. Il s’ensuit que le système de composition doit
être capable de retrouver les caractères d’origine à partir desquels les glyphes
du paragraphe ont été choisis, et ceci n’est possible qu’en connaissance des
correspondances entre les deux textes. D’autre part, depuis l’existence de
documents interactifs (cf. section 1.7), ces correspondances demeurent pertinentes après le processus de formatage car elles sont essentielles pour assurer l’interactivité du document généré (l’extraction du contenu, la recherche,
l’indexation).
En réalité, rien ne garantit que le processus de formatage soit une transformation bijective entre la chaîne de caractères et la chaîne de glyphes : si
par exemple une fonte ne contient pas de glyphe dédié à un caractère donné,
la pratique courante est d’y faire associer un glyphe spécial non défini (notdef). Puisque notdef peut être l’image de plusieurs caractères, il n’existe pas
de fonction inverse qui puisse retourner le caractère d’origine.
De plus, certaines transformations peuvent rompre la correspondance unà-un séquentielle entre les éléments respectifs des deux chaînes : par exemple,
le remplacement de deux glyphes « f » et « i » par une ligature « fi » diminue la
longueur de la chaîne de glyphes.
La solution unanimement adoptée par les systèmes de formatage compatibles avec les formats de fonte intelligents consiste à créer un graphe de
correspondances entre caractères d’entrée et glyphes de sortie. Ce graphe G,
maintenu par le logiciel de formatage (application ou bibliothèque système),
permet de retrouver le (ou les) caractère(s) correspondant à chaque glyphe et
vice versa. Il faut donc étendre le modèle de texte caractère-glyphe par ce
troisième élément : le graphe de correspondances, un graphe biparti dont les
nœuds correspondent aux caractères d’une part, et aux glyphes d’autre part.
Une arête est présente entre un nœud de caractère et un nœud de glyphe
lorsque ce dernier « correspond au » (« représente » ou « fait partie de la représentation du ») premier :
Soit c1 c2 ...cn la chaîne de caractères et g1 g2 ...gm la chaîne de glyphes,
alors G = (V, E); V = {c1 , c2 , ..., cn } ∪ {g1 , g2 , ..., gm } (tel que ci 6= gj );
E = {(ci , gj ) | gj « correspond à » ci }
Nous avons déjà mentionné dans cette section qu’une des fonctionnalités
majeures qui distingue les fontes intelligentes de leurs ancêtres plus simples
83
Correspondances
entre caractères
d’entrée et glyphes
de sortie
Le graphe
de correspondances
est « la possibilité de définir des manipulations sur les glyphes qui prennent
Graphe en compte le contexte du glyphe en question ». Il s’agit ici, entre autres,
de correspondance de transformations dites contextuelles (dans le jargon des développeurs) qui
et fontes intelligentes peuvent remplacer une sous-chaîne de glyphes de longueur arbitraire par une
autre chaîne de longueur potentiellement différente, possiblement en fonction d’autres glyphes qui précèdent et qui suivent la sous-chaîne d’origine.
Ceci signifie que des correspondances multiple-à-multiple deviennent possibles entre les caractères de départ et les glyphes d’arrivée, et que le maintien du graphe de correspondances devient essentiel. La complexité de cette
tâche dépend largement des types d’opérations permises par les fontes intelligentes (réordonnancement, substitution contextuelle, insertion, suppression,
etc.) ; par conséquent, la simplification des transformations possibles a été un
enjeu très important lors de la conception des différentes formats de fonte
intelligents.
1.9.2 P ROPRIÉTÉS DANS LES DIFFÉRENTS FORMATS DE
ET PLATES - FORMES DE COMPOSITION
FONTE
Dans la suite, nous allons examiner les trois formats de fonte intelligents
les plus avancés : AAT (développé par Apple), OpenType (Microsoft/Adobe)
et Graphite (par SIL International, organisme à but non lucratif). Chacun des
formats possède au niveau du système d’exploitation son propre système de
bibliothèques de support, qui comprend les moteurs de composition et de
mise en page, du support Unicode, etc. Les bibliothèques correspondantes
sont : ATSUI pour AAT, Uniscribe et OTLS pour OpenType ; au format Graphite correspond un système au même nom. D’autre part, nous allons également analyser l’approche du système m17n (multilingualization) qui n’a pas
de format de fonte associé mais qui remplit le même rôle que les trois autres
systèmes.
Comme nous l’avons annoncé au début de la section, notre présentation
de ces formats et systèmes ne sera guère exhaustive ; nous devrons supposer de
la part du lecteur une connaissance préalable de leurs principes de base afin
d’éviter ici une présentation détaillée qui nous détournerait du sujet principal
qui reste la modélisation de texte.
AAT
ET
OPENT YPE
Ces deux formats propriétaires ont certains points en commun regardant
leur fonctionnement et l’interface de contrôle qu’ils fournissent aux applications, le but étant de réduire d’une part la gamme d’opérations que la fonte est
capable d’effectuer sur le texte, d’autre part le contrôle que le client (l’application et/ou l’utilisateur) peut exercer sur le processus de composition (voir à cet
égard [14]). Typiquement, l’interface fournie par le système à l’application est
restreinte à un ensemble de fonctionnalités qui peuvent être activées ou désactivées. Une fonctionnalité représente un ensemble de transformations définies
au sein de la fonte (composition de ligatures, énumération de variantes de
glyphes, calcul des positions de marques, etc.). Les fonctionnalités sont triées
par système d’écriture, puis par langue.
84
FIG. 1.7 – La table de correspondances entre caractères et glyphes retournée
par Uniscribe (en bas). Le nombre dans la k-ième case indique la position du
premier glyphe correspondant au k-ième caractère.
Le texte d’entrée pris en charge par le moteur de composition (ATSUI
ou Uniscribe) est bien évidemment une chaîne de caractères Unicode avec
des propriétés associées. En supposant que la chaîne a déjà été découpée en
sous-chaînes qui utilisent une fonte unique (ceci est un pré-requis à la charge
de l’application), les propriétés envoyées au moteur de composition sont la
langue et l’état des fonctionnalités (activée/désactivée). Le système d’écriture
n’est pas une propriété à part car elle est une propriété du caractère Unicodemême qui se dérive à partir du code de caractère à l’aide de la BD d’Unicode.
Dans un premier temps, à l’aide de la table de correspondance cmap de la
fonte AAT ou OpenType, une chaîne de glyphes initiale est calculée à partir de
la chaîne de caractères d’entrée. cmap réalise des correspondances un-à-un et
ne change pas l’ordre des glyphes par rapport à l’ordre des caractères. Ensuite,
la chaîne de glyphes peut subir davantage de transformations (substitutions mà-n dans le cas des deux formats, réordonnancement, insertion et suppression
dans le cas d’AAT uniquement). Ces transformations nécessitent que le système de composition maintienne à jour le graphe de correspondances entre
caractères et glyphes. Le graphe est retourné dans la forme d’un simple tableau
qui indique pour chaque caractère le ou les glyphes qui en ont résulté (voir
figure 1.7 pour un exemple). En plus du graphe, une liste de propriétés visuelles (métriques, positions, classe de justification, diacritique ou non, etc.),
parallèle à la chaîne de glyphes, est retournée.
GRAPHITE
Graphite n’étant pas un système propriétaire, ses concepteurs n’ont pas eu
à s’inquiéter d’éventuels problèmes de maintenance et de support ; ils ont pu
donc créer un format de fonte et un système de composition qui offre plus
de souplesse et de personnalisation potentielles aux développeurs de fontes et
d’applications. Le résultat en est un format de fonte qui est capable de tout ce
dont OpenType et AAT sont capables et de bien plus. Premièrement, Graphite Graphite est équipé
introduit le concept d’attribut de case (slot attribute)40 qui se distinguent des de propriétés :
attributs de glyphe par le fait qu’ils s’associent à une position dans la chaîne les attributs de case
40
Dans le jargon de Graphite, attribut et synonyme de ce que nous appelons propriété.
85
plutôt qu’à un identifiant de glyphe. Remarquons que notre définition de la
propriété dans la section précédente est identique à celle de l’attribut de case
alors que les attributs de glyphe41 sont des propriétés invariantes.
La propriété intégrée
La nouveauté n’est pas dans le fait d’utiliser de tels attributs — ils sont
dans le modèle incontournables et bien évidemment utilisés dans tout système de traitement
textuel — mais plutôt dans l’intégration de la case (slot) en tant que conteneur
générique dans le modèle de texte. Dans le cas d’AAT et d’OpenType, les
attributs textuels (d’entrée et de sortie) sont contrôlés en interne par le moteur
de composition : les transformations définies dans la fonte n’ont aucun moyen
de prendre en compte les attributs associés aux glyphes, et l’application cliente
n’envoie au moteur et n’en récupère que les attributs que celui-ci reconnaît en
tant que tels. En revanche, le langage de description de Graphite (GDL) — qui
décrit la fonte Graphite entière — met à disposition de l’auteur de la fonte
16 attributs de case typés dont la sémantique est à choisir par l’auteur et qui
peuvent être utilisés librement dans les transformations de glyphes (décrites
par le même langage GDL), tout comme les attributs de case pré-définis et
les attributs de glyphe. Tous les types d’attributs font donc partie intégrante du
modèle de texte de Graphite. Par exemple, la règle de transformation Graphite
gA { kern.x = 10 } / gB
remplace le glyphe gA par le glyphe gB seulement si l’attribut de crénage
horizontal du premier est égal à 10. Cet exemple montre aussi que la valeur
d’un attribut Graphite peut être une liste de sous-attributs, en d’autres termes,
un arbre de couples clé-valeur.
Malgré le fait que la gestion évoluée et bien intégrée de propriétés rend le
modèle de texte de Graphite puissant et flexible, il semble que sa puissance
Les pseudo-glyphes n’est pas toujours bien exploitée. Notamment, les règles de transformation de
dans Graphite, AAT Graphite font souvent recours à des pseudo-glyphes qui sont des éléments
et OpenType textuels temporaires dont le seul rôle est de modifier le comportement des
règles. De tels pseudo-glyphes sont les glyphes marqueurs de début et de
fin de chaîne, le glyphe de saut de ligne, le glyphe ZWJ (liant sans chasse),
etc. L’information que portent ces pseudo-glyphes pourrait cependant être représentée plus naturellement à l’aide de propriétés : le premier glyphe de la
chaîne pourrait avoir une propriété first=true, le glyphe à coller au glyphe
précédent aurait la propriété join_to_left=true, et ainsi de suite. Le même
principe de pseudo-glyphes est également employé par AAT et par OpenType,
ce qui est plus justifiable car leur modèle de texte ne gère pas les propriétés.
Le GDL et le concept d’attributs sont présentés en détail dans le document
[35].
LA
BIBLIOTHÈQUE
« M17N » ET
LE
« M-TEXT »
m17n [40] n’est pas un format de fonte mais un ensemble de bibliothèques
qui offrent diverses fonctionnalités de traitement textuel multilingue. C’est
le plus récent parmi les systèmes présentés, son développement ayant commencé autour de 2002. En plus d’un moteur de composition (qui est au mo41
Dans le modèle de texte de Graphite, les glyphes héritent des attributs des caractères Unicode qui sont à leur origine.
86
ment de la rédaction en cours d’intégration avec la bibliothèque Pango, alternative d’Uniscribe dans le domaine libre), m17n intègre une base de connaissances qui elle-même comprend :
– des méthodes d’entrée (input methods) ;
– les données de la BD d’Unicode ;
– des Font Layout Table qui décrivent, similairement au GDL de Graphite,
de manière formelle les transformations nécessaires pour la composition
de texte multilingue, la différence avec celui-ci et avec les formats AAT
et OpenType étant que ces tables — qui recueillent les transformations
propres aux écritures et aux langues qui ne sont pas dépendantes de
la fonte — sont centralisées dans la base de données de m17n au lieu
d’être intégrées dans chaque fonte ;
– etc.
Nous considérons que le plus grand intérêt de m17n est son modèle de M-text
texte qui a son propre nom : M-text. Le M-text n’est autre que le couple
(TC , Φ(TC )) d’une chaîne de caractères Unicode et d’un nombre arbitraire de
text properties, propriétés de texte associées (où le sens du terme « propriété de
texte » est conforme à notre définition ci-dessus). Comme dans GDL, les propriétés peuvent s’imbriquer et ainsi créer des arbres. Par contre, la nouveauté
du M-text est le fait que l’ensemble des propriétés utilisables n’est pas prédéfini, toute application et utilisateur pouvant en inventer et en rattacher au
texte. La propriété fait donc partie intégrante du modèle de texte, son cycle de
vie n’est pas restreint au processus de composition. Ainsi il devient possible de
communiquer avec le processus de traitement (que ce soit de la composition
typographique, du traitement linguistique ou autre) à travers les propriétés.
Il devient également possible d’ajouter de l’information au texte à un niveau
représentationnel jusqu’ici inexistant : la propriété se situe au niveau du caractère individuel mais elle est orthogonale avec lui, elle complète le texte sans
pour autant altérer la succession des éléments textuels. En revanche, le M-text
reste toujours du texte en caractères, un modèle indépendant de celui du texte
en glyphes que m17n considère comme un cul-de-sac représentationnel qui
ne peut être réutilisé pour un objectif autre que la visualisation du texte.
1.9.3 CONCLUSION
Ayant retracé la chronologie de conception des différents formats de fonte
intelligents et systèmes de composition, on a pu observer que la notion de
propriété a gagné de l’importance dans les systèmes développés plus récemment (Graphite, m17n) par rapport aux systèmes plus anciens (OpenType+Uniscribe, AAT+ATSUI). La nouveauté n’est pas d’attacher des propriétés de présentation aux caractères ou aux glyphes du texte en soi mais plutôt
de considérer les propriétés comme un ensemble ouvert et extensible qui s’intègre dans le modèle de texte de manière qu’il puisse intervenir dans les différentes étapes de la composition de texte. Ceci a un double intérêt : d’une
part, le modèle devient plus clair car les solutions « bricolées » — comme les
pseudo-glyphes qui dans la forme d’éléments textuels représentent des informations qui ne le sont pas réellement — ne sont plus nécessaires. Mais ce qui
est plus important, l’idée de m17n de rendre la propriété partie intégrante du
87
texte, en général et non seulement pour la durée de la composition, est un pas
de géant vers une approche intensionnelle à la représentation de données textuelles, et plus généralement, vers l’adoption d’idées et de méthodes jusque-là
propres aux systèmes fondés sur la représentation des connaissances. m17n
n’étend cependant pas la même approche vers le modèle de texte visuel, la
chaîne de glyphes. C’est tout d’abord cette dernière étape de généralisation,
en unifiant dans un premier temps les propriétés de caractère et de glyphe, et
puis le caractère et le glyphe tout court, qui distingue le modèle de texte que
nous allons bientôt introduire du modèle M-text.
1.10
SYNTHÈSE : L’ÉVOLUTION DE LA MODÉLISATION
DU TEXTE INFORMATIQUE
Ce chapitre a servi à examiner le développement de la représentation du
texte par ordinateur, depuis son début jusqu’à nos jours. Parmi les multiples facettes de la problématique, nous nous sommes principalement intéressés aux
modèles de texte par lesquels nous avons cherché à comprendre les structures
de données et les opérations de base effectuées sur ces structures.
Ce qui n’a pas changé depuis les premiers ordinateurs est la représentation du texte par une chaîne d’éléments textuels, caractères dans la grande
majorité des cas sauf dans les modèles visuels où l’élément de base est le
glyphe. Les caractères et glyphes disponibles sont tirés d’un répertoire — le
codage de caractères ou la fonte — ce qui relève en essence d’une approche
extensionnelle, par le principe énumératif.
D’autre part, les usages et les besoins du texte numérique ont subi une
évolution considérable, notamment grâce aux documents interactifs et au
Web. Ces nouveaux usages se traduisent par le besoin technologique de faire
converger les représentations d’échange et finale d’un même document, besoin que les modèles de texte actuels — basés sur la dichotomie caractèreglyphe — ne sont pas toujours capables d’assurer.
Entretemps, l’« internationalisation » de l’informatique a rendu nécessaire
une extension drastique de l’ensemble des éléments textuels disponibles, aussi
bien au niveau des caractères qu’au niveau des glyphes, avec comme résultat l’apparition du codage Unicode et des fontes intelligentes. Dès lors, une
application voulant afficher ou simplement traiter du texte a eu besoin d’incomparablement plus de connaissances spécialisées, un phénomène qui a mis
en évidence les faiblesses des modèles de texte extensionnels. D’où l’intérêt
de la base de données d’Unicode qui étend le répertoire de signes par des
descriptions intensionnelles, et des fontes intelligentes qui permettent d’ajouter aux caractères et aux glyphes, en tant que ressources, des « règles d’usage » :
des méthodes, des rôles, des relations, des contextes. En un mot, il est de plus
en plus question de représenter et de gérer non seulement de simples données mais aussi des connaissances liées à ces données, ce qui suppose une
approche descriptive plus articulée. Si les termes précédents font allusion à
la modélisation objet, aux logiques de description, aux ontologies, aux bases
de données, etc., c’est parce que les problèmes que nous venons de citer et
que nous tentons de résoudre dans le cadre de la modélisation de texte n’y
88
sont pas toujours particuliers : ils sont souvent généralisables à des problèmes
classiques de la représentation des connaissances.
La nouveauté apportée par la présente thèse — que nous allons présenter dans le chapitre suivant — est justement de proposer un point de vue qui
s’inspire des systèmes de représentation des connaissances par l’application
de certains de ses aspects à la modélisation de texte. Il s’agit d’une réinterprétation drastique du texte informatique : désormais, un élément textuel ne
sera représenté par un indice de tableau mais par l’ensemble de propriétés
le décrivant, ce qui relève d’une approche intensionnelle, autrement dit, de
la préférence d’une approche analytique plutôt qu’énumérative. Tout comme
dans le M-text fourni par la bibliothèque m17n, notre approche intégrera la
propriété au cœur du modèle textuel, sauf que le caractère tel que l’on le
connaît aujourd’hui cessera d’en être l’élément de base. En effet, il ne sera
plus nécessaire de distinguer entre caractère et glyphe et de gérer ainsi deux
modèles de texte distincts en parallèle : le caractère et le glyphe seront supplantés par le concept plus général de textème.
89
90
CHAPITRE 2
PROPOSITION D’UN
CADRE
DE MODÉLISATION DE TEXTE INTENSIONNEL
2.1 INTRODUCTION
Le chapitre précédent a présenté l’évolution de la représentation numérique de texte jusqu’au codage de caractères Unicode et aux formats de fonte
intelligents. Unicode et le format OpenType sont à la pointe de la technologie
actuelle, en train d’en devenir des constituants incontournables. Nous avons
cependant réussi à identifier certaines limitations de ces technologies, limitations dont la raison se trouve dans les approches théoriques des modèles de
texte sur lesquels elles reposent.
D’autre part, nous avons pu voir que même ces technologies — si fortement influencées soient-elles par des considérations pragmatiques d’implémentation et même commerciales — finissent par épouser certaines approches
théoriques inspirées de la problématique de la représentation des connaissances, certes dans une forme embryonnaire. Ce phénomène est inévitable
vue la croissance drastique de la gamme d’éléments textuels à traiter (contenues dans les tables de codage et dans les fontes) couplée avec la diversification et la complexification des méthodes de traitement exigées par le nouveau
modèle de texte qui se veut universel.
Dans l’idée de poursuivre cette convergence interdisciplinaire, et désormais de manière consciente, nous proposons de concevoir un nouveau cadre
de modélisation de texte fondé sur une approche descriptive intensionnelle.
Celle-ci consiste à décrire l’élément textuel à travers un nombre de propriétés.
En fonction de la diversité des propriétés, la description d’un signe peut être
plus vague ou plus précise, suivant les besoins et les usages. Si nécessaire, la
description peut se concentrer sur une facette particulière du signe : propriétés
linguistiques, présentationnelles, etc. Le code numérique n’est plus le moyen
unique d’identifier un caractère : suivant l’approche intensionnelle, l’identité
et donc l’identification de celui-ci consistent en l’ensemble de propriétés permettant de le distinguer des autres signes d’écriture.
L’idée de considérer l’unité textuelle comme un ensemble de propriétés
présente un intérêt particulier : il permet d’unifier les concepts de caractère
et de glyphe, une démarche qui représente une simplification considérable
dans la modélisation de texte, aussi bien en théorie qu’en pratique. Depuis
l’existence d’Unicode et de son modèle de texte, on ne cesse de justifier l’importance de différencier au niveau conceptuel les caractères et les glyphes.
En effet, pour comprendre le fonctionnement d’Unicode et des nouveaux formats de fonte, une distinction claire entre les deux concepts est essentielle.
91
Dans les modèles que nous proposons, en revanche, aucune telle distinction
n’est nécessaire car le caractère et le glyphe sont tout simplement deux facettes (deux sous-ensembles de propriétés) de la même unité textuelle. Le résultat de cette généralisation sera une nouvelle unité textuelle, le textème, qui
peut parfois être équivalent à un caractère, parfois à un glyphe, parfois aux
deux en même temps et parfois à aucun des deux. Alors que les technologies
d’aujourd’hui — Unicode, les fontes intelligentes, les logiciels PAO les plus
avancés — se contentent de perfectionner une reproduction fidèle de la subtilité de la communication écrite d’avant l’ère informatique, les modèles de
texte basés sur les textèmes que nous proposons pourraient permettre de passer au-delà de l’existant et de créer des formes de communication textuelles
novatrices. D’un point de vue pratique, l’abandon de la double représentation textuelle — chaîne de caractères pour le contenu, chaîne de glyphes pour
la présentation — en faveur d’une simple chaîne de textèmes permet d’éviter
de nombreuses difficultés liées au passage d’un modèle à l’autre dont les effets néfastes sur l’interaction homme-machine sont omniprésents aujourd’hui,
comme par exemple l’incapacité de rechercher ou d’indexer certains types de
documents.
Nous allons débuter ce chapitre, avant même de mettre en place les fondements de notre cadre de modélisation, par le survol de deux travaux essentiels pour la compréhension de ce qui suivra, ouvrages qui ont directement
inspiré notre travail. Il s’agit d’une part, de l’œuvre de Gottlob Frege sur la
problématique de nommage, avec lequel l’auteur s’est familiarisé à travers les
textes Sens et dénotation et Concept et objet [24]. D’autre part, nous présenterons quelques éléments de la thèse de V-H. Zaldivar-Carrillo écrite en 1995
à l’ENST Bretagne [71] sous la direction de Ioannis Kanellos, s’inspirant et se
basant sur la thèse de ce dernier [39]. La thèse de Zaldivar s’intéresse principalement au problème de la catégorisation dans le domaine de la représentation
des connaissances. Son cadre méthodologique et le formalisme qu’elle introduit se montrent particulièrement bien adaptés à notre problème.
Les fondements épistémologiques de notre travail se trouvent donc dans le
cadre de la représentation des connaissances. Nous nous laisserons inspirer de
certaines idées fondamentales de ce problème scientifique, sans pour autant
chercher à nous restreindre à un courant théorique ou à un outil particulier
parmi les approches extrêmement diverses qu’englobe ce domaine vaste. En
même temps, nous ne considérons pas que l’acte de modélisation de texte soit
un cas « classique » de la représentation des connaissances, dans le sens où le
focus n’est pas sur la mise en œuvre d’une description fine d’un phénomène
bien circonscrit du monde réel, mais plutôt sur la création d’un cadre général
et souple de manipulation de texte : général parce qu’il se prête à tous les
usages et pratiques textuels connus, et souple parce que nous devrons toujours
exiger une certaine simplicité conceptuelle du texte, qui reste, malgré tout, un
des outils fondamentaux de l’humanité.
92
2.1.1 L ES
NOTIONS DE CONCEPT, DE PROPRIÉTÉ, D ’ EXTENSION
ET D ’ INTENSION SELON F REGE ET RUSSELL
L’objectif de tout système de représentation des connaissances est de décrire, de conceptualiser un fragment du monde réel. Sans avoir la prétention
d’aborder dans ce travail les questions fondamentales de la cognition humaine, nous signalons que selon de nombreux philosophes, la perception et
la compréhension que possède du monde un être humain se construisent également autour de concepts et non en rapport direct avec objets réels. L’idée de
définir l’objet non pas en tant qu’entité en soi mais à travers un ensemble de
concepts qui y sont liés est, en fait, la véritable source de la dualité qui existe
entre les approches descriptives extensionnelle et intensionnelle. Puisque c’est
cette dualité qui nous a inspiré de nombreuses réflexions sur la modélisation
textuelle, il nous sera peut-être intéressant de nous attarder, très brièvement,
sur le sujet de la relation entre concept et objet.
Selon Frege, un signifiant ou nom propre (mot, signe, combinaison de
signes, expression) peut en même temps désigner une dénotation et posséder
un sens. La dénotation du nom est un objet précis, alors que le sens peut être
considéré comme un ensemble de concepts sous lesquels tombe cet objet
[24, Sens et dénotation]. Ainsi, « le bureau de l’auteur à l’ENST Bretagne » est
un nom qui dénote l’objet physique concret. Le sens de ce nom à son tour
comprend de nombreux éléments, entre lesquels on trouve sans doute les
concepts de « table », de « meuble », etc. La caractérisation des concepts (comment peut-on décrire, par exemple, le concept de table ?) était et est toujours
un problème majeur de la catégorisation au sein du domaine de la représentation des connaissances. Selon Frege, un concept lié à un objet peut être considéré comme une propriété de celui-ci (dans ce sens, les termes concept et
propriété sont synonymes). Certains concepts peuvent ne pas être atomiques :
par exemple, le concept de « table basse » est caractérisé par les deux concepts
« être table » et « être basse ». Tous ces trois concepts sont en même temps propriétés de l’objet réel qui est la dénotation de « table basse » [24, p. 137].
Deux autres notions que nous avons déjà employées dans cette thèse mais
que nous n’avons définies qu’approximativement sont celles d’intension et
d’extension. Dans le cadre de la pensée de Frege, l’extension d’un concept est
l’ensemble d’objets dont le sens comprend ce concept. Inversement, l’intension d’un objet est l’ensemble de concepts qui le décrivent. (Voir figure 2.1.)
Appliquons maintenant les idées de Frege aux éléments du texte informatique. En admettant, pour l’instant, que caractère ou glyphe soient des
concepts, l’extension du concept caractère Unicode n’est autre que la liste
des caractères Unicode. Respectivement, l’extension du concept glyphe de la
fonte F est l’ensemble de glyphes contenus dans la fonte F. Dans ce contexte,
le code de caractère joue le rôle du signifiant. « U+0041 » est un signifiant,
un nom propre dont la dénotation est un élément précis de la table de codage
(notamment, la case qui correspond à la lettre A majuscule) et dont le sens est
composé de concepts (autrement dit, de propriétés) tels que « être caractère »,
« être lettre latine », « être majuscule », « être la première lettre de l’alphabet
français », et ainsi de suite.
Si la relation entre les concepts que nous venons d’énumérer ne semble
93
Les sens et dénotation
de Frege
Intension et extension
Le sens et la dénotation
d’un caractère
FIG. 2.1 – L’extension du concept c2 , EXT (c2 ), est l’ensemble d’objets
{o1 , o2 , o3 , o4 } ; en d’autres termes, ces quatres objets tombent sous le concept
c2 . Inversement, l’intension de l’objet o2 , INT (o2 ), est l’ensemble de concepts
{c1 , c2 } ; en d’autres termes, c1 et c2 décrivent l’objet o2 .
pas claire (quels sont les concepts qui caractérisent le concept « être caractère » ? quels sont les concepts pertinents pour Unicode ?), ce n’est pas par
hasard. C’est justement cet aspect ambigu et sous-défini que nous avons reproché à la norme Unicode en section 1.8, tout en saluant la base de données
d’Unicode comme la forme embryonnaire d’une approche plus rigoureuse.
En effet, le sens d’un caractère donné est décrit par un ensemble de propriétés
dans la BD d’Unicode. Malheureusement, les propriétés associées dans la BD
à tel ou tel caractère sont en général choisies de manière ad hoc dans l’objectif
de servir quelques usages bien précis (par exemple, coupure de lignes, classes
combinantes, etc.). Ceci est la conséquence du fait qu’Unicode est construit,
comme nous avons déjà démontré dans le chapitre précédent, suivant une
approche extensionnelle — c’est-à-dire par l’énumération de l’extension du
concept « être caractère Unicode » — au lieu d’une approche intensionnelle
qui consisterait à définir les propriétés qui caractérisent ce concept et qui de
cette façon permettrait de mieux décrire le sens de chacun des caractères.
Désaccord entre Russell
La vision de Frege n’est pas la seule possible. Bertrand Russell, son contemet Frege porain, rejette l’idée que le nom propre ait la double fonction de véhiculer à
la fois le sens et la dénotation. Selon lui, tout nom propre est en quelque
sorte l’abréviation d’une description définitoire de l’objet en question. La dénotation de Frege en tant que « référence directe » vers l’objet n’existe pas car
toute connaissance est forcément descriptive1 . Ainsi, pour Russell, le code de
caractère U+0041 serait une simple abréviation d’une description définitoire
telle que LETTRE LATINE MAJUSCULE A qui constitue le sens en étant une forme
indirecte de l’expression logique « il existe un x tel que x est lettre, x est latin,
x est majuscule et x est A ».
1
Selon Russell, les seuls noms ayant de véritables dénotations dans le sens de Frege sont les
pronoms démonstratifs tels que « ceci » ou « cela ».
94
2.1.2 M ODÈLES COGNITIFS BASÉS SUR LA NOTION DE « THÉORIE »
La recherche scientifique concernant certains actes cognitifs comme la catégorisation nécessite la prise en compte et une description plus fine des relations que les concepts peuvent entretenir entre eux. Au lieu des modèles classiques (tel que la théorie du prototype) qui interprètent le concept en tant que
simple ensemble de propriétés et la catégorie comme l’ensemble de concepts
similaires (partageant un « relativement grand nombre » de propriétés), des
modèles plus sophistiqués ont été élaborés. La thèse de Zaldivar [71], qui s’intéresse principalement à la problématique de la catégorisation, s’inspire d’un
parmi ces modèles, à savoir de celui fondé sur la notion de théorie initialement
proposé par Douglas L. Medin [50].
Le terme théorie est employé ici dans un sens spécial qui ne correspond
pas à son acception standarde en logique, à savoir « un ensemble de formules
fermé par l’implication ». Plutôt, s’inscrivant dans un cadre de sciences cognitives et plus particulièrement de catégorisation, le terme connote « un ensemble complexe de relations entre concepts » [50] qui représenteraient des
connaissances a priori auxquelles on fait recours lorsque l’on établit des catégories. L’idée de base est que le sens d’un concept n’est pas intrinsèque et
ne peut pas être décrit, par exemple, en tant qu’une liste de propriétés qui le
caractérisent. Au contraire, le sens d’un concept se trouve dans ses relations
avec d’autres concepts, et le rôle des théories est justement de formuler ces
relations.
La thèse de Zaldivar [71] propose une formalisation mathématique rigoureuse de la notion de théorie. En prenant celle-ci comme brique de base, elle
construit un cadre formel de représentation des connaissances qu’elle exploite
ensuite dans l’objectif de proposer de nouvelles approches à la catégorisation.
Si dans la présente thèse nous empruntons, en partie, le formalisme de Zaldivar, c’est avant tout pour l’employer comme cadre épistémologique à la modélisation de texte. Le cadre — ou méthodologie — proposé par Zaldivar nous
fournit un outil générique et puissante de représentation des connaissances,
au sein duquel nous pouvons représenter nos modèles de texte d’une manière
abstraite. L’intérêt d’une telle démarche est la « prise de recul » qu’elle permet
par rapport à nos problèmes concrets de modélisation de texte, en révélant
les points communs entre ceux-ci et des problèmes plus généraux déjà longuement étudiés dans un contexte plus général de représentation des connaissances. Un autre point intéressant du système formel proposé par Kanellos et
Zaldivar est, comme nous allons voir, qu’il représente les notions d’extension
et d’intension avec une clarté et une intuitivité particulières.
Nous insistons donc sur le fait que notre adoption de la méthodologie de
Zaldivar n’entraîne aucunement de notre part l’adoption du point de vue de
Medin sur la cognition. Nous adoptons un cadre formel de représentation des
connaissances générique qui, par ailleurs, aurait pu être inspiré par les travaux
de celui-ci. Pour cette même raison, nous cesserons d’utiliser le terme « théorie » que nous remplacerons désormais par le mot « relation », tout simplement
parce que la théorie se définit dans l’édifice proposé par Zaldivar comme une
relation mathématique.
Dans les grandes lignes, Zaldivar et Kanellos proposent une approche à la
95
La « théorie »
Sens ≈ relations entre
concepts ≈ théories
Un cadre formel de RC
basé sur la notion
de « théorie »
Théorie 7→ relation
représentation des connaissances dont l’idée fondamentale est l’organisation
de l’information en strates, chaque strate étant un ensemble. Les éléments de
la strate inférieure (la « zéroième » strate) correspondent aux objets du monde
que l’on perçoit, ou plus précisément, au segment du monde que nous visons
à décrire. Et justement, le rôle des strates supérieures est de décrire les objets
avec de plus en plus de précision, en les organisant en un réseau de relations.
Ainsi, la première strate comprend des relations sur les éléments de la zéroième strate (celle des objets). Un simple ensemble uniforme de relations ne
possède cependant pas l’expressivité et la puissance nécessaires pour décrire
certains aspects plus complexes de la réalité. Ceci explique le besoin d’introduire des strates supérieures qui fournissent des « données sur les données »
(méta-données), qui formulent des connaissances sur les données brutes.
L’univers de base
La strate inférieure, appelée l’ensemble des objets, contient des entités
qui sont d’une certaine manière liées au monde que l’on perçoit, ou plus
précisément, au segment du monde que nous visons à décrire. À part cette
délimitation vague, nous ne possédons a priori aucune information sur ces
entités, la description de leur sens étant justement l’objectif de la structure
que nous sommes en train de construire. La connaissance des éléments de
l’ensemble-base d’objets n’est pas une condition nécessaire pour l’efficacité
du système en construction, même si sa délimitation plus ou moins précise,
comme nous allons voir, peut ensuite rendre les modèles qui en découlent
plus ou moins puissants.
Plus précisément, l’ensemble de base, que Zaldivar appelle T0 , contiendra,
en plus des objets qui nous intéressent, les produits cartésiens de ces objets :
si O est l’ensemble d’objets, alors
Les strates
T0 =
n
[
Oi
i=1
où le nombre n est une valeur finie (car nous visons à décrire un fragment fini
du monde) bien qu’a priori non définie (car nous n’imposons pas de borne
fixé quant à la taille de ce fragment).
Les relations
Les strates supérieures à T0 contiennent des relations dont le rôle est de
décrire les objets se trouvant dans T0 mais aussi les relations des strates inférieures. Une telle relation représente un bout d’information qui exprime,
de manière formelle, quelque chose à propos d’un autre bout d’information.
Ainsi, les relations contenues dans la strate directement supérieure à T0 , appelée T1 , formulent des assertions sur les objets « bruts » éléments de T0 . En général, une relation d’une strate donnée s’exprime sur les éléments de la strate
directement inférieure (ou parfois des deux strates directement inférieures).
Formellement,
T1 = {t | t est une relation i-aire sur O, 1 ≤ i ≤ n}
Les relations de T1 représentent des données de base exprimées sur les objets
bruts, éléments de T0 , soit individuellement (à travers des relations unaires)
soit les uns par rapport aux autres (relations i-aires). Remarquons que cette
définition de T1 restreint la portée de toute relation t à une partition Oi précise
de T0 . Dans la suite, nous appellerons les relations unaires — qui expriment
donc des connaissances sur des objets individuels — propriétés.
96
FIG. 2.2 – Les relations servent à décrire les objets. Dans cet exemple, la
relation t2 représente une propriété de l’objet o2 alors que t3 est une autre
propriété à la fois de o2 et de o3 . Les relations t4 et t6 sont extensionnellement égales car ext(t4 ) = ext(t6 ). On peut les considérer comme deux
« synonymes » pour ce qui est essentiellement la même affirmation. L’intension restreinte de l’objet o2 est {t2 , t3 }, alors que son intension globale est
{t2 , t3 , t4 , t6 }.
L’extension d’une relation et l’intension d’un objet se définissent de ma- Extension de relation,
nière quasi-analogue au rapport concept-objet défini antérieurement dans intension d’objet
cette section. Ainsi, l’extension ext(t) d’une relation t de T1 est l’ensemble
d’éléments de T0 (éléments individuels ou tuples) qui vérifient la relation t.
Inversement, l’intension (globale2 ) int(o) d’un objet o de T0 (ou, plus généralement, d’un élément quelconque de T0 ) est l’ensemble de relations auxquelles
participe l’objet o.
Une propriété très importante de l’ensemble T1 est son intensionnalité, ce L’intensionnalité de T1
qui permet l’existence de deux (ou plusieurs) relations non identiques ayant la
même extension :
∃ti , tj telles que ti 6≡ tj , ext(ti ) = ext(tj )
L’intensionnalité de T1 est assurée de manière axiomatique [71, p. 56]. Il s’agit
d’une propriété essentielle pour équiper notre système d’une puissance descriptive suffisante, autrement dit, pour le rendre « réalistique » par rapport au
monde que nous souhaitons décrire. Les deux strates T0 et T1 sont, en effet,
déjà capables de générer un modèle riche qui permet d’exprimer de nombreuses relations sémantiques. Ainsi, l’égalité extensionnelle de deux propriétés ou relations dans T1 , ext(ti ) = ext(tj ), exprime un rapport de « synonymie »
entre elles, alors que le fait que ext(ti ) ⊂ ext(tj ) peut exprimer un rapport de
subsomption (ou d’héritage) entre ti et tj . De plus, à travers la définition de
diverses formes d’égalités projectives entre relations d’arités différentes, il devient possible d’exprimer des « ressemblances de famille » [71, p. 113] entre
objets qui dépassent en puissance descriptive la catégorisation classique basée
2
Zaldivar distingue entre l’intension restreinte d’un objet qui ne comprend que ses propriétés et l’intension globale qui contient également les relations (d’arités supérieures) sur l’objet.
97
sur la similitude ou sur l’existence d’un prototype. Puisque ces considérations
sortent du cadre de cette thèse, nous nous contentons de les mentionner sans
donner davantage d’explications.
L’introduction de strates supérieures telles que T2 , T3 , etc., permet d’exprimer des connaissances sur les éléments de T1 (tels que les propriétés), tout
comme ceux-ci ont permis d’exprimer des connaissances sur les objets. Ainsi,
Zaldivar introduit la strate T2 comme suit (les strates supérieures pouvant s’introduire de la même manière) :
T2 = {t | t exprime une relation sur T1 ou sur T0 ∪ T1 }
On peut voir que T2 permet non seulement de décrire les relations de la strate
directement inférieure (T1 ) mais aussi d’exprimer des relations entre celle-ci
et la strate en dessous (T0 ici). Une autre observation importante est que l’intensionnalité (axiomatique) de T1 est héritée par la strate T2 et aussi par toute
strate supérieure éventuelle. Il n’y a pas de limite théorique à l’introduction
de nouvelles strates, il faut cependant que le formalisme que nous sommes en
train de construire « colle » avec les phénomènes du monde réel modélisé3 .
L’utilité du modèle
Le choix de concepts mathématiques de si bas niveau — l’ensemble et la
en strates relation — comme outils fondamentaux confère à notre approche (à part sa
pureté théorique) une grande généralité, ce qui permet de l’appliquer à une
gamme de problèmes très diversifiés, dont la modélisation de texte. D’autre
part, la particularité de cette approche ne se trouve pas dans la description des
objets atomiques à l’aide de relations et de relations de relations, etc. : tout
système de représentation des connaissances devra inévitablement suivre, à
la base, ce même principe. Sa spécificité provient plutôt du découpage en
strates de l’ensemble d’informations afin d’établir un ordre entre les relations,
en leur imposant une transition graduelle depuis le simple vers le complexe.
Cette approche particulière à la stratification a comme effet de rendre plus
intuitif l’établissement de rapports sémantiques entre les éléments abstraits du
système (les relations) et les phénomènes réels du monde. En même temps,
il faut remarquer que la stratification des connaissances en général — d’une
manière ou d’une autre — semble également être une idée incontournable
des systèmes de représentation des connaissances : il suffit de penser à la
catégorisation comme approche fondamentale à la description du monde, à
la relation classe-instance, à la notion d’héritage, aux schémas de description,
etc.
Notation
Finalement, une convention notationnelle reprise à l’identique depuis la
thèse de Zaldivar : lorsque nous écrivons t(i) , l’indice entre parenthèses indique le type de la relation, c’est-à-dire la strate dans laquelle elle se trouve.
3
Ainsi, l’introduction des niveaux T2 et (implicitement) T3 permet à Zaldivar de formaliser
avec son approche des notions complexes comme la contextualité, la métaphore, l’identité
sémantique, et ainsi de suite.
98
2.2 APPLICATION DE LA REPRÉSENTATION
DES CONNAISSANCES À LA MODÉLISATION
TEXTUELLE
Le cadre formel qu’offre le cadre ci-introduit nous permettra de réévaluer
ce que nous entendons par caractère, glyphe ou usage d’un texte : il est temps
de faire dissiper le « brouillard » qui entoure ces notions si mal définies et
pourtant omniprésentes. Il s’agit donc d’appliquer la méthodologie décrite cidessus à la tranche du monde observé que représentent les signes d’écriture.
Dans l’approche présentée dans la section précédente, la strate inférieure,
T0 , consiste en un simple ensemble d’éléments « opaques », correspondant aux
entités du monde que nous visons à décrire. Toutes nos données (informations,
connaissances) sur ce monde s’expriment à travers des relations appartenant
aux strates supérieures, dont le rôle est d’établir un certain ordre parmi les
éléments présents « en vrac » dans cet ensemble potentiellement vague et mal
circonscrit qu’est T0 . Au plus général, nous dirons que celui-ci contient la
totalité des signes de toutes les écritures du monde qui peuvent potentiellement être informatisés, dans toutes leurs formes et dans toutes leurs apparitions. Est-il possible de décrire le contenu de T0 en l’énumérant ? En pratique,
certainement pas : on parle de tous les signes d’écriture, existants ou potentiels, dans toutes leurs formes graphiques, apparus dans tous les ouvrages. De
plus, il ne s’agit aucunement de prendre une « photographie instantanée » de
l’œuvre écrite de l’humanité à un certain point dans le temps mais plutôt de
supposer que cet ensemble T0 grandit constamment. Certains sous-ensembles
bien restreints peuvent cependant en être énumérés au prix d’un effort acceptable, comme par exemple « tous les signes arabes qui apparaissent dans tel
ou tel manuscrit du Coran ». Mais à partir d’un certain ordre de grandeur, on
se heurte forcément à des problèmes de catégorisation, comme dans le cas de
l’effort entrepris par la norme Unicode d’énumérer ce qui n’est encore qu’une
petite fraction de tous les signes d’écriture du monde.
En pratique, la généralité visée par le choix d’un ensemble T0 si vaste devient un obstacle à l’exploitation informatique des modèles que nous tentons
de construire. Dans une logique implémentationnelle, il est intéressant de réduire le contenu de T0 à un ensemble maîtrisable et énumérable (comme par
exemple à une liste de signes dont la taille serait similaire à celle du codage
Unicode, voire même à une page particulière de celui-ci). Nous verrons plus
tard que, comme principe général, plus l’ensemble T0 est restreint, plus nos
modèles se montrent réalisables en pratique4 . Néamnoins, dans un premier
temps, nous tenterons d’adopter une approche généraliste, notre objectif étant
toujours de proposer un modèle de texte global et universel. Une fois un tel
modèle mis en œuvre et évaluée, nous examinerons les éventuelles possibilités de simplification.
Avant de passer à la discussion de la strate T1 , reconsidérons brièvement
les tuples d’objets que nous avons ignorés jusqu’à maintenant, contenus dans
les partitions Oi ⊂ T0 où i est supérieur à 1. Étant donné que O représente
4
Ce qui est d’ailleurs vrai pour tout modèle : plus il vise la généralité, plus il perd la capacité
d’adresser des problèmes particuliers, et vice versa.
99
Le contenu de T0
Universalité
contre intérêt pratique
Tuples d’objets :
chaînes de signes
FIG. 2.3 – Illustration de l’ensemble de signes d’écriture et des propriétés qui
leur sont associées.
l’ensemble de signes d’écriture, on peut considérer, de manière intuitive, l’ensemble Oi comme l’ensemble de chaînes de signes à longueur i. Il s’ensuit
qu’une relation d’arité i qui désigne un sous-ensemble de Oi représente une
propriété associée à des chaînes de signes en tant que telles, au lieu d’être
une propriété d’un signe individuel. Décrire les signes non seulement dans
leur individualité mais également dans leur succession est une capacité remarquable du système que nous serons amenés à exploiter afin de gérer certains aspects plus complexes de l’information textuelle. Notamment, les tuples
d’objets nous seront utiles dans la représentation de propriétés dites contextuelles. Ils sont également à la base d’une généralisation potentielle du cadre
que nous sommes en train d’introduire, que nous présenterons dans le dernier
chapitre de la thèse.
2.2.1 L ES
PROPRIÉTÉS
: ÉLÉMENTS DE T1
Ce sont les strates supérieures à T0 , dans un premier temps l’ensemble
T1 , qui nous permettront d’exprimer des connaissances sur les éléments de
T0 . Si T0 est l’ensemble de signes d’écriture, alors les relations unaires de T1
représentent les propriétés de ces signes :
DÉFINITION 5 (PROPRIÉTÉ )
Une propriété φ est une relation unaire de T1 , c’est-à-dire
φ ∈ T1 : ext(φ) ⊂ O, O ⊂ T0
(Nous écrirons parfois également t(1) ou tvaleur(1) au lieu de φ pour mettre en
évidence qu’il s’agit d’une relation de T1 .)
Les propriétés peuvent être graphiques, sémantiques, linguistiques, et ainsi
de suite : avant d’avoir considéré des strates supérieures (qui décriveront les
propriétés mêmes), nous ne sommes capables de faire aucune distinction entre
elles.
Un signe d’écriture se définit donc à travers ses propriétés, autrement
dit, son intension ; c’est pour cette raison que nous avons appelé dans le
titre du présent chapitre intensionnel le cadre de modélisation de texte que
nous sommes en train de développer. La figure 2.3 illustre les deux premières
100
strates, de manière analogue à la relation objet-concept en figure 2.1. Notons
que, puisque T0 contient aussi bien des objets individuels que leurs tuples, les
relations de T1 peuvent également référer à ces dernières, en d’autres termes,
décrire les rapports entre signes individuels.
La strate T1 nous a permis de décrire nos objets à travers des « données
brutes », en forme de propriétés. Ces données fournies par T1 seul ne sont pas
toujours exploitables : notamment, il peut être en pratique très difficile, voire
impossible, de connaître l’extension d’une propriété donnée (« quels sont tous
les signes qui représentent des voyelles ? »). Pourtant, en disposition d’uniquement les deux strates T0 et T1 , comparer deux propriétés n’est possible
en théorie que par la comparaison de leurs extensions respectives. Ceci n’est
pas généralement réalisable en pratique mais peut être possible lorsque l’on
s’intéresse à un sous-ensemble relativement petit (c’est-à-dire énumérable) de
T0 . Sur un tel sous-ensemble restreint, il devient possible d’analyser les rapports entre propriétés : par exemple, une relation ext(φ1 ) ⊆ ext(φ2 ) entre les
deux propriétés φ1 , φ2 ∈ T1 signifie que φ2 « entraîne » φ1 , ou dans un jargon informatique, elles sont en dépendance. Si par exemple φ1 = « être en
malais » et φ2 = « être une lettre arabe », alors un tel rapport de dépendance
doit forcément exister entre les deux propriétés car la langue malaise s’écrit
officiellement en arabe. Néanmoins, on ne peut pas généraliser une telle observation en sécurité pour tous les textes malais écrits depuis toujours : il vaut
mieux restreindre le sous-ensemble de T0 considéré, par exemple, à la littérature malaise apparue dans le XXe siècle.
2.2.2 L ES
CLÉS DE PROPRIÉTÉ
T1 est décrite à la fois
par son extension
(dans T0 )
et par son intension
(dans T2 )
: ÉLÉMENTS DE T2
Afin de décrire — ou de catégoriser — les propriétés de T1 suivant d’autres
critères que ceux déduisibles à partir de leur extension, il est nécessaire d’introduire une strate supérieure dans le système. Par exemple, il peut être utile
de reconnaître que les propriétés voyelle et consonne en figure 2.3 sont deux
manifestations du même aspect d’un signe : sa sonorité ; tout comme arabe et
latin sont les manifestations de l’aspect système d’écriture. En effet, lorsqu’en
pratique on adopte intuitivement la définition de couple clé-valeur comme
la structure d’une propriété, on applique indirectement le même principe de
catégorisation. Cette catégorisation étant à la fois si naturelle et si pratique, il
est certainement dans notre intérêt de la représenter au sein du système, par
l’intermédiaire d’une strate T2 supérieure.
Ainsi, une relation unaire de T2 représentera une clé de propriété et son extension représentera les propriétés correspondantes au sein de T1 . Par conséquent, le couple clé-valeur se définit ainsi :
DÉFINITION 6 (COUPLE
CLÉ-VALEUR ) Un couple clé-valeur est un couple
(tclé(2) , tvaleur(1) ) où la première est une relation unaire de T2 alors que la
seconde est une relation unaire de T1 telle que tvaleur(1) ∈ ext(tclé(2) ).
À ce point, nous imposons une restriction par rapport à la création de sous- Les valeurs
ensembles de propriétés dans T2 : pour qu’un tel sous-ensemble puisse être d’une propriété doivent
considéré comme clé de propriété, il faut que les relations de T1 (les valeurs) être disjointes
101
FIG. 2.4 – Illustration des strates T2 et T3 .
correspondantes aient des extensions mutuellement disjointes :
∀tclé(2) ∈ T2 , ext(tclé(2) ) = {t1 , t2 , ..., tn } ⊂ T1 :
∀(i, j) tels que 1 ≤ i, j ≤ n et i 6= j, ext(ti ) ∩ ext(tj ) = ∅
Il s’agit donc d’interdire les valeurs de propriétés qui « se chevauchent » ; par
exemple, une propriété « couleur » ne peut avoir comme valeurs « rouge » et
« rougeâtre » s’il peut exister un signe qui peut être caractérisé à la fois par
ces deux couleurs. Nous n’excluons pas la possibilité que ces deux propriétés puissent exister individuellement, nous interdisons tout simplement de les
regrouper sous la même clé de T2 . Bien que cette contrainte puisse paraître
arbitraire, il ne posera aucune difficulté en pratique, et il se prouvera fort utile
dans la suite d’un point de vue implémentationnel.
2.2.3 L ES
CATÉGORIES DE CLÉS
: ÉLÉMENTS DE T3
D’après l’exemple des strates T1 et T2 , il semble évident que de nouvelles
strates peuvent théoriquement être introduites jusqu’à l’infini car il est toujours
possible de créer des catégories de catégories, des relations sur des relations,
et ainsi de suite. Il faut cependant que l’introduction de nouvelles strates nous
présente un intérêt pratique : elle doit nous permettre de formuler des connaissances qualitativement différentes sur les éléments des strates inférieures, et
ces nouvelles connaissances formulées au sein du cadre formel d’une certaine
manière correspondre à nos observations du monde réel.
Propriétés pertinentes
Ce qui justifie dans notre cas de continuer à introduire des strates supépour un usage rieures est le besoin de filtrer entre informations utiles et inutiles ou plus précisément, entre propriétés pertinentes et non pertinentes dans le contexte d’un
usage donné. Car il est évident que les propriétés que l’on peut potentiellement inventer ne sont pas toutes utiles pour tous les usages textuels. Dans le
modèle de texte « caractère-glyphe » que nous avons présenté dans le chapitre
102
précédent à propos d’Unicode et des fontes intelligentes, on observe l’application (implicite) du même principe : lorsqu’un texte est constitué de glyphes,
ce sont les propriétés graphiques des signes qui sont mises en évidence, alors
qu’un texte en caractères offre peu d’informations visuelles et, par exemple,
davantage de propriétés linguistiques.
Par conséquent, une catégorisation des clés de propriété en fonction des
usages textuels semble être d’une grande utilité, et même indispensable étant
donné que nous nous proposons de mettre en œuvre un cadre de modélisation de texte intensionnel, c’est-à-dire construit autour des propriétés. Nous
rappelons cependant que l’objectif de cette thèse n’est pas de proposer une
taxonomie de propriétés à travers des catégories fonctionnelles mais de montrer l’intérêt de faire ainsi et de proposer une méthodologie pour la réaliser.
Nous avons situé les clés de propriété au niveau de la strate T2 . La strate
T3 nouvellement introduite contiendra, entre autres, des catégories fonctionnelles (où par « fonctionnel » on entend tout simplement « basé sur les usages »),
définies comme des sous-ensembles de clés de propriété. Une illustration (largement simplifiée, bien sûr) d’une telle catégorisation est présentée en fig. 2.4.
L’intérêt de cette démarche se justifie lorsque l’on réalise à quel point il Caractère et glyphe :
devient plus facile de répondre à des questions telles que « qu’est-ce qu’un relations de T3
caractère ? » ou « qu’est-ce qui différencie un glyphe d’un caractère ? ». Désormais, il est possible de formuler des réponses plus exactes que celles fournies
par la norme Unicode : on peut considérer le caractère comme étant une catégorie de propriétés « bien choisie », définie dans T3 . Le glyphe, à son tour,
sera considéré comme une catégorie différente. Des propriétés telles que majuscule, chiffre, arrêt glottal, écriture latine feront sans doute partie de la catégorie caractère alors que chasse à 1em, italique, Futura appartiendront à la
catégorie glyphe. Suivant cette approche, caractère et glyphe sont donc des relations unaires de T3 qui correspondent à des ensembles de clés de propriété
bien précis.
Une approche alternative, similaire mais non équivalente, serait de créer La strate T4
une strate T4 de catégories de catégories de clés de propriété qui correspon- est optionnelle
drait aux usages. La raison derrière cette solution plus complexe en apparence
est que les usages pratiques (tels que « transmission de contenu textuel », « document formaté et mis en page ») ne correspondent en général pas exactement
aux catégories fonctionnelles de T3 (telles que « propriétés graphiques », « propriétés linguistiques », « propriétés sémantiques »). Il semble plus réaliste de
supposer que plusieurs catégories peuvent correspondre à un usage, comme
par exemple un document PDF devrait contenir des informations liées à la
fois à la présentation et à la sémantique du texte qu’il contient. Néanmoins,
la séparation des strates T3 et T4 n’est pas essentielle car les propriétés correspondant à un usage donné peuvent très bien être « ramassées » directement
au lieu d’être d’abord catégorisées. Ainsi, T3 peut très bien être considérée
comme la strate des catégories des clés et la strate d’usages en même temps.
Cette approche est illustrée sur la figure 2.5. L’approche à suivre dépendra
sans doute de considérations pratiques.
103
FIG. 2.5 – Un usage peut être considéré comme une catégorie de clé. « Caractère » et « glyphe » sont selon cette interprétation deux usages distincts qui
peuvent néanmoins partager des propriétés communes.
COUPLES
CLÉ-VALEUR EN TANT QU’ÉLÉMENTS DE
T3
Les relations unaires de la strate T3 représentent donc des catégories fonctionnelles de clés. T3 contient cependant également des relations binaires de
forme (t(2) , t(1) ) : des ensembles de couples clé-valeur. Pour un couple clévaleur, nous exigeons bien évidemment que t(1) ∈ ext(t(2) ).
Il ne relève pas d’abus de langage d’appeler ces couples propriétés,
comme on fait très souvent en langage informel, puisqu’il s’agit tout simplement d’un élément de T1 — une propriété proprement dite — couplé avec une
étiquette (la clé) qui est en quelque sorte sa catégorie primaire. Par conséquent
et aussi pour des raisons de simplicité, lorsque nous parlons de l’extension
d’une propriété en tant que couple clé-valeur, ceci désigne l’extension de sa
partie t(1) , ce qui donne un ensemble dans T0 :
DÉFINITION 7 (EXTENSION
D’UN COUPLE CLÉ-VALEUR)
ext (t(2) , t(1) ) := ext t(1) (par définition).
Par la définition suivante, nous introduisons l’extension commune d’un
ensemble de couples clé-valeur, élément de T3 , qui désignera l’extension de
l’intersection de ses éléments, et que nous allons représenter par « extc » :
DÉFINITION 8
(EXTENSION COMMUNE D’UN ENSEMBLE DE COUPLES CLÉ-VALEUR )
Soit t(3) ∈ T3 une relation binaire composée de couples clé-valeur :
t(3) =
n
[
i=1
(t(2)i , t(1)i )
Alors :
extc(t(3) ) = ext (t(2)1 , t(1)1 ) ∩ ext (t(2)2 , t(1)2 ) ∩ ... ∩ ext (t(2)n , t(1)n ) =
= ext(t(1)1 ) ∩ ext(t(1)2 ) ∩ ... ∩ ext(t(1)n )
L’extension commune d’un ensemble de couples clé-valeur sert à obtenir les
signes de l’univers T0 caractérisés par chacune des propriétés de cet ensemble,
comme nous verrons toute de suite dans la section suivante.
104
2.2.4 L E
CARACTÈRE U NICODE , LE GLYPHE ET LE SIGNE
TYPOGRAPHIQUE EN TANT QU ’ ÉLÉMENTS DE T3
LE
CARACTÈRE
UNICODE
Notre proposition de considérer le caractère en tant que relation de T3
n’est pas incompatible avec la norme Unicode. Dans celle-ci, un caractère est
défini (au niveau CCS, Coded Character Set) par :
– son nom (VERTICAL LINE) ;
– son code numérique (U+007C) ;
– sa description informelle (« used in pairs to indicate absolute value ») ;
– ses propriétés dans la BD d’Unicode (« Symbol », « Math », etc.).
Le nom d’un caractère sert comme identifiant unique de celui-ci au niveau
ACS (Abstract Character Set, ensemble de caractères dits abstraits car non codés). Quant au code numérique, il s’agit du nom propre le plus pratique par
lequel le caractère est identifié5 . Il est clair que la définition d’un caractère
Unicode comporte un ensemble de propriétés, même si celles-ci n’ont pas
été choisies suivant une méthodologie bien établie (car les propriétés pertinentes pour Unicode n’ont jamais été définies). Nous pouvons donc affirmer
qu’il est possible de décrire la totalité des caractères Unicode d’une manière
intensionnelle, à l’aide de relations de T2 .
Le caractère en tant que catégorie générale est donc un élément de T3
(ou en d’autres termes un ensemble d’éléments de T2 ). Comment représentet-on dans ce système un caractère précis, par exemple, la LETTRE MAJUSCULE
LATINE A ? Il s’agit d’assigner des valeurs aux clés de propriété pertinentes pour
le caractère, c’est-à-dire d’associer à chaque clé de T2 une de ses propriétés
de T1 . Un couple clé-valeur est un couple (tclé(2) , tvaleur(1) ) tel que tvaleur(1) ∈
ext(tclé(2) ), et le caractère en question se compose de tels couples, il s’agit
donc d’une relation t(3) ∈ T3 . Parmi tous les signes dans T0 (l’univers), ceux
représentés par ce caractère précis sont ceux qui sont décrits par à la fois
toutes les propriétés contenues dans t(3) , en d’autres termes, les éléments de
son extension commune : extc(t(3) ).
LE
GLYPHE
Jusqu’ici nous avons employé le terme glyphe dans le sens d’« image contenue dans une fonte ». Une fonte est cependant bien plus qu’une liste d’images
car elle comprend également un ensemble d’informations relatives à l’affichage de celles-ci. Il s’agit donc encore une fois d’un ensemble de propriétés décrivant l’élément graphique d’écriture, l’image elle-même pouvant être
considérée comme une propriété, complexe certes mais décomposable en une
série de propriétés plus basiques (courbes de Bézier, chacune d’elles à quatre
paramètres numériques).
En revanche, à l’opposé du caractère Unicode, l’identifiant numérique de
glyphe n’est pas un nom propre en soi car il n’est unique qu’au sein de la
même fonte, du moins dans le cas des formats de fonte courants. Pour iden5
Dans la pensée frégéenne, ce code renvoie à la fois vers la dénotation du caractère et vers
son sens, ce dernier étant composé de l’ensemble de ses propriétés. Selon Russell, ce même
code numérique doit plutôt être considéré comme pointeur ou abréviation vers le sens.
105
Le caractère
en tant que catégorie
Le caractère
en tant qu’instance
tifier une image particulière (et ses propriétés), il faut avoir recours au couple
(nom de fonte, ID de glyphe), pourvu que le nom de fonte soit unique (ce qui
devrait être le cas en pratique).
Si l’on compare le caractère et le glyphe selon les données — les propriétés — qui leur sont explicitement associées par la norme Unicode et par les
fontes, resp., on observe que les deux ensembles sont bien distincts. Ceci est
conforme à la vision suggérée par Unicode qui met l’accent sur une distinction formelle entre les deux notions, distinction qui se fait selon les différents
usages textuels : représentations d’échange et finale. En revanche, la raison
pour laquelle cette distinction peut paraître artificielle et non-intuitive aux non
encore initiés à ce modèle « bicaméral » de représentation textuelle est qu’en
réalité il est sous-entendu que le caractère et son glyphe ont le même signifié :
le code du caractère U+0041 LETTRE LATINE MAJUSCULE A dans une case de
la mémoire vive d’un ordinateur et le glyphe sur l’écran qui lui est associé
signifient le même phonème (morphème, concept, etc.). Dans un modèle de
texte que nous pourrions considérer plus intuitif (et que nous espérons être
le cas de nos résultats), le caractère et son glyphe devraient être deux entités qui partagent certaines de leurs propriétés (dans notre exemple, la valeur
phonémique) et diffèrent par d’autres.
LE
SIGNE TYPOGRAPHIQUE
Dans le chapitre précédent (page 34) nous avons déjà parlé des signes typographiques comme étant des unités sémantiques de la typographie, ou d’un
autre point de vue : des classes d’équivalence de glyphes suivant des critères à
prépondérance typographique6 . À leur origine, les noms de glyphe PostScript
(page 38) fonctionnaient comme noms propres de signes typographiques dans
le but d’indiquer l’appartenance d’un glyphe à sa classe d’équivalence, abstraction faite de nombreuses propriétés graphiques (l’image concrète, les dimensions, etc.). Par conséquent, entre l’interprétation intensionnelle du signe
typographique et celle du glyphe il y a donc une relation d’héritage car les
propriétés décrivant le premier forment un sous-ensemble des propriétés du
dernier : ext(tst(3) ) ⊆ ext(tg(3) ). Un glyphe est un signe typographique particulier, ou un signe typographique est une catégorie de glyphes.
La thèse de Gérard Blanchard, intitulée Pour une sémiologie de la typographie [17], énumère et analyse de nombreuses propriétés graphiques qui
décrivent le signe typographique ; mais au lieu de propriété, il emploie, après
Jacques Bertin, le terme « variable ».
2.3
LE TEXTÈME : ÉLÉMENT TEXTUEL GÉNÉRALISÉ
Une des conclusions majeures de la section précédente est qu’il n’existe
pas de différence conceptuelle entre caractère, glyphe et signe typographique
car tous les trois sont des relations de T3 correspondant à trois sous-ensembles
6
Heureusement, même si l’on a un certain mal à formuler une définition précise pour ce
terme, on n’a aucun mal à le comprendre intuitivement grâce aux notions acquises de plusieurs
siècles de typographie traditionnelle.
106
(non identiques) de clés de propriété. En vue de cette réalisation, nous nous
posons la question suivante : existe-t-il une raison théorique de construire un
modèle de texte qui soit basé sur une telle distinction, comme dans le cas
du modèle caractère-glyphe recommandé par la norme Unicode ? N’est-il pas
préférable de chercher un modèle qui puisse intégrer dans la même chaîne
textuelle à la fois l’équivalent du caractère et l’équivalent du glyphe ? Dans le
reste de cette thèse, nous allons répondre à ces questions à travers la constuction et l’analyse d’un tel modèle unifié.
Si nous avons investi un effort considérable dans la construction de l’hiérarchie de strates dans la section précédente, nous sommes maintenant recompensés par la facilité avec laquelle nous pouvons en tirer une importante
conclusion : l’élément textuel de base de notre nouveau modèle de texte doit
être l’équivalent d’un élément de T3 . Plus précisément, l’élément textuel en
tant que catégorie sera une relation simple de T3 (c’est-à-dire un ensemble de
clés de propriété de T2 ) alors que l’élément textuel en tant qu’instance sera
une relation complexe de T3 (c’est-à-dire un ensemble de couples clé-valeur,
de relations binaires entre T2 et T1 ). La catégorie représentée par l’élément de
T3 en question n’est en général équivalente ni à un caractère, ni à un glyphe,
ni à un signe typographique, mais elle peut être équivalente à l’un ou à l’autre
lorsque les clés instanciées coïncident avec celles qui caractérisent ces trois
catégories. En conséquence, il est également possible qu’un tel élément textuel soit à la fois un caractère et un glyphe lorsqu’il possède les propriétés
de ces deux catégories, mais il peut aussi représenter un signe d’une toute
différente nature.
Puisque cet élément textuel est de toute évidence plus général qu’un caractère, un glyphe ou un signe typographique — car il peut décrire un signe
avec une gamme de précision très large —, il semble utile de lui inventer à ce
point une nouvelle appellation. L’auteur et Yannis Haralambous ont proposé
le terme textème car il réfère au composant élémentaire du texte (informatique), par analogie à d’autres termes comme phonème, graphème, sémème,
etc. (pour référer aux composants élémentaires de la parole, de l’écriture ou
du sens respectivement). Il faut noter que le terme textème a déjà un usage alternatif qui antidate le nôtre et dont la signification semble être « morceau de
texte ininterrompu ». Par contre, l’emploi de celui-ci paraît assez peu fréquent,
lié à un contexte sémiologique, et restreint surtout à la littérature germanophone7 .
Le modèle de texte que nous proposons et que nous allons définir peut
donc être décrit, de manière informelle, ainsi : l’élément textuel de base est le
textème, un ensemble de couples clé-valeur, et le texte est une suite unidimensionnelle de textèmes. Ce même modèle sera à la base des représentations
textuelles d’échange, transitionnelle et finale ; il ne sera plus nécessaire de
changer de modèle de texte lorsque l’on passe d’une représentation à l’autre.
Notons qu’il est légèrement réducteur de parler de modèle de texte en
singulier car de nombreux différents modèles, simples et complexes, peuvent
être conçus autour de l’idée de textème. Ceci dit, pour des raisons de simplicité nous écrirons dans la suite modèle de texte en textèmes alors qu’il est
7
Nous devons avouer que notre « sondage » se base sur l’apparition du terme sur Internet et
dans les résultats de Google.
107
Le nouvel élément
textuel
L’origine du terme
textème
Une introduction
informelle au modèle
sous-entendu qu’il s’agit en réalité des traits communs des différents modèles
basés sur les textèmes.
2.3.1 D ÉFINITION FORMELLE DU
TEXTÈME
Nous avons déjà mentionné qu’une instance de textème — où des valeurs
ont été assignées aux clés de propriété — est une relation binaire de la strate T3
entre clés et valeurs de propriété.
DÉFINITION 9 (TEXTÈME)
n n
o
[
(tcléi (2) , tvaleuri (1) ) | tvaleuri (1) ∈ ext(tcléi (2) )
t ∈ T3 ; t =
i=1
où n est un entier naturel. Le cas aberrant du n = 0, le « textème vide »,
n’est pas explicitement interdit car il correspond à un phénomène existant
en pratique (même si non souhaitable et rare), cf. section 2.6.2. Notons que
les signes de l’univers T0 représentés par le textème t peuvent être obtenus à
l’aide de son extension commune, extc(t).
Le texte se définit tout simplement comme une chaîne, c’est-à-dire une
séquence ordonnée, de textèmes8 :
T = t1 t2 t3 ...
Une chaîne de textèmes de longueur n peut également être considérée
comme une relation n-aire d’éléments textèmes de T3 , relation dont la cardinalité est égale à 1. En définissant T4 de manière analogue aux strates inférieures, on peut considérer que le texte est une relation non-complexe de
T4 :
DÉFINITION 10 (TEXTE)
T = t(4) , t(4) ∈ T4 de sorte que ext(t(4) ) = {(t1 , t2 , ..., tn )}, ti sont des textèmes,
|ext(t(4) )| = 1
Texte et contexte
En comparant ces définitions avec celle en section 1.4.2, page 26 pour
d’usage le texte en caractères, on remarque l’absence de référence vers le contexte
d’usage. En effet, dans le chapitre précédent nous avions fait une distinction
entre la chaîne de caractères non contextuelle et le texte où le sens des éléments constitutifs s’interprète suivant le contexte d’usage. Cette distinction est
nettement moins utile pour le texte en textèmes puisque l’usage y est déjà représenté par l’ensemble de propriétés dont les textèmes sont construits. Ceci
étant dit, une notion de contexte pourrait tout de même s’avérer utile pour
la désambiguïsation du sens des propriétés dans la mesure où le sens exact
d’une propriété donnée est toujours dépendant de contexte. Nous n’excluons
donc pas la possibilité de parler de contexte extrinsèque comme dans le cas
du texte en caractères, et nous y reviendrons en section 2.5.
Les définitions que nous venons de donner peuvent paraître très simples
et claires, la plupart du travail reste cependant devant nous : il faut maintenant
interpréter les définitions, aussi bien en théorie que dans le cadre pratique des
usages informatiques.
8
Nous passons au gothique afin d’éviter toute confusion avec la notation déjà introduite
pour les strates.
108
2.4 CONSÉQUENCES DU MODÈLE
Il est important de distinguer entre trois aspects indépendants d’un modèle
de texte (et de tout modèle ayant des débouchés informatiques, d’ailleurs) :
sa conception théorique, son implémentation et finalement sa présentation
ou son interface vers l’utilisateur. Bien entendu, les principes théoriques du
modèle doivent être pris en charge par son implémentation informatique, et
cette dernière doit également fournir une interface vers l’humain (qui est le
programmeur d’applications ou l’utilisateur final) où transparaissent, même si
indirectement, ces mêmes principes. Néanmoins, afin de maintenir une certaine clarté de raisonnement, nous souhaitons éviter que la discussion de certains aspects théoriques du modèle proposé soit détournée par des considérations d’implémentation ou d’ergonomie d’usage. Ainsi, lorsque nous considérons le textème comme une liste de couples clé-valeur représentées dans
nos exemples par des étiquettes textuelles (par exemple : langue = français),
cela ne signifie pas forcément que le textème soit ainsi codé et stocké par l’ordinateur, ni que la propriété en question soit ainsi visualisée par l’utilisateur,
tout comme la forme de codage effective d’un caractère Unicode (en UTF-8,
UCS-16, etc.) ou sa présentation visuelle n’ont rien à voir avec son identité
sémantique telle qu’elle est définie dans la norme.
Pour ces raisons, nous consacrerons la suite de ce chapitre uniquement
aux considérations théoriques, en laissant les potentielles implémentations
informatiques optimisées du modèle, ainsi que la comparaison du nouveau
modèle à ses prédécesseurs en termes de besoin de ressources calculatoires
ou de stockage, pour le chapitre suivant. Quant aux conséquences du modèle
sur l’interface homme-machine, même si nous reconnaissons leur importance,
nous ne pourrons les aborder dans le cadre de cette thèse.
2.4.1 L’INTENSIONNALITÉ DE L’ENSEMBLE DES
Trois aspects :
conception,
implémentation,
interface
PROPRIÉTÉS
Ce que nous avons reproché à la norme Unicode était avant tout sa nature énumérative ou extensionnelle : un caractère est un caractère pour la
seule raison qu’il fait partie d’une longue liste que l’on appelle codage. Une
question qui se pose naturellement par rapport au modèle que nous venons
d’introduire est si l’ensemble T2 (les clés) n’a pas, en théorie ou en pratique,
la même nature. Est-ce qu’une « liste officielle » de clés doit exister, à partir
de laquelle un textème donné est assemblé ? Ou bien, les définit-on de manière intensionnelle : en observant les signes d’écriture du monde, a-t-on à
tout moment la possibilité de créer de nouvelles catégories selon ses besoins ?
D’après le cadre que nous avons construit en section 2.2, un élément de T1 L’ensemble
est l’intension d’éléments de T0 et de même, un élément de T2 est l’intension de propriétés
d’éléments de T1 . Il n’y a donc aucune raison théorique de limiter a priori n’est pas limité
les propriétés à une gamme « prêt-à-porter ». Au contraire, le pouvoir de notre
modèle réside dans le potentiel d’inventer de nouvelles propriétés au fur et à
mesure, suivant les besoins des usages actuels. L’ensemble des propriétés — et
par conséquent des clés — utilisables est ouvert à tout usager, non seulement
à des corps de normalisation ou à des grandes entreprises qui développent les
systèmes d’exploitation ou des logiciels de traitement textuel. Rien n’empêche
109
même la création de plusieurs propriétés décrivant la même information (c’està-dire ayant la même extension), chacun du point de vue d’un usage différent :
l’intensionnalité des ensembles T1 et T2 permet l’existence de telles propriétés
« synonymes ». Nous mettrons en valeur l’importance de ces principes dans les
sections suivantes.
La nature illimité de T1
L’augmentation constante du nombre de propriétés utilisées, donc du caret de T2 ne pose pas dinal de T1 et de T2 , n’a rien en commun avec le phénomène d’augmentation
de problème théorique des caractères codés par Unicode. Dans ce dernier cas, chaque version de
la norme est considérée close, et le nombre de caractères codés est supposé
converger vers une quantité « suffisante », ou du moins sa croissance est censée
diminuer au fur et à mesure. En revanche, les propriétés s’inventent suivant les
usages — qui ne cessent jamais d’évoluer — et l’utilisation immédiate des nouvelles propriétés ne devrait jamais être limitée par un refus de normalisation
éventuel de la part d’un organisme centralisé quelconque.
Le fait que nous laissons ouvert l’ensemble de propriétés ne signifie pas
qu’il n’y aurait pas besoin d’en normaliser un sous-ensemble bien défini. Au
contraire, ceci semble inévitable afin de permettre l’interopérabilité textuelle
entre différents individus et logiciels. Cette considération pratique sera développée dans le chapitre suivant.
2.4.2 L’ŒUF ET
LA POULE : LA CLÉ ET LA VALEUR
DE PROPRIÉTÉ , SONT- ELLES ÉGALEMENT DU TEXTE ?
Selon notre définition, une propriété est un couple clé-valeur. En pratique, on représente de telles propriétés souvent en forme textuelle, telle que
corps = 24pt ou forme_arabe = initial. En effet, la manière la plus naturelle
d’identifier une clé de propriété est de la nommer, ce que l’on fait intuitivement lorsque l’on recourt à des étiquettes textuelles. De même, des valeurs
de propriétés textuelles peuvent parfois être très utiles. Cependant, puisque
nous avons défini le texte comme étant une chaîne de textèmes, comment
définit-on le texte qui sert à décrire les clés et les valeurs de propriétés à l’intérieur de ceux-ci ? S’agirait-il de textèmes imbriqués dans des textèmes de
façon récursive et sans fin, comme la semence humaine contiendrait, a-t-on
pensé autrefois, de minuscules homunculus9 qui à leur tour contiennent des
homunculus encore plus microscopiques, jusqu’à l’infini ?
La question est sérieuse car en acceptant que le texte informatique soit
modélisé par une chaîne de textèmes, et le propos du paragraphe précédent
étant bien évidemment absurde, nous risquons, paraît-il, de devoir abandonner en pratique l’idée d’avoir des clés et des valeurs textuelles. Cependant,
il est de nouveau utile de séparer les considérations théoriques, implémentationnelles et interactionnelles. Nous avons défini la valeur de propriété comme
étant un sous-ensemble de O ⊂ T0 , et la clé comme étant un sous-ensemble
de tels sous-ensembles. Lorsque nous référons à la clé et à la valeur par des
noms textuels, ces noms ne sont en réalité que des étiquettes qui nous servent
à identifier les relations correspondantes. Autrement dit, ces noms textuels
« traduisent » à l’humain la signification des propriétés. Ils peuvent également
9
Puisque cette thèse s’écrit en français et non en latin, l’auteur refuse l’emploi de formes
plurielles telles que homonculi, scénarii, etc.
110
apparaître dans les implémentations du modèle en tant qu’identifiants, mais
encore une fois, ce n’est pas nécessaire : le logiciel peut très bien optimiser sa
représentation interne de clés et de valeurs en adoptant des identifiants numériques, et n’employer les noms textuels que pour l’interaction avec l’extérieur
(l’utilisateur humain ou un autre logiciel). Pour ces cas, il est tout à fait possible de faire recours à un alphabet restreint bien défini (un sous-ensemble
d’ASCII ou d’Unicode, par exemple) sans le moindrement mettre en cause la
cohérence de notre modèle.
2.4.3 CHANGEMENTS D’USAGE
Le même texte peut subir de nombreuses opérations appartenant à des
usages divers, surtout depuis l’existence de documents formatés interactifs et
donc manipulables. Dans le modèle de texte proposé (entre autres) par la
norme Unicode, le formatage consiste à passer du texte en caractères au texte
formaté en glyphes ; il s’agit donc d’un changement de « sous-modèle » au sein
d’un modèle à deux niveaux. Bien que cette approche, grâce à sa souplesse,
soit capable de s’adapter remarquablement bien aux particularités des différentes écritures du monde, elle présente également quelques inconvénients,
comme nous avons pu voir dans le chapitre précédent : les passages d’un
niveau à l’autre deviennent complexes lorsqu’une correspondance un-à-un
entre caractères et glyphes ne peut être établie (pp. 41, 54, 83), et d’autre part,
il existe une séparation artificelle entre propriétés de caractère et de glyphe
(p. 82).
Le modèle de texte en textèmes est libre de ces inconvénients car le chan- Plusieurs usages
gement d’usage n’entraîne pas de changement de modèle : la différence entre intégrés dans le même
usages graphiques et d’échange (ou d’autres) se manifeste principalement dans modèle
l’ajout ou la modification d’un ensemble différent de propriétés de la même
chaîne de textèmes. Le modèle de texte en textèmes est un modèle « monocaméral ». L’exemple simple en figure 2.12, page 138, représente un changement
d’usage depuis un usage linguistique ou d’échange vers un usage présentationnel : il s’agit d’une simple opération de formatage. On voit que la seule différence entre le texte initial et le texte formaté est dans le nombre de propriétés
attachées aux textèmes. Puisqu’il s’agit d’une opération additive — l’enrichissement de textèmes par propriétés —, aucune information n’est perdue lors du
changement d’usage.
Le changement d’usage étant une opération textuelle fondamentale et parfois complexe, malgré la simplicité apparente de l’exemple précédent, nous y
consacrerons une section séparée dans ce même chapitre (cf. 2.6).
2.4.4 R ELATIONS ENTRE
PROPRIÉTÉS ET TEXTÈMES
DÉRIVÉES DE LEURS EXTENSIONS ET INTENSIONS
Conceptuellement, nous avons situé les propriétés au niveau T1 de notre
cadre formel, la strate T0 inférieure étant l’ensemble de base de signes décrits
par celles-ci, et les strates supérieures étant responsables (entre autres) de la catégorisation de ces dernières. Nous allons maintenant examiner certains types
de relations entre propriétés de T1 qui découlent des relations ensemblistes
111
de leurs extensions respectives dans T0 . Nous allons également découvrir ce
que les catégories établies dans T2 et T3 , c’est-à-dire les clés et les catégories
fonctionnelles, ajoutent à l’interprétation des relations entre propriétés de T1 .
Notons que la plupart de nos observations ont déjà été les sujets d’une analyse détaillée, d’une point de vue de représentation des connaissances, dans
les thèses de Zaldivar [71] et de Kanellos [39].
ÉGALITÉ
DES PROPRIÉTÉS
Plusieurs notions
La notion d’égalité entre relations peut être interprétée de plusieurs mad’égalité nières, ce qui est une conséquence de la non-extensionnalité des strates T1 et
dans la représentation supérieures. Rappelons que la non-extensionnalité signifie que deux relations
à strates t et t de T peuvent être des éléments non-identiques (c’est-à-dire i 6= j)
i
j
1
Égalité de chaînes
textuelles
Identité
ou égalité superficielle
Égalité extensionnelle
même si elles ont la même extension (ext(ti ) = ext(tj )). Le « sens » de leur
différence (en reprenant l’expression employée par Zaldivar : leur identité sémantique) est décrit par leur catégorisation et en général par les relations de
rang supérieur leur faisant référence. Ainsi, l’égalité extensionnelle n’est qu’un
parmi les différents niveaux d’égalité qui peuvent être établis entre deux relations.
Dans le cadre de notre modèle de texte, ces considérations ont une très
grande importance car la vérification de l’égalité de deux signes ou de deux
morceaux de texte est parmi les opérations textuelles les plus basiques et les
plus fréquemment employées. La question que nous cherchons à répondre est
la suivante : comment — à l’aide de quelle notion d’égalité — compare-t-on
deux chaînes textuelles ?
La réponse la plus triviale est d’exiger que les deux chaînes aient le même
nombre de textèmes et que les textèmes respectifs soient composés des mêmes
propriétés, c’est-à-dire des mêmes clés et des mêmes valeurs. Cette condition,
la plus restrictive que possible, est bien évidemment suffisante, mais elle n’est
pas forcément nécessaire. Une interprétation plus faible de l’égalité de deux
textèmes est de n’exiger que leur égalité extensionnelle : qu’ils dénotent le
même signe ou (plus précisément) la même classe de signes, exprimée à l’aide
de leur extension commune (p. 104). Si ti et tj sont des textèmes, c’est-à-dire
des relations binaires de T3 entre clés et valeurs, alors
ti =ext tj ⇔ extc(ti ) = extc(tj )
c’est-à-dire que si φi,1 , ..., φi,n sont les propriétés de ti et φj,1 , ..., φj,m les propriétés de tj , alors
ext(φi,1 ) ∩ ... ∩ ext(φi,n ) = ext(φj,1 ) ∩ ... ∩ ext(φj,m )
où l’égalité ici représente l’égalité ensembliste. L’égalité extensionnelle de
deux textèmes signifie donc que les intersections des extensions de leurs propriétés respectives dans T0 comprennent les mêmes signes. Il est facile à vérifier qu’il s’agit d’une relation d’équivalence [71, p. 56].
Pertinence pratique
L’égalité extensionnelle est avant tout une notion théorique dont l’exploide l’égalité tation en pratique peut s’avérer plus ou moins possible. Le problème est qu’en
extensionnelle général les extensions des propriétés ne sont pas connues (« quels sont tous
112
les signes qui représentent des voyelles ? », avons-nous déjà exprimé ainsi l’impossibilité d’énumérer ces ensembles), et par conséquent les relations ensemblistes ne peuvent être vérifiées. Il existe une situation dans laquelle une telle
approche peut néanmoins fonctionner : lorsque l’ensemble de base de signes,
O ⊂ T0 , est réduit à un sous-ensemble bien circonscrit et énumérable, à la
manière d’une table de codage. Sur un tel ensemble restreint, il devient possible de créer une base de connaissances de signes, à la manière de la BD Base de connaissances
d’Unicode mais plus étendue. À l’aide d’une telle base de connaissances, il de signes
est facile de retrouver l’extension d’une propriété donnée, et d’ainsi vérifier
l’égalité extensionnelle de deux propriétés, voire de deux textèmes (en temps
linéaire).
Une autre solution, moins efficace mais ne nécessitant pas l’existence d’un Base de connaissances
ensemble énuméré de signes disponibles, est la déclaration explicite de l’éga- de propriétés
lité entre propriétés. Il s’agit encore une fois d’une base de connaissances
(qui n’est pas forcément centralisée, comme nous le verrons dans le chapitre
suivant) décrivant non pas des signes mais des propriétés individuelles. Une
partie de cette description est l’énumération de propriétés qui sont, individuellement ou en groupe, équivalentes à la propriété qui est en train d’être décrite.
Par exemple, lorsque certains textes emploient une propriété nommée, disons,
arab_form = final afin d’indiquer la forme finale des lettres arabes et d’autres
textes emploient pour ce qui est exactement la même fonction une autre propriété nommée form_arab = fina, alors la base de connaissances peut indiquer
l’équivalence des deux clés et des deux valeurs. L’idéal serait, bien entendu,
de n’avoir qu’une seule propriété ayant cette sémantique, mais ceci ne peut
en général être assuré à cause de l’intensionnalité de notre modèle qui montre
une attitude libérale envers la création de nouvelles propriétés.
Entre les égalités superficielle et extensionnelle, il est possible d’en définir Égalités
encore d’autres, plus restrictives que la dernière mais plus permissives que non-extensionnelles
la première. En effet, entre deux propriétés extensionnellement égales mais
non identiques, on peut distinguer non seulement par leur étiquette (représentée par des chaînes de caractères ou par des entiers : cela n’a pas d’importance) mais également à l’aide des relations de rangs supérieurs qui les
caractérisent, et notamment par leurs catégories fonctionnelles. L’importance
pratique de telles formes d’égalité peut être illustrée par l’exemple suivant :
supposons qu’un algorithme chargé de la simplification (ou normalisation)
d’une chaîne de textèmes est censé substituer toutes les propriétés extensionnellement égales par une même propriété choisie par défaut. Malgré le fait
que toutes les propriétés dans une même classe d’équivalence extensionnelle
dénotent exactement les mêmes signes de T0 , elles n’appartiennent pas forcément à la même catégorie fonctionnelle de T3 , autrement dit, au même usage.
L’opération de substitution de propriétés peut donc créer des textèmes dont
certaines propriétés ne correspondent pas aux usages que le texte a subis, et
qui risquent de ne pas être considérées de la même manière que les propriétés
qu’elles remplacent, voire d’être supprimées lors d’un filtrage du texte selon
l’usage (cf. section 2.6). En conséquence, il est préférable que l’algorithme de
normalisation vérifie non pas l’égalité extensionnelle de deux propriétés mais
une égalité plus restreinte qui exige que celles-ci appartiennent aux mêmes
catégories fonctionnelles de T3 .
113
RELATION
DE DÉPENDANCE ENTRE PROPRIÉTÉS
Tout comme l’égalité extensionnelle entre deux propriétés, ext(φi ) =
ext(φj ), le cas plus général des relations de compréhension entre les extensions possède également une sémantique particulière. La relation ext(φi ) ⊆
ext(φj ) exprime que tous les signes caractérisés par φi sont forcément caractérisés par φj également. Nous appelons cette relation entre propriétés dépendance ou dépendance fonctionnelle10 . Puisque nous consacrerons une
section entière (2.7) à l’analyse du phénomène de dépendance, nous nous
contentons ici de mentionner son existence.
2.4.5 L A
Segmentation intuitive
Segmentation intuitive
et considérations
pratiques
STRUCTURE DU TEXTE EN TEXTÈMES
À la base, le texte écrit est une chaîne unidimensionnelle de signes d’écriture, ce qui témoigne de sa liaison inévitable avec la parole. Cette propriété
générale n’est bien évidemment pas en contradiction ni avec les aspects bidimensionnels intra-signe (dans le logogramme chinois, dans la syllabe hangûl,
dans la lettre diacritée), ni avec quelques usages spécialisés éloignés de la
parole qui organisent l’information textuelle en deux dimensions (comme les
formules mathématiques), ni avec la mise en page qui forme le texte unidimensionnel en pavés rectangulaires. À un niveau précis, et ce niveau dépend de
l’écriture et de l’usage en question, le texte écrit se segmente naturellement
et intuitivement en une chaîne de signes unidimensionnelle. Dans [58], Richard Sproat appelle Small Linguistic Unit cet élément constitutif de la chaîne
textuelle11 .
Cependant, même si le niveau de segmentation unidimensionnelle peut
pour la plupart des écritures être aisément déterminé, cela ne veut pas dire que
ce niveau soit le plus pratique pour une modélisation informatique. Si c’était
encore le cas pour de nombreux codages de caractères historiques « naïfs »,
Unicode a adopté une approche différente :
– dans les écritures alphabétiques, les diacritiques sont devenus des caractères à part (de classe combinante) ;
– dans le hangûl, où la Small Linguistic Unit correspond à la syllabe,
une modélisation alphabétique (et donc sous-syllabique) a également
été proposée ;
– dans les écritures indiennes, la Small Linguistic Unit correspond au
groupe (ou cluster) d’une voyelle et de toutes les consonnes qui la précèdent ; Unicode a cependant choisi de coder voyelles et consonnes
séparément.
Le choix d’un niveau de segmentation particulier par rapport à d’autres
segmentations possibles peut être motivé par de nombreuses considérations :
10
La dépendance n’est pas la seule interprétation sémantique possible de la relation de compréhension : entre autres, la notion d’héritage y trouve ses origines également. L’interprétation
à choisir dépend, bien sûr, du phénomène que nous visons à modéliser.
11
D’ailleurs, l’auteur n’est au courant que d’une seule écriture naturelle qui n’obéisse pas
complètement à ce principe : dans l’époque archaïque de l’écriture sumérienne cunéiforme
(dans la même époque où le sens de l’écriture est passé du vertical à l’horizontal), le texte à
l’intérieur d’une colonne/ligne se divisait en « cases ». Une case pouvait contenir une poignée
de signes, dans un ordre indépendant de l’ordre de lecture. Même dans cette écriture il existe
donc une segmentation unidimensionnelle (les cases), encore qu’à un niveau relativement haut.
114
– la réduction du nombre de signes dans le répertoire ;
– la facilité de traitement automatique (linguistique, présentationnel, etc.) ;
– la compatibilité avec d’anciennes normes, technologies et habitudes ;
– l’adaptativité aux méthodes de saisie et aux contraintes matérielles ;
– l’aspect intuitif pour l’utilisateur (y compris le programmeur).
Dans le modèle de texte caractère-glyphe, la segmentation est choisie selon des critères différents pour la chaîne de caractères et pour la chaîne de
glyphes. Pour cette raison, lorsque les unités pertinentes des deux chaînes sont
d’une granularité différente, la maintenance du graphe de correspondances
entre les deux chaînes devient primordiale.
Le choix de l’unité pertinente est également très important dans le cadre Le choix du segment
du modèle en textèmes. Il peut être motivé par les mêmes considérations mais détermine le contenu
le fait que le textème possède une structure interne permet de choisir comme du textème
unité pertinente une segmentation de niveau relativement haut et d’ensuite
décomposer chaque unité pertinente à l’intérieur de son textème à l’aide des
propriétés. De cette manière, dans le modèle en textèmes, des considérations
qui étaient contradictoires dans le modèle caractère-glyphe peuvent être satisfaites simultanément. Notamment, le choix d’une unité textuelle intuitive de
niveau relativement plus haut, comme la syllabe hangûl, n’entraîne pas forcément le besoin d’un répertoire immense de signes, car ceux-ci sont représentés
dans les textèmes par leur composants de plus bas niveau et beaucoup moins
nombreux. Nous verrons des exemples plus détaillés en section 2.4.6. Notons
qu’une telle approche peut nécessiter une légère extension de notre modèle
afin de permettre l’imbrication de propriétés, i.e., que celles-ci soient structurées en arbres ; nous reviendrons également à ce problème dans la même
section.
2.4.6 P ERTINENCE VIS- À -VIS DES
ÉCRITURES DU MONDE
Dans les cultures alphabétiques, on est habitué à considérer les unités
constitutives de son écriture comme les éléments d’un répertoire bien restreint. Ce n’est pas par hasard que les modèles textuels initialement développés se basaient sur la table de codage qui suivait le même principe énumératif.
Ce n’est pas par hasard non plus que ce principe a commencé à montrer ses
faiblesses au moment où il a été appliqué sans réflexion à la totalité des écritures du monde comme l’arabe, le chinois ou le coréen, écritures qui nous
serviront comme exemples pour mettre en valeur certains aspects utiles des
textèmes.
ÉCRITURES
ALPHABÉTIQUES
Pour l’esprit éduqué dans un milieu alphabétique, regarder la lettre comme
étant un ensemble plus ou moins volatile de propriétés peut paraître étrange.
On nous demande de renoncer à la terre ferme sous nos pieds — la lettre
comme atome, membre de l’alphabet que l’on s’approprie dès le plus jeune
âge — en faveur d’une expressivité déconcertante qu’offrent les propriétés. Par La lettre « A »
exemple, comment peut se caractériser une lettre « A » en tant que textème ? en tant que textème
Ses propriétés peuvent être les suivantes :
– appartenir à la famille des écritures d’origine latine ;
115
– être une lettre ;
– être la première lettre de l’alphabet (français, latin, etc.) ;
– être en forme majuscule.
Ce sont à peu près les propriétés du caractère U+0041 tel qu’il est défini dans
Unicode. Mais nous n’avons aucun mal à trouver d’autres propriétés qui le
caractérisent :
– représenter une voyelle ;
– en français, être parfois une forme alternative de la lettre « À » ;
– être composé de trois traits (deux inclinés et un horizontal).
Une visualisation plus rigoureuse et de style plus « informatique » pourrait être
la suivante (que nous adopterons également pour afficher les textèmes d’une
façon intuitive dans la suite de cette thèse) :
script = latin
function = letter
latin_pos = 1
case = upper
phon_cat = vowel
Avantages
et inconvénients
du textème par rapport
au caractère Unicode
ou au glyphe
Caractère Unicode
dans le textème
Cette représentation, est-elle plus compliquée que « 0048 » ? Certainement.
Il faut cependant comprendre que la complexité apparente est tout d’abord
due au fait que notre exemple de textème fournit davantage d’informations
que le caractère Unicode. La plupart des propriétés explicitement présentes
dans le textème ne sont disponibles pour un caractère Unicode qu’à travers sa
base de données. D’autres, comme « être voyelle », n’y sont pas disponibles du
tout. En fonction de l’usage, le textème peut s’avérer plus ou moins pratique
que le code de caractère Unicode ou le code de glyphe ; typiquement, plus les
usages d’un texte sont variés, plus l’approche textème devient utile. Un texte
en textèmes qui subit du traitement aussi bien linguistique que typographique
pour ensuite être indexé et recherché se prête bien plus aisément à ces opérations que l’équivalent en caractères ou en glyphes où le code numérique
réfère implicitement à un nombre de propriétés figées. En revanche, lorsque
les usages du texte sont plus simples (par exemple, traitement de code source
dont les caractères se limitent à la gamme ASCII), la représentation de celui-ci
par une suite de codes numériques est probablement plus pratique.
Par ces considérations nous nous approchons des questions d’implémentation que nous souhaitons couvrir séparément, dans le chapitre suivant. En
anticipation, nous signalons qu’une approche mixte — à la fois intensionnelle
et extensionnelle — qui permet de profiter des avantages des deux mondes est
tout à fait envisageable : le code de caractère Unicode ou le code de glyphe
peuvent également devenir des propriétés du textème. Ainsi, le textème
unicode = 0041
phon_cat = vowel
Le modèle en textèmes
est compatible
avec le modèle
Unicode
donne des renseignements équivalents au précédent (pourvu que l’accès à la
BD d’Unicode soit disponible) et la propriété unicode = 0041 peut être considérée comme l’abréviation russellienne des quatre autres. Un texte dont les
textèmes ne contiennent que la valeur Unicode comme propriété est équivalent à une chaîne Unicode ; par conséquent, notre modèle est capable
d’émuler et est donc compatible avec le modèle de texte d’Unicode.
116
ÉCRITURES
LOGOGRAPHIQUES
Les hanzi chinois, kanji japonais et hanja coréens sont les éléments des
trois écritures logographiques dont l’origine est commune. Nous avons déjà
présenté certaines particularités de ces écritures en section 1.6.2. Nous ne
faisons que réitérer ici notre observation selon laquelle le logogramme n’est en
réalité pas l’unité atomique de l’écriture logographique comme l’est la lettre
des écritures alphabétiques. Il se construit à partir de composants (dont un
radical) qui eux-mêmes se décomposent graphiquement en traits élémentaires
bien définis. Bien que cette manière de décomposer le logogramme asiatique
soit avant tout basée sur des considérations graphiques, la prononciation et/ou
le sens du logogramme sont très souvent en corrélation avec la prononciation
et/ou le sens de ses composants [26, chapitre 5].
Nous avons montré (section 1.6.2) les inconvénients du codage des dizaines de milliers de logogrammes individuellement, comme fait Unicode, en
argumentant en faveur d’une approche analytique et constructiviste. Le textème est un cadre idéal pour une description analytique du logogramme car,
à travers les propriétés, il offre la possibilité d’en indiquer la construction graphique, la prononciation et le sens, aussi bien pour le logogramme entier que
pour ses composants :
– la possibilité de définir un logogramme à travers sa composition graphique correspond mieux à la nature ouverte des écritures logographiques que l’approche d’Unicode qui les regarde comme une liste définitive ;
– la polysémie occasionnelle des logogrammes peut rendre utile pour certains usages (éducation, désambiguïsation) l’indication explicite du sens
du logogramme à travers une propriété ;
– enfin, le même logogramme peut avoir différentes prononciations (surtout en japonais mais également en chinois), nécessitant parfois une
propriété pour indiquer la prononciation appropriée dans le contexte
donné.
En admettant qu’un textème représente un logogramme dans lequel une
propriété structure est censée décrire les composants graphiques de celui-ci,
comment représenter le sens et la prononciation des composants ? Logiquement, la propriété structure doit être une propriété complexe qui se définit à
son tour également par un ensemble de propriétés. Cela veut dire que la valeur de la propriété structure devrait pouvoir contenir un ensemble de couples
clé-valeur, et ceci de manière récursive. Plus généralement, la structure d’une
propriété devrait pouvoir prendre la forme d’un arbre, comme sur l’exemple
de la figure 2.6. Nous examinerons l’intérêt potentiel, en théorie et en pratique, de cette extension de modèle en section 2.6.2.
LE
HANGÛL CORÉEN
Nous avons présenté les propriétés principales de l’écriture coréenne
en section 1.6.2. Peut-être plus encore que les écritures logographiques
(car la structure graphique coïncide parfaitement avec la structure morpho117
Le logogramme
n’est pas un atome
Le textème : description
analytique
du logogramme
La propriété
en tant qu’arbre ?
FIG. 2.6 – Les propriétés du logogramme chinois « zhào » s’organisent naturellement en une structure arborescente.
Représentations
syllabique
ou par jamos,
par Unicode
et dans la fonte
phonémique de la syllabe12 ), le hangûl se prête naturellement à une description analytique.
Unicode propose deux méthodes pour coder du texte en hangûl : par syllabes pré-composées ou par jamos individuels. De manière analogue, deux
types de fontes coréennes peuvent être envisagés : celles qui contiennent des
glyphes de syllabes entières et celles qui assemblent les syllabes à partir de
composants élémentaires13 . Par conséquent, en combinant la méthode de codage par Unicode avec la méthode d’affichage par la fonte, quatre cas peuvent
arriver :
1. caractère jamo 7→ glyphe jamo ;
2. caractères jamo 7→ glyphe pré-composé ;
3. caractère pré-composé 7→ glyphes jamo ;
4. caractère pré-composé 7→ glyphe pré-composé.
Le quatrième cas semble être le plus courant dans les usages pratiques (fontes
courantes, documents HTML, etc.) car il est le seul à être compatible avec
les technologies historiques. Quant aux cas 2 et 3, les opérations de composition et de décomposition peuvent en théorie être résolues aussi bien dans
le domaine des caractères que dans le domaine de glyphes (par la fonte).
La conversion caractères jamo ↔ caractère pré-composé est une opération triviale grâce à la « formule magique » présentée en section 1.6.2, encore que
le logiciel de composition doive être préparé à effectuer cette conversion automatiquement. Dans le domaine des glyphes la même conversion nécessite
un format de fonte intelligent qui puisse définir des substitutions de glyphe
un-à-multiple et multiple-à-un. Finalement, le premier cas correspond à une
simple substitution un-à-un mais la disposition bidimensionnelle des glyphes
jamo en syllabes-blocs nécessite encore une fois des formats de fonte capables
d’indiquer un déplacement à la fois horizontal et vertical.
L’inconvénient majeur des cas 2, 3 et 4 reste cependant la nécessité de devoir répertorier une dizaine de milliers de caractères Unicode pré-composés
et/ou de devoir dessiner et inclure dans chaque fonte le même nombre de
12
L’orthographe coréenne, et plus particulièrement le fait si elle devrait suivre le principe
phonétique ou le principe morphologique, a toujours été sujet de débat en Corée [19, p. 223].
13
Bien entendu, cette dernière approche nécessite un format de fonte intelligent. Il est également possible de combiner les deux approches.
118
glyphes. Ces inconvénients sont aujourd’hui surmontables grâce à l’augmentation en puissance des ordinateurs. Les solutions qui se basent sur la précomposition restent cependant suboptimales en termes d’économie d’espace
de stockage ou encore de transparence (car un simple identifiant numérique
dit très peu de l’identité d’un glyphe ou d’un caractère).
L’utilisation de textèmes pour l’écriture hangûl permet de combiner les Le textème offre
avantages du principe d’économie et le structuralisme de la représentation une représentation
alphabétique avec le caractère intuitif de la représentation syllabique (car la combinée
syllabe reste l’élément intuitif de l’écriture, le Small Linguistic Unit, voir section 2.4.5). Dans cet objectif, un textème correspondra à une syllabe. Cette
syllabe ne sera cependant pas identifiée par un simple code numérique mais
par ses composants alphabétiques (la valeur Unicode a été ajoutée en tant que
propriété dans un objectif de référence) :
script = korean
onset =
peak =
coda =
unicode = U+AC10
glyph =
Dans notre exemple, on réalise une correspondance trois-à-un au sein d’un
textème entre les composants de syllabe et le glyphe (ce dernier serait en réalité représenté par un couple de propriétés fonte-identifiant). La décomposition
permet de réduire le répertoire de signes élémentaires à la taille de l’alphabet,
alors que le textème entier correspond à la syllabe, l’unité intuitive de l’écriture, et permet d’attacher des propriétés supplémentaires à celle-ci dans sa
globalité. Si, par contre, il devenait nécessaire d’associer des informations aux
trois composants élémentaires individuellement, par exemple dans le but de
fournir une translittération phonétique latine par laquelle on associe à chaque
lettre hangûl son équivalent latin, alors une structure arborescente de propriétés serait encore une fois très utile, comme sur la fig. 2.6 à propos des écritures
logographiques.
L’ÉCRITURE
ARABE
L’arabe est une des écritures qui ont énormément profité de l’apparition
d’Unicode et des technologies de fonte intelligentes. Le codage de l’alphabet
arabe dans Unicode est défini suivant des considérations linguistiques : l’unité
de codage choisie est le graphème (la lettre), représentant écrit du phonème.
Les différentes formes cursives que les lettres prennent au début du mot, au milieu, à la fin ou en isolation, ou encore les ligatures ne sont pas devenues des
caractères Unicode séparés14 (voir page 65). La raison derrière ce choix a été
de créer un codage arabe qui fait abstraction de tout aspect visuel de l’écriture,
ce qui facilite certains usages comme la recherche textuelle. Il appartient au
processus de composition de texte et à la fonte intelligente d’exécuter l’analyse
contextuelle du texte Unicode arabe et de faire correspondre à chaque caractère le glyphe — l’allographe contextuel, la ligature, etc. — approprié.
14
À part, bien sûr, les formes de présentation dont l’usage est découragé par Unicode.
119
Les inconvénients
de l’approche
d’Unicode
La souplesse
de la représentation
textémique
Cette séparation nette des usages visuels et non-visuels (qui d’ailleurs n’a
pas toujours été suivie pour d’autres écritures ayant pourtant quelques particularités similaires, comme par exemple l’hébreu) a été sagement choisie de
sorte que le modèle s’adapte aux usages les plus importants ; cependant, la
même séparation du texte en caractères et du texte en glyphes, l’exorcisation
de toute propriété visuelle du premier et en pratique la quasi-impossibilité de
toute manipulation interactive du dernier, ont abouti à la mise sur pied d’un
modèle de texte qui rend la composition arabe lourde et peu souple. D’une
part, l’utilisateur qui introduit son texte en caractères a peu de contrôle sur
l’aspect visuel de celui-ci car les caractères arabes ne portent aucune information visuelle. D’autre part, même si le document formaté qui en résulte
est capable d’offrir des fonctionnalités interactives comme la recherche ou le
copier-coller (ce qui est déjà un cas rare en réalité), ces fonctionnalités sont
limitées au contenu en caractères : entre autres, une recherche intelligente sur
des propriétés visuelles du texte est impossible.
Dans le textème, en revanche, aucune séparation artificielle n’est faite
entre modes de représentation visuels et non-visuels. L’opération de formatage
se fait globalement de la même manière que dans le modèle caractère-glyphe :
en partant d’un texte non-formaté (première ligne de textèmes ci-dessous),
d’abord une analyse contextuelle y est effectuée afin de déterminer les formes
contextuelles des lettres individuelles (deuxième ligne).
letter =
letter =
form = init
letter =
letter =
form = medi
letter =
letter =
form = fina
Ensuite, à l’aide de ces informations, les formes appropriées des glyphes
sont retrouvées dans la fonte intelligente et indiquées dans les textèmes :
letter =
form = init
font = myfont
glyphID = 15 ( )
letter =
form = medi
font = myfont
glyphID = 16 ( )
letter =
form = fina
font = myfont
glyphID = 3 ( )
Les formes contextuelles peuvent également être indiquées explicitement
par l’utilisateur au moment de l’introduction du texte, ce qui peut être utile
dans les cas exceptionnels où la forme d’une lettre ne correspond pas à sa
position dans le mot : par exemple, pour indiquer qu’il s’agit d’un mot abrégé,
la lettre en position finale doit garder sa forme médiane ou initiale. Dans un
texte Unicode, le même effet nécessite l’introduction d’un caractère spécial
ZERO-WIDTH JOINER, artefact qui rompt le texte arabe et dont l’existence n’est
peut-être même pas connue par l’utilisateur.
2.4.7 L E
TEXTÈME PERMET L’ INVENTION D ’ USAGES NOVATEURS
La primauté
Dans la grande majorité des implémentations pratiques du modèle caracdu caractère tère-glyphe, la primauté est donnée au texte en caractères : c’est le caractère,
sur le glyphe et non le glyphe, qui a été choisi comme unité de représentation d’échange ;
les fichiers texte contiennent des caractères et non des glyphes ; les documents
120
HTML et XML, constituants du Web, sont en caractères ; le M-text de la bibliothèque m17n (voir page 86) est en caractères ; et ainsi de suite. Le texte est
stocké et manipulé dans sa forme « brute », en tant que chaînes de caractères
avec éventuellement des données associées (comme par exemple du balisage).
À quelques exceptions près, comme les formats de document PDF et SVG, le
texte passe à sa représentation finale dans le seul but d’être visualisé, et cette
représentation n’est pas considérée comme faisant partie essentielle du texte.
Le glyphe est juste une partie de l’image formatée et non pas du texte « réel »
d’origine.
Les textèmes bouleversent cette vision. En admettant qu’un textème re- Dans le textème,
présente un signe d’écriture (ce qui n’est pas forcément le cas, comme nous pas d’usage a priori
verrons plus loin), a priori rien n’oblige qu’il se définisse uniquement par des préféré
propriétés qui caractérisent les caractères Unicode. La présence de telles propriétés est sans doute utile mais nullement obligatoire, et on peut très bien imaginer des chaînes de textèmes où seules des propriétés graphiques sont présentes (fonte, ID de glyphe, position, couleur, etc.) ou des propriétés de glyphe
et de caractère simultanément, comme dans la seconde ligne de l’exemple de
la figure 2.12, page 138. Le texte en textèmes est donc capable de simuler le
texte en caractères, le texte en glyphes, ou les deux à la fois.
Que se passe-t-il lorsque l’ensemble de propriétés dans un textème ne
contient ni les propriétés associées au caractère ni celles associées au glyphe ?
S’agit-il encore d’un signe d’écriture ? Par exemple, dans le textème
script = latin
function = letter
latin_pos = 1
Textème sans caractère
ni glyphe
nous avons omis l’indication de casse : il peut s’agir aussi bien d’un « a » minuscule que d’un « A » majuscule. Le signe est donc sous-défini par rapport au
codage Unicode (mais non par rapport à la première version du codage ASCII
de 1963). Malgré cette abstraction, ce textème peut pourtant bel et bien être
considéré comme représentant d’un signe d’écriture, tout comme le caractère
Unicode U+0644 ARABIC LETTER LAM peut l’être malgré la non-indication de
sa forme contextuelle. Comme nous avons démontré en section 1.8.4, qu’un
signe soit abstrait ou non est toujours relatif à un usage.
Que dire alors du texte suivant :
Nouvelles formes
textuelles
phon_cat = consonant
phon_cat = consonant
phon_cat = vowel
S’agit-il encore de signes d’écriture, voire même de texte, étant donné que
la seule information présente est une catégorie phonétique ? Puisque dans le
cadre de notre modèle nous avons défini le texte comme étant une chaîne de
textèmes, l’exemple ci-dessus remplit toujours ce critère. D’autre part, il serait
difficile de trouver une définition exacte pour ce terme qui soit en concordance avec son emploi très diversifié aussi bien dans l’usage courant que dans
les sciences, tellement il est devenu un concept « fourre-tout ». Vue de cet
angle, notre interprétation ne semble donc pas être extravagante. Dire qu’il
s’agit de signes d’écriture serait par contre cette fois-ci une exagération : plutôt,
ces textèmes pourraient être considérés comme étant des « classes de signes
121
représentant des voyelles ». Il faut réaliser cependant qu’un textème ne repréLe textème représente sente jamais autre chose qu’une classe de signes : même un signe aussi bien
toujours une classe circonscrit qu’un « L » majuscule, en langue allemande, en fonte Optima (noude signes velle version), corps Medium 24pt, à une définition de 600dpi, en couleur
noire, ne correspond toujours qu’à la classe de toutes les lettres existantes qui
correspondent à nos critères, et il est toujours possible de continuer à restreindre la couverture, en ajoutant par exemple la propriété « être en position
initiale dans le mot Lieber ». Si l’exemple de trois textèmes ci-dessus paraît
inhabituel, c’est parce que l’usage potentiel d’un tel texte est probablement
très différent des usages textuels informatiques auxquels nous nous sommes
en général habitués. Or, la chaîne de caractères Unicode peut s’avérer tout
aussi inadaptée et sous-définie pour certains usages comme la représentation
informatique d’un manuscrit du Coran ou du Torah où toute altération de « la
parole de Dieu » relève de sacrilège. Il n’y a donc de sens de parler de signe
ou de texte sous-défini qu’en fonction d’un usage donné. D’ailleurs, le seul
genre de textème complètement défini serait probablement similaire à :
sign = le tout premier signe dans la lettre de W. A. Mozart
écrite à son père le 17 août 1776
Retournons à l’exemple de deux consonnes suivies par une voyelle. Une
chose est d’admettre que, d’après notre définition, cette suite de textèmes a
tout droit d’être appelée texte, mais il reste à démontrer l’utilité d’une telle
interprétation libérale.
Utilité est toujours fonction d’usage, et tous les usages novateurs d’un nouveau concept comme le textème ne sont pas toujours prévisibles. Un texte
comme celui d’en haut peut représenter, par exemple, de l’information extraite d’un morceau de parole enregistré, comme étant le résultat d’une première analyse vers sa reconnaissance automatique. Ou il peut être le résultat
de la première étape de la conversion d’un texte coréen codé de manière alphabétique vers son codage par syllabes, où les frontières des syllabes sont
reconnues à l’aide de règles phonétiques de la langue coréenne.
Sans même essayer d’être exhaustif dans notre recherche de nouveaux
usages potentiels de toutes les combinaisons de propriétés que nous pouvons
inventer, nous souhaitons donner ici quelques exemples qui illustrent le fait
que le texte en textèmes offre des modes de représentation textuels que les
modèles anciens, comme le modèle caractère-glyphe, ne peuvent capter de
façon satisfaisante.
RECONNAISSANCE
OPTIQUE DE TEXTE
Il est connu que la reconnaissance optique de texte est une opération stochastique dans le sens où l’identité des signes individuels ne peut être reconnue qu’avec une certaine probabilité. Il arrive parfois, en fonction des propriétés graphiques mais aussi linguistiques du texte à reconnaître, que la décision
entre plusieurs signes candidats ne soit pas évidente. Si le texte reconnu est
représenté par une chaîne de caractères, le logiciel doit alors choisir parmi
les signes candidats celui dont la probabilité est la plus élevée, ou s’il existe
plusieurs candidats à probabilité égale, alors le choix doit se faire au hasard.
En revanche, le modèle en textèmes permet d’inclure dans le même textème
122
tous les signes candidats, avec leurs probabilités associées (voir exemple cidessous). Ceci peut être utile pour une éventuelle décision ultérieure, que ce
soit à l’aide d’un utilisateur humain ou d’un logiciel automatique de traitement
linguistique extérieur.
lang = french
letter_1 = f
prob_1 = 60%
letter_2 = t
prob_2 = 40%
lang = french
letter = a
lang = french
letter = u
lang = french
letter = x
Ici, nous dérivons légèrement de notre modèle d’origine : en réalité, les
propriétés letter_1 et letter_2 sont des alternatives, de sorte que le textème
représente l’union (et non l’intersection) des ensembles des lettres « f » et « t ».
Afin de rendre cette approche possible, nous permettons dans un textème la
présence de plusieurs couples clé-valeur ayant la même clé mais des valeurs
différentes15 :
i 6= j, tclé(2)i = tclé(2)j , tvaleur(1)i 6= tvaleur(1)j
pourvu que cela soit interprétée de sorte que le textème réfère à une classe de
signes ayant une (et une seule) parmi les propriétés en contradiction.
REPRÉSENTATION
PROBABILISTE DE TEXTES ARABES ANCIENS
La même approche probabiliste peut s’avérer utile dans un contexte très
différent : la représentation informatique des textes arabes anciens. Comme
mentionne Haralambous dans [27], dans son état initial l’écriture arabe ne se
servait pas de points sur les lettres telles que bâ, tâ, thâ, nûn, etc., ce qui entraînait une certaine ambiguïté lors de la lecture des lettres concernées. Même
si le phonème représenté peut dans la plupart des cas être deviné à partir du
contexte, des situations existent où la signification ne peut être indiquée que
par des probabilités (voir figure 2.7). Une telle indication peut cependant être
utile non seulement pour la lecture mais aussi dans un contexte d’étude paléographique.
Le même article [27] de Haralambous fournit de nombreux autres exemples
de signes où ni la catégorie de caractère, ni celle de glyphe n’est appropriée
pour décrire certains phénomènes textuels. Il serait inutile de reproduire ces
exemples ici ; notons cependant que dans l’article on voit apparaître la même
idée de propriété mais avec une interprétation légèrement différente : en tant
qu’extension du texte en caractères ou du texte en glyphes au moyen d’informations supplémentaires. Ce type d’usage des propriétés peut être considéré
comme un modèle particulier de la famille de modèles que nous avons appelé
jusqu’ici, d’une manière un peu simplificatrice, modèle de texte en textèmes.
REMÉDIER
AUX DÉFAUTS D’UNICODE
Les exemples suivants serviront à mettre en évidence la manière dont l’approche intensionnelle de description des signes d’un texte à travers leurs pro15
En pratique, on suppose qu’il existe au moins un « indice » par lequel ces propriétés qui
ont la même clé peuvent être distinguées.
123
script = arabic
letter = kâf
script = arabic
letter = lâm
script = arabic
letter1 = bâ
prob1 = 60%
letter2 = tâ
prob2 =38%
letter3 = thâ
prob3 =1%
letter4 = undotted
quranic letter
prob4 =1%
FIG. 2.7 – Exemple tiré de [27] : la valeur de la dernière lettre sans indication
de point(s) est ambiguë, les alternatives possibles et leurs probabilités ont été
indiquées dans le textème correspondant.
Autant de caractères
Unicode
que de combinaisons
de propriétés
Les futurs usages
d’un texte Unicode
se restreignent
dès sa rédaction
priétés produit une représentation textuelle incomparablement plus simple,
claire et utile que le même texte codé en caractères Unicode.
Nous avons déjà évoqué le fait qu’Unicode contient une vingtaine de caractères d’espacement : espace cadratin, espace demi-cadratin, espace fine,
espace très fine, espace de chasse nulle, espace insécable, espace fine et insécable, et ainsi de suite. Certaines parmi ces espaces se distinguent par leur
chasse : ce sont des propriétés de présentation qui ne devraient a priori concerner Unicode, mais comme pour la plupart des propriétés présentationnelles,
on peut toujours argumenter en faveur de leur importance sémantique. La propriété de chasse nulle peut servir à des usages linguistiques afin de séparer,
par exemple, les « mots » (groupes de logogrammes) chinois sans introduire de
l’espacement visible, tout comme la propriété d’insécabilité qui peut interdire
une coupure de ligne entre deux mots français ou viêtnamiens.
Le problème est que, par la nature d’Unicode, l’introduction de chaque
nouvelle propriété doit forcément entraîner la création d’un ou de plusieurs
nouveaux caractères codés. Lorsque deux propriétés binaires sont combinées
(par exemple, normal-fin et sécable-insécable), quatre combinaisons sont possibles, ce qui est égal au nombre de caractères Unicode à créer. Si plus tard
on ajoute une troisième propriété binaire, le nombre de caractères Unicode
à introduire (en addition aux quatre existants, car Unicode refuse de modifier
les caractères déjà normalisés) s’élève à huit.
Un problème lié est que l’introduction d’un texte Unicode suppose la
connaissance a priori de ses usages futurs : si l’utilisateur prévoit un éventuel
formatage de bonne qualité de son texte en français ou en viêtnamien, alors
il a intérêt à employer le caractère espace insécable où celui-ci est approprié,
faute de quoi il risque d’obtenir une mise en page erronnée. Si par contre ce
même texte équipé d’espaces insécables est ensuite traité par un logiciel plus
simple (comme le bloc-notes de Windows) qui n’accède pas à la base de données d’Unicode et qui par conséquent n’est pas capable de reconnaître que
le caractère U+00A0 NO-BREAK SPACE et U+0020 SPACE sont, bien que différents, tous les deux des caractères d’espacement, alors certaines opérations
textuelles (comme la recherche) peuvent échouer à cause de l’information introduite en forme d’un caractère alternatif.
Dans le textème, les propriétés sont orthogonales entre elles : l’ajout d’une
124
nouvelle propriété n’affecte pas (ou pas toujours, voir plus tard) la valeur de
ses propriétés déjà présentes. Les propriétés signe d’espacement, insécable et L’orthogonalité
chasse fine peuvent donc être indiquées indépendamment. La phrase viêtna- des propriétés
de textème
mienne
Ông già d̄i nhanh quá.
peut être interprétée de deux manières : « ce vieux va très vite » et « tu vieillis
très vite », en fonction de l’association du morphème (le « mot ») già au morphème ông ou d̄i, respectivement. La coupure de lignes doit tenir compte de
ce fait afin d’éviter de suggérer un sens non voulu. Étant donné la difficulté
élevée de la gestion automatique des ambiguïtés linguistiques comme celleci, l’indication du sens voulu par la propriété insécable de l’espace est une
tâche effectuée typiquement par l’humain. Dans le modèle en textèmes, cette
indication peut être réalisée de la manière suivante :
Ô
n
g
letter = space
nobreak = true
g
i
à
letter = space
d̄
i
Il suffit donc d’ajouter une propriété nobreak = true à l’espace approprié.
Cette approche, meilleure que l’emploi de nombreux différents caractères
Unicode d’espacement pour les raisons évoquées ci-dessus, est de loin plus
compréhensible pour l’utilisateur non initié au fonctionnement d’Unicode et
à la modélisation textuelle informatique en général : au lieu de demander
l’emploi d’un caractère inhabituel qui ne se distingue pas visuellement d’un
espace ordinaire et dont très probablement l’utilisateur ignore l’existence, on
demande d’ajouter une précision à un élément textuel simple. Nous arrivons
ici à des considérations qui s’inscrivent dans le cadre de la problématique
de l’interface homme-machine que nous n’avons la possibilité d’aborder dans
cette thèse.
TEXTÈMES
BALISES
En section 1.8.8 nous nous sommes intéressés aux différences entre texte
brut et texte balisé. Nous avons trouvé que certains caractères Unicode
agissent exactement comme des balises et que même certains signes de ponctuation peuvent s’interpréter d’un point de vue fonctionnel comme telles. La
frontière entre texte brut et texte balisé est donc plus floue que l’on ne pourrait
penser.
En pratique, les balises d’un texte en caractères font partie intégrante du
texte dans le sens où elles-mêmes sont des chaînes de caractères qui s’imbriquent dans le texte sans interrompre son flux unidimensionnel. Les balises
se distinguent du « contenu » par l’emploi exclusif de certains caractères réservés.
Tout en gardant le même principe de balisage, nous proposons une représentation alternative des balises à l’aide de textèmes. Dans cette représentation, les balises ne sont pas de chaînes de signes spécialement interprétées
mais plutôt des textèmes individuels non-graphémiques ayant une fonction
spéciale « balise ». Il s’agit donc de textèmes qui ne réfèrent à aucun signe
d’écriture et qui ne correspondent à aucun caractère ni à aucun glyphe. De
125
ce fait, tout en faisant partie intégrante de la chaîne de textèmes, les textèmesbalises s’en distinguent par l’ensemble particulier de propriétés qu’ils portent.
Prenons par exemple un morceau de document HTML :
<p class="toto">Bonjour</p>
À l’aide des textèmes-balises, la même chaîne devient la suivante :
function = markup
element = p
tag = opening
class = toto
B
o
n
j
o
u
r
function = markup
element = p
tag = closing
L’intérêt pratique de cette approche est évidente : d’une part, on n’a
plus besoin de caractères réservés, de méthodes d’échappement ou d’entités. D’autre part, la lecture et l’interprétation du document balisé deviennent
beaucoup plus facile et rapide car le document est plus court et le repérage de
balises est une simple opération de recherche de propriété function = markup.
D’un point de vue théorique, le textème-balise est une réalisation plus fidèle
de l’essence de la balise : un élément atextuel qui fait néanmoins partie du
flot d’éléments textuels.
T YPOGRAPHIE
Techniques alternatives
d’égalisation des lignes
Paragraphes candidats
calculés en amont
DYNAMIQUE
La typographie dynamique est une nouvelle approche au problème de
l’égalisation des lignes des paragraphes, inventée par l’auteur et Yannis Haralambous et présentée en détail dans [14]. Ici, nous n’allons que résumer ses
principes fondamentaux.
L’égalisation des lignes de paragraphes par l’élongation des lettres ou par
l’activation-désactivation des ligatures est une technique traditionnellement
employée, entre autres, par la calligraphie et la typographie arabes [38] ou
hébraïques, ainsi que dans les Bibles de Gutenberg [67]. Les formats de fonte
intelligents tels qu’AAT ou OpenType sont en théorie capables de définir des
opérations similaires aux techniques que nous venons d’évoquer, cependant,
d’une part, les solutions offertes par ces formats sont suboptimales (l’optimisation des coupures se fait au niveau de la ligne et non pas au niveau du
paragraphe entier, les ligatures et les glyphes alternatifs sont appliqués a posteriori ; pour les détails cf. [14]), d’autre part, à la connaissance de l’auteur,
aucune application et virtuellement aucune fonte ne supportent aujourd’hui
ces techniques.
La typographie dynamique procède autrement : dans un premier temps,
en supposant que les ligatures (en leurs formes composées-décomposées), les
glyphes alternatifs et les césures éventuelles peuvent être librement combinés,
autant de paragraphes candidats16 sont générés qu’il existe de combinaisons.
(Comme mesure d’optimisation, le nombre de combinaisons peut être réduit
de manière radicale par la classification des ligatures et des glyphes alternatifs
en classes d’équivalence, par la relation d’équivalence « avoir les chasses du
même ordre ».)
16
« Candidats » dans le sens de « candidats à l’égalisation ».
126
Le modèle de texte en textèmes est une plate-forme idéale pour la représentation des paragraphes candidats grâce à la possibilité d’inclure plusieurs
glyphes candidats dans le même textème. Nous prenons comme exemple
le mot « affiné » en supposant qu’il fasse partie d’un paragraphe que nous
sommes en train de composer. Supposons également qu’initialement le mot
soit formé de caractères (le nom de propriété « caractère » a été abrégé par « c »
dans les textèmes) et que les points de césure potentiels (« af-finé » et « affi-né »)
aient été marqués par des propriétés hyph :
c = 61 (a)
c = 66 (f)
hyph = 1
c = 66 (f)
c = 69 (i)
hyph = 1
c = 6e (n)
c = e9 (é)
Après l’inclusion des glyphes candidats — ligatures, traits de césure et variantes stylistiques — le mot prend la forme suivante :
c = 61 (a)
font = lmr
g=a
c = 66 (f)
font = lmr
g=f
g2 = ffi
g3 = ff
font = lmr
g=g2 = ∅
c = 66 (f)
font = lmr
g=f
g2 = ∅
g3 = fi
c = 69 (i)
font = lmr
g=i
g2 = ∅
font = lmr
g=g2 = ∅
c = 6e (n)
font = lmr
g=n
c = e9 (é)
font = lmr
g=é
g2 =
où les glyphes candidats sont g, g2 et g3 , et de nouveaux textèmes correspondant aux traits de césure éventuels ont été insérés. Ces derniers n’ont pas de
propriété de caractère, ce qui est logique puisque le trait de césure ne fait pas
partie du contenu textuel. Bien évidemment, les glyphes candidats ne peuvent
pas être combinés en toute liberté : par exemple, il n’est pas possible de composer la ligature « ffi » du deuxième textème et ensuite le trait de césure du
troisième textème. La gestion de telles contraintes est un aspect important de
la typographie dynamique que nous présenterons en section 2.7.8, p. 164.
La solution que nous y proposons nous permettra en particulier d’éviter que
notre problème se réduise au problème général de satisfaisabilité, dont la NPcomplétude est bien connue.
L’étape suivante de la typographie dynamique comprend la construction Extension du graphe
d’une version étendue du graphe de paragraphage de Knuth et de Plass [43] de paragraphage
(voir fig. 2.8) dans lequel les lignes optimales sont calculées par la recherche
du chemin le plus court. L’extension consiste à scinder les arêtes correspondant aux lignes potentielles à chaque endroit où se trouve une ligature ou
un glyphe alternatif, et à pondérer les arêtes nouvellement insérées par les
chasses des (classes de) glyphes en question. Ceci permet d’optimiser le choix
de glyphes au niveau du paragraphe entier, contrairement aux solutions qui les
font intervenir a priori ou a posteriori. En réalité, cette étape est fortement optimisée (pas toutes les combinaisons légales de ligatures et de glyphes variantes
sont prises en compte) afin d’éviter l’explosion combinatoire du nombre de
lignes candidates. Finalement, une dernière étape de post-paragraphage peut
être exécutée, désormais en temps linéaire, pour peaufiner le choix de variantes et de ligatures.
127
FIG. 2.8 – L’extension d’une arête du graphe de paragraphage par les nœuds de
variante. À gauche, l’arête d’origine représente une ligne qui contient le mot
affiné au milieu. Les carrés noirs aux extrémités de l’arête correspondent aux
coupures faisables en début et en fin de ligne. À droite, l’arête a été étendue
par toutes les variantes du mot affiné. Les cercles sont les nœuds de variante.
2.5
LE RÔLE DU CONTEXTE
DANS LA REPRÉSENTATION TEXTUELLE
La notion de contexte est incontournable dans de nombreux problèmes,
qu’il s’agisse de logique, de traitement automatique de langues naturelles, de
représentation des connaissances, d’intelligence artificielle et ainsi de suite.
Quel que soit le domaine, l’appréhension et la description précise et formelle
de la notion de contextualité se sont souvent avérées difficiles, dû à la nature
très hétérogène des phénomènes que l’on a tendance à généraliser comme
La métaphore étant contextuels. La métaphore de la boîte [25] capture bien l’essence du
de la boîte raisonnement contextuel : on ne s’intéresse à un moment donné qu’à ce qui
se trouve à l’intérieur de la « boîte » qui représente une portion restreinte du
monde. Tout modèle doit forcément s’imposer des limites, au-delà desquelles
il n’est plus applicable, tout comme une description ne peut être que partielle,
un énoncé a toujours un début et une fin, et ainsi de suite. Les frontières
que l’on s’impose ainsi ne sont cependant pas infranchissables ; au contraire,
dans la grande majorité des cas, le modèle ne peut éviter de communiquer
avec son extérieur et l’énoncé s’interprète selon des circonstances qui lui sont
extrinsèques.
Modèle et contexte
Dans une logique de modélisation, notre compréhension du monde extérieur est souvent partielle, plus limitée que celle du fragment du monde modélisé : c’est justement la réalité pratique de ne jamais être capable de construire
des modèles omniscients et tout-englobants qui donne un vrai sens distinct à
la notion de contexte [25]. D’autre part, on est conscient de l’hétérogénéité et
de la complexité du monde extérieur, d’où l’intérêt de représenter le contexte
comme une entité typiquement multidimensionnelle.
Ces considérations s’appliquent naturellement aux opérations textuelles
(comme la typographie numérique) ; ceci a déjà été mis en évidence notamment par John Plaice qui a visionné un logiciel typographe sensible au
contexte à tous ses niveaux [54]. Dans le même article, le contexte est défini tout simplement comme un ensemble de couples attribut-valeur (chacun
correspondant à une dimension) où les contextes imbriqués sont permis (en
d’autres termes, une valeur peut à son tour être composée d’un ensemble de
couples, et cela de manière récursive).
De notre part, pour le moment nous adoptons une interprétation plus générale de la notion de contexte, sans pour autant viser à construire une théo128
rie unificatrice formelle et rigoureuse de ses aspects divergents. Néanmoins, Discussion théorique
nous allons voir que de nombreux phénomènes contextuels peuvent se dé- contre réalisation
crire à l’aide de notre cadre formel en strates, ce qui nous permettra au moins pratique
de « faire le ménage » parmi les diverses interprétations de cette notion, tout
en se posant la question sur la possibilité pratique de la conception et de la
réalisation d’un mécanisme unique qui serait capable de gérer la totalité des
problèmes contextuels.
2.5.1 L ES
DIFFÉRENTS ASPECTS CONTEXTUELS
DU TEXTE NUMÉRIQUE
Dû au principe du raisonnement local — que l’étendue du modèle (de
la boîte) est choisie en fonction de la tâche à accomplir —, le contenu du
contexte varie selon le niveau structurel sur lequel le texte est modélisé (niveau
de la propriété individuelle, de l’élément textuel, du « mot », de la ligne, du
paragraphe, etc.). Dans la suite, nous allons considérer quelques situations où
il semble utile et même intuitif de prendre en compte le contexte d’une unité
textuelle.
1. Depuis le début, nous avons choisi de limiter nos études aux proprié- Attributs de caractère
tés textuelles en-deçà de la frontière imposée par la fin de paragraphe. et de paragraphe
Il est donc naturel de considérer les propriétés concernant les unités dans la PAO
structurelles supérieures comme des propriétés contextuelles. D’ailleurs,
le même principe est appliqué implicitement dans de nombreux logiciels de PAO et de traitement de texte : on distingue entre attributs de
caractère et de paragraphe, les premiers étant des paramètres microtypographiques qui peuvent varier signe par signe (fonte, taille, crénage,
langue, etc.), et les derniers étant valables pour des paragraphes entiers
(alignement, interlignage, règles de césure, etc.). Au niveau des signes
individuels, les attributs de paragraphe peuvent être considérés comme
dimensions de contexte et, en tant que telles, peuvent influencer le traitement micro-typographique.
2. Certaines propriétés de texte comme la langue sont souvent considérées Propriétés associées
micro-typographiques car elles affectent le traitement typographique en aux chaînes de textèmes
s’associant à des unités textuelles plus petites que le paragraphe. L’unité
linguistique la plus courte caractérisable par la propriété de langue est
le morphème, qui peut être représenté en écrit par un seul textème (en
écriture chinoise) jusqu’à une suite de textèmes (en écritures latine, cyrillique, etc.). Il ne s’agit donc pas, ou pas toujours, d’une propriété de
signe — de textème — mais d’une propriété linguistique s’associant le
plus souvent à une chaîne de signes qui, par conséquent, se représente
en dehors de la « boîte » du textème.
3. L’illustration graphique que nous avons employé jusqu’ici pour la chaîne Relations entre textèmes
de textèmes est celle d’une séquence de boîtes, chaque boîte contenant adjacents
une liste de couples clé-valeur. La faiblesse de cette métaphore est peutêtre qu’elle suggère une indépendance mutuelle entre textèmes. Ceci
est loin d’être le cas, comme nous allons voir dans les sections 2.6.2
et 2.7 ; pour le moment il suffit de penser à l’opération de crénage entre
deux glyphes adjacents, aux ligatures, etc. Du point de vue d’un textème
129
Co-texte
individuel, les autres textèmes qui l’entourent (et qui ne se limitent pas
forcément aux deux textèmes adjacents) appartiennent à son contexte.
C’est à ce type de contexte que réfèrent les termes substitution et positionnement contextuelles du jargon employé dans les spécifications des
formats de fonte intelligents. Il faut noter que les linguistes ont inventé
un nouveau terme, le co-texte, pour distinguer le contexte textuel proprement dit (c’est-à-dire le texte qui précède et qui suit l’unité textuelle
de notre intérêt) du contexte extra-textuel.
Dépendance
4. Bien que les propriétés d’un textème soient a priori orthogonales (indépendantes), toute combinaison de propriété ne dénote pas forcément
de signe existant : par exemple, les deux propriétés {lettre = F, écriture = cyrillique} sont clairement contradictoires, puisque la lettre « F »
ne peut être que latine. On observe donc que ces deux propriétés sont,
en quelque sorte, corrélées. On retrouve le même phénomène entre propriétés se trouvant dans des textèmes différents : la propriété de crénage
d’un glyphe dépend également du glyphe précédent. Ce phénomène
de dépendance entre propriétés est la conséquence d’un ensemble de
contraintes extrinsèques — contextuelles — auxquelles le texte est soumis.
Contexte d’usage
5. Le contexte d’usage, que nous avons évoqué la première fois par rapport aux codages de caractères (p. 27) et dont nous avons donné une
première interprétation tentative à propros du texte brut (p. 77), est
une propriété que le modèle de texte caractère-glyphe intègre de façon controversée : d’une part, la séparation entre chaîne de caractères
et chaîne de glyphes est clairement faite selon l’usage (représentations
d’échange/finale), d’autre part, à part ces deux usages principaux, il
n’existe aucune autre manière standarde d’adapter le texte (la chaîne
de caractères ou la chaîne de glyphes) à un usage particulier. Le modèle
de textèmes est différent : l’usage s’y manifeste de manière explicite à
travers les catégories fonctionnelles de la strate T3 (cf. fig. 2.5 sur la
page 104), c’est-à-dire à travers les propriétés présentes dans les textèmes.
Nous avons vu que chacun de ces aspects contextuels peut être lié à un
type de problème particulier de modélisation textuelle. Malgré le fait que
nous les regroupons sous la catégorie d’« effets contextuels », ces phénomènes
n’ont pas forcément une source commune, et nous allons voir que même s’ils
peuvent être formellement décrits au sein de notre système en strates, ils ne
s’y représentent pas toujours de la même manière.
2.5.2 L E
CONTEXTE MACROSCOPIQUE
Dans une première approximation inspirée de considérations intuitives,
nous appellerons contexte macroscopique toute information s’associant à une
chaîne de textèmes au lieu d’être présent dans chaque textème en tant que propriété individuelle. Dans la section précédente, nous avons suivi la distinction
habituelle entre attributs de paragraphe qui décrivent le paragraphe en tant
qu’unité à part entière et attributs « de caractère » qui s’associent à des chaînes
130
d’unités textuelles de longueurs variables (mais inférieures à la longueur du
paragraphe).
Notre modèle de texte, tel que nous l’avons développé jusqu’ici, n’offre Rapport entre
aucun moyen direct de prendre en charge des propriétés textuelles de plus propriétés contextuelles
haut niveau. La question qui se pose à ce point est, les propriétés de tex- et pr. de textème
tème pourraient-elles utilisées à ces fins ? Serait-il judicieux, par exemple, de
représenter la propriété de langue d’un morceau de texte par cette même propriété insérée dans chacun de ses textèmes ? Il faut encore une fois séparer
les considérations théoriques et implémentationnelles. Il est évident qu’une
implémentation qui suive une telle approche à la lettre serait extrêmement
sous-optimale en termes d’espace de stockage utilisé, mais pour le moment
nous écartons ces considérations pratiques afin de nous concentrer sur les
problèmes de modélisation.
D’un point de vue sémantique, une telle représentation n’est pas forcément valide. Parler d’une propriété, disons, de langue d’un signe est légitime lorsqu’il s’agit d’un logogramme chinois jouant le rôle linguistique de
morphème, et nettement moins lorsqu’il s’agit d’une lettre latine. De même,
l’association d’un URI à une chaîne de texte à travers une propriété hyperlien n’est pas équivalent à l’association du même URI à chacun des signes
séparément. Par contre, lorsqu’une seule couleur est associée à l’intégralité
du texte d’un paragraphe, on peut très bien considérer que la même propriété
s’attache à chacun des signes individuels. La différence conceptuelle entre ces
trois exemples est que la propriété de couleur réalise une relation unaire, alors
que la langue, l’hyperlien ou par exemple la propriété de crénage mettent en
relation plusieurs textèmes. Lorsque l’on associe la propriété de langue française au mot « bon », ce ne sont pas les trois lettres individuelles qui possèdent
cette propriété mais leur relation, dans cet ordre précis. Il s’ensuit que notre
modèle — qui définit le texte comme une chaîne de textèmes et le textème
comme étant un ensemble de propriétés unaires — ne possède pas la puissance sémantique nécessaire pour exprimer des relations d’arités supérieures
à l’unité. Ces relations doivent donc être considérées comme contextuelles.
Néanmoins, du point de vue de l’interfaçage entre la chaîne de textèmes et Mouvement
son utilisateur — qu’il s’agisse d’un être humain ou d’une application —, il est de la propriété entre
tout à fait envisageable, et même souhaitable, que certaines propriétés contex- le contexte et le textème
tuelles macroscopiques soient accessibles comme s’il s’agissait de propriétés
de textème. D’autre part, lorsque tous les textèmes d’une chaîne partagent
une même propriété (par exemple, tous les signes ont la même couleur), il est
également souhaitable que celle-ci puisse être déplacée depuis les textèmes
individuels vers un « niveau contextuel » supérieur.
Les opérations de décontextualisation et de contextualisation (resp.) que Opérations
nous venons de décrire sont parmi les opérations de base du raisonnement équivalentes dans la RC
contextuel dans le cadre de l’intelligence artificielle : elles sont également
appelées pop et push [15] ou entering et leaving the context [46]. La décontextualisation peut également être considérée comme une forme d’héritage
entre le contexte et le textème.
131
FIG. 2.9 – Le contexte macroscopique se crée à partir de propriétés de chaînes
de signes. Le contexte tc(3) est un ensemble de couples clé-valeur, tout comme
le textème (t(3) ), et s’associe, dans T4 , à des chaînes de textèmes qui deviennent ainsi contextuelles.
REPRÉSENTATION
DU CONTEXTE MACROSCOPIQUE
DANS LE CADRE FORMEL À STRATES
Nous allons procéder à une tentative de formalisation du contexte macroscopique dans notre cadre de modélisation à strates : il s’agit d’y situer les
propriétés contextuelles, propriétés qui sont donc associées à des chaînes de
texte. Tout d’abord, nous avons besoin d’une représentation formelle de la
Chaîne de signes chaîne de signes ainsi que de la chaîne de textèmes.
et chaîne de textèmes
Comme nous avons pu voir (p. 96), la chaîne de signes est un élément
de la strate T0 , plus précisément un tuple n-aire de signes pour une chaîne
de longueur n. La chaîne de textèmes, également en tant que tuple n-aire,
doit se situer dans la strate directement supérieure à T3 (la strate des textèmes
individuels), c’est-à-dire dans T4 .
Par conséquent, nous avons le choix de situer les propriétés contextuelles
soit au niveau T1 , côte-à-côte avec les propriétés de textème, soit à un niveau T5 nouvellement introduit. La conséquence du premier choix est que le
contexe devient un élément de T3 , de manière analogue au textème (fig. 2.9),
alors que dans le dernier cas le contexte se construit sur la base de la chaîne
de textèmes et devient ainsi un élément de T7 (fig. 2.10).
132
FIG. 2.10 – Ici, le contexte ne se construit pas à travers la description de
chaînes de signes de T0 , plutôt, les propriétés contextuelles s’associent directement aux chaînes de textèmes.
133
Notre choix parmi les deux façons de représenter l’information — dont
l’une est proche du monde observé (T0 ) et l’autre se trouve dans les strates supérieures — témoigne de la vision fondamentale que l’on adopte lorsque l’on
modélise un phénomène, dans notre cas, la contextualité. En choisissant de situer les propriétés contextuelles dans T1 , on exprime le fait que celles-ci se dérivent de nos observations de « textes réels ». Ainsi, les propriétés contextuelles
deviennent en quelque sorte la généralisation de la propriété de textème : une
propriété de textème est une propriété contextuelle qui réfère à un seul signe.
Pour suivre la notation de la figure 2.9, t(3)i est un ensemble de couples clévaleur de propriétés de signes individuels, alors que tc(3)i est un ensemble
de couples clé-valeur de propriétés de chaînes de signes. En revanche, les
propriétés contextuelles de la strate T5 (fig. 2.10) s’associent directement aux
chaînes de textèmes, qui sont des entités du modèle et non des entités observées. Ce sont par conséquent des informations abstraites que nous, en tant que
concepteurs, ajoutons au modèle, sans pour autant que celles-ci soient forcément dérivées du « monde réel ». Philosophiquement parlant, on peut dire que
le contexte de T3 se dérive de nos observations représentées par les éléments
de T0 , ce qui relève d’une approche « de bas en haut » ou empiriste, alors
que le contexte représenté dans les strates supérieures de T5 , T6 et T7 exprime
des informations et des connaissances a priori existantes, ce qui relève d’une
approche « de haut en bas » ou idéaliste.
Il n’est bien évidemment pas question de devoir choisir à ce moment, de
manière exclusive, une approche parmi ces deux. Ce qui paraît plus pertinent
est de considérer le contexte de T3 comme constitué de propriétés en quelque
sorte « naturelles » du texte (e.g., langue), et le contexte de T7 comme propre
au modèle (e.g., règles de substitution contextuelles d’une fonte OpenType,
relations de dépendance entre textèmes adjacents).
D’ailleurs, l’idée selon laquelle les propriétés de textème sont généralisables vers les propriétés contextuelles nous permet de concevoir un modèle
de texte alternatif qui ne distingue plus entre ces deux : les propriétés « dans » et
« hors » de la boîte deviennent le même concept, car c’est la boîte même — le
textème — qui cesse d’exister. Une telle approche a des avantages et des inconvénients par rapport au modèle en textèmes (dont nous verrons quelques-uns
dans la section suivante). Ce modèle alternatif sera brièvement esquissé dans
le chapitre terminal de cette thèse.
2.6
LE CONTEXTE D’USAGE
Nous continuons la discussion des différents effets contextuels par le
contexte d’usage. Si la notion de contexte est très difficile à définir dans sa
généralité, il n’en est pas autrement pour celle d’usage, un concept vaste et
Ce que l’on entend général17 . Lorsque l’on parle d’usages textuels, on réfère très probablement
par usage à une gamme restreinte d’opérations qui visent certains aspects du texte. Selon cette interprétation, un usage particulier correspond à un sous-ensemble
parmi toutes les opérations textuelles possibles, ces opérations ne concernant
17
De ce point de vue, parler de « contexte d’usage » ne fait très probablement qu’empirer la
situation...
134
en général qu’un sous-ensemble de propriétés textuelles.
Remarquons que cette interprétation est cohérente avec celle anoncée en
page 77 en rapport avec notre définition du texte brut. Pour situer le contexte
d’usage dans notre cadre en strates, il suffit de considérer une opération textuelle comme une fonction texte 7→ texte, le texte étant considéré comme une
chaîne de textèmes. (Il est tout à fait possible que le contexte macroscopique
soit considéré comme faisant partie intégrante du texte.) Puisqu’une fonction
est une relation applicative et puisque la chaîne de textèmes est un élément
de la strate T4 , on arrive par conséquent à situer l’usage (un ensemble de
fonctions) au sein de la strate T6 .
Une fonction textuelle ne s’intéressera en général pas à l’intégralité des
propriétés au sein des textèmes. À chaque fonction f de l’usage U (f ∈ ext(U ))
correspond donc un ensemble de clés de propriété. Par exemple, une fonction de crénage — qui calcule un déplacement horizontal pour un couple
de glyphes identifiés par leurs indices respectives venant d’une fonte donnée
— a comme catégorie fonctionnelle correspondante l’ensemble {fonte, indice
de glyphe, dx}. L’union des ensembles de clés forme une catégorie de clés
(élément de T3 ) qui peut être considérée comme une catégorie fonctionnelle.
En redescendant dans l’hiérarchie des strates, on observe que l’extension
de la catégorie fonctionnelle correspondant à l’usage « découpe » dans T2 un
sous-ensemble de clés de propriété, dont l’extension est un sous-ensemble de
propriétés dans T1 , et enfin un sous-ensemble de signes dans T0 (fig. 2.11).
Il faut noter que lorsque nous parlons de l’extension d’un ensemble de
relations, nous comprenons ici par cela l’union des extensions des relations
individuelles :
ext({t(3)1 , t(3)2 , ..., t(3)n) }) = ext(t(3)1 ) ∪ ext(t(3)2 ) ∪ ... ∪ ext(t(3)n )
Un contexte d’usage permet donc d’adopter un point de vue, une vision
sélective du texte en textèmes : il filtre les propriétés y présentes, ainsi réduisant la description des signes individuels à leurs propriétés pertinentes
dans le contexte d’usage. Les clés pertinentes dans un contexte d’usage
{t(3),1 , ..., t(3),n } sont les éléments de ext({t(3),1 , ..., t(3),n }), les propriétés pertinentes sont les éléments de ext(ext({t(3),1 , ..., t(3),n })), et les signes pertinents
sont ext(ext(ext({t(3),1 , ..., t(3),n }))).
Pour exprimer de manière plus formelle ce que nous entendons par le
filtrage d’un textème ou d’un texte, nous proposons la définition suivante.
DÉFINITION 11 (FILTRAGE
DE TEXTÈME SELON UN CONTEXTE D’USAGE)
Soit t(3) un textème avec n propriétés :
t(3) =
n n
[
i=1
o
(tcléi (2) , tvaleuri (1) )
Soit I l’ensemble de clés présentes dans le textème :
I=
n n
[
tcléi (2)
i=1
135
o
Le contexte d’usage
au sein du cadre
en strates
Usage et catégorie
fonctionnelle
FIG. 2.11 – La catégorie fonctionnelle correspondant au contexte d’usage de
cet exemple est la catégorie « graphique ». L’extension de celle-ci comprend
les clés de propriété pertinentes dans ce contexte, et ainsi de suite, jusqu’au
niveau T0 . Dans ce contexte d’usage particulier, les signes ne sont discernables
que par quatre propriétés (rouge, noire, maigre, x-gras).
Soit U un contexte d’usage avec la catégorie fonctionnelle UCF . Le filtrage
du textème t(3) selon le contexte d’usage U est la restriction du textème au
domaine UCF ∩I. (Nous considérons ici le textème comme une relation binaire
entre clés et valeurs dans cet ordre.) Le textème filtré t̂(3) peut également
s’exprimer ainsi :
n
o
[
(tcléj (2) , tvaleurj (1) )
t̂(3) =
∀tcléj (2) ∈I∩UCF
Par exemple, les textèmes de la première ligne de la figure 2.12, p. 138
peuvent être considérés comme le résultat obtenu après un filtrage des textèmes correspondants en seconde ligne selon un contexte d’usage dont la caFiltrage d’un texte tégorie fonctionnelle est UCF = {letter, case, hyph}. On peut ainsi parler du
filtrage d’un texte : il s’agit du filtrage de chacun de ses textèmes individuels.
Filtrage du contexte Remarquons cependant que l’on peut permettre à la catégorie fonctionnelle
d’inclure non seulement des clés de propriété de textème (dont les valeurs
sont des relations unaires) mais également des clés de propriété contextuelles
136
(dont les valeurs sont des relations d’arités supérieures) lorsque celles-ci sont
considérées comme en fig. 2.9 (p. 132). Ainsi, le filtrage d’un texte selon un
contexte d’usage est capable de filtrer les deux types de propriétés en même
temps.
2.6.1 L E
CHANGEMENT DE CONTEXTE D ’ USAGE
Un exemple de changement d’usage textuel auquel nous nous sommes
particulièrement intéressés arrive lors de l’opération de formatage. Dans le
modèle caractère-glyphe, celle-ci consiste, entre autres, à passer de la représentation d’échange en caractères à la représentation finale en glyphes. Le
passage dans le sens inverse, des glyphes aux caractères, est également une
opération très fréquente. Nous avons déjà présenté dans les grandes lignes la
différence principale à cet égard entre le modèle de texte caractère-glyphe et
le modèle en textèmes : dans ce dernier, le changement s’effectue à l’intérieur
des textèmes.
L’ajout et la suppression de propriétés font partie des opérations élémentaires sur une chaîne de textèmes. La première, opération additive, peut être
interprétée comme une restriction de la classe de signes représentés par le
textème en question, alors que la dernière, opération soustractive, comme
l’élargissement de la même classe. L’opération de formatage comprend un
changement d’usage vers une catégorie de propriétés graphiques. Si l’on voulait simuler le passage de la chaîne de caractères à la chaîne de glyphes à
l’aide d’une chaîne de textèmes, ceci pourrait se faire d’abord par le calcul et
l’ajout des propriétés correspondant à la catégorie « glyphe », puis par la suppression (par filtrage) des propriétés correspondant à la catégorie « caractère »,
à l’exception des propriétés communes aux deux ensembles, s’il en existe.
Cependant, cette dernière opération de suppression irait à l’encontre de l’idée
fondamentale de notre modèle qui permet et encourage même l’accumulation
de propriétés de différents usages au sein des textèmes. On a d’autant plus
d’intérêt à garder dans les textèmes les propriétés correspondant à plusieurs
usages qu’on facilite ainsi le retour aux usages précédents ; en revanche, dans
le modèle caractère-glyphe le retour aux caractères est une opération souvent
difficile.
Dans le modèle de texte en textèmes, nous considérons donc le formatage
comme un enrichissement des textèmes par l’ajout de propriétés graphiques
(voir figure 2.12). Et puisque la fonction de formatage est une fonction additive,
aucune information du texte d’origine n’est perdue lors de son application.
Autrement dit, dans le contexte d’un usage non concerné par la présentation
du texte (par exemple, la recherche d’un mot), le texte reste équivalent à son
état d’avant le formatage puisque les propriétés correspondant à cet usage
n’ont pas changé. (Dans l’exemple de la figure 2.12 il s’agit des propriétés
letter, case et hyph.)
Prenons maintenant l’exemple d’un usage textuel courant, le copier-coller,
sur un document formaté de type PDF. Le format PDF adopte le modèle de
texte caractère-glyphe : comme déjà présenté en section 1.7.3, un texte PDF
est un texte en glyphes auquel le texte équivalent en caractères, en partie ou
dans son intégralité, peut éventuellement être associé. Cette association peut
137
Le formatage relève
de changement d’usage
Ajout et suppression
de propriétés
Formatage =
enrichissement
des textèmes
Copier-coller à partir
du PDF
letter = s
case = upper
letter = s
case = upper
font = Times
size = 10pt
glyphID = 20
dx = 0
dy = 0
letter = a
case = lower
hyph = yes
letter = l
case = lower
letter = u
case = lower
letter = a
case = lower
hyph = yes
font = Times
size = 10pt
glyphID = 28
dx = 8.8pt
dy = 0
letter = l
case = lower
font = Times
size = 10pt
glyphID = 38
dx = 8pt
dy = 0
letter = u
case = lower
font = Times
size = 10pt
glyphID = 47
dx = 5.6pt
dy = 0
letter = t
case = lower
letter = t
case = lower
font = Times
size = 10pt
glyphID = 46
dx = 8pt
dy = 0
FIG. 2.12 – Dans cet exemple hypothétique, le texte non-formaté est décrit
par trois propriétés seulement : lettre, casse et point de césure potentiel. Après
formatage, les textèmes ont été enrichis par des propriétés visuelles : fonte,
corps, identifiant de glyphe, déplacements horizontal et vertical du glyphe
par rapport au glyphe précédent. Le formatage consiste donc à enrichir les
textèmes avec de nouvelles propriétés dans le cadre du même modèle de
texte.
se faire au niveau des glyphes individuels mais en théorie également à un
niveau plus haut (séquences de glyphes, mots, etc.). Lors de la sélection et la
copie d’un morceau de texte dans le presse-papiers, une conversion glyphescaractères est effectuée par le logiciel Adobe Acrobat. Cette conversion est
triviale si les associations glyphe-caractère sont explicitement définies dans
le document PDF ; le cas échéant, Acrobat tente de déduire les caractères à
partir des noms de glyphes. C’est donc toujours le texte en caractères Unicode
— la représentation d’échange — et non le texte en glyphes qui sera copié.
Acrobat dépose également dans le presse-papiers une version formatée du
texte copié, en format RTF : il s’agit, rappelons-nous, d’un format en caractères
où les informations présentationnelles sont représentées par des balises. Le
principe du presse-papiers est donc que le logiciel de source y dépose le texte
dans autant de formats qu’il y a d’usages prévus, et les logiciels de destination
— chacun représentant un usage particulier — choisissent le format qui leur
convient le mieux.
Copier-coller
L’opération de copier-coller s’effectue de manière différente lorsqu’il s’agit
d’un document de texte en textèmes (pourvu bien sûr qu’aussi bien le logiciel de source que
en textèmes celui de destination soit compatible avec ce modèle). Transférer du texte à
partir d’une application vers une autre relève d’un changement de contexte
d’usage. Puisque le logiciel de source ne connaît a priori pas l’usage que
subira le texte copié, il dépose dans le presse-papiers des textèmes dans la
forme la plus riche (avec le plus de propriétés que possible) dont il dispose.
Le logiciel de destination, à son tour, ne s’en intéressera qu’aux propriétés qui
correspondent aux usages qui le concernent ; par conséquent, lors du coller,
un filtrage est effectué sur le texte selon l’usage en question, éventuellement
combinée avec la suppression effective des propriétés non concernées.
138
2.6.2 CHANGEMENTS D’UNITÉ PERTINENTE
Il faut admettre que la simplicité et l’élégance que nous avons revendiquées pour notre modèle à propos des changements d’usage se doit en partie à nos exemples choisis intentionnellement de manière à retarder jusqu’ici
l’examen de certains aspects plus complexes du modèle. Ainsi, nous n’avons
pas encore examiné en détail comment notre modèle gère les situations qui
se traduisent dans le modèle caractère-glyphe par une correspondance un-àmultiple, multiple-à-un ou multiple-à-multiple entre caractères et glyphes. Ces
cas sont pourtant fréquents :
– ligatures (correspondance multiple-à-un) ;
– lettres accentuées (un-à-multiple, multiple-à-un ou multiple-à-multiple) ;
– décomposition graphique du signe en traits ou en composants de plus
bas niveau (un-à-multiple) ;
– réordonnancement des glyphes par rapport aux caractères.
En même temps, le fait que notre modèle se fixe l’objectif de servir un Le choix de l’unité
grand nombre d’usages divers, à l’aide de la même chaîne textuelle, pré- pertinente est fonction
suppose le choix a priori des unités pertinentes de chaque écriture, de sorte de l’usage
que celles-ci correspondent aux textèmes individuels. Cependant, puisque ce
choix d’unité pertinente se fait forcément en fonction d’un ou de plusieurs
usages donnés, il est possible qu’il ne soit pas approprié à certains autres
usages — les exemples cités ci-dessus en sont les témoins. De ce point de vue,
la structure bicamérale du modèle caractère-glyphe s’adapte plus facilement à
de telles situations, à condition que l’on ne sorte pas du cadre circonscrit par
les deux usages « typographique » (pour la représentation finale) et « généraliste » (pour la représentation d’échange).
Dans notre modèle, le textème est la forme unique de l’unité textuelle,
et en tant que telle, il s’aligne inévitablement avec une division particulière
de l’écriture donnée ; en d’autres termes, il présuppose la préférence d’un
usage particulier à d’autres à travers la bijection entre l’unité que représente
le textème et l’unité pertinente correspondant à cet usage. Vu d’un angle implémentationnel, cela signifie que les correspondances de type m-à-n entre
les unités pertinentes de deux usages peuvent se résoudre essentiellement
de deux manières : par l’inclusion de plusieurs éléments textuels au sein du
même textème ou par la répartition de l’information parmi plusieurs textèmes
(voir fig. 2.13). Strictement parlant, aucun de ces deux types de solutions n’est
conforme à notre modèle initial qui suppose que chaque propriété d’un textème décrit le même élément textuel. De quelque sorte, les solutions que
nous allons présenter doivent être considérés comme différentes extensions
de notre modèle, chacune ayant ses propres avantages et inconvénients pratiques et dont l’approche à choisir doit être décidée cas par cas.
PLUSIEURS
ÉLÉMENTS TEXTUELS DANS LE MÊME TEXTÈME
Nous avons déjà montré des exemples où un textème regroupait plusieurs
éléments textuels, en particulier dans le cas des écritures logographiques et du
hangûl. Lorsque le logogramme chinois ou la syllabe coréenne sont choisis
comme unités pertinentes correspondant au textème — ce qui est un choix
intuitif — alors leurs composants de plus bas niveau doivent se représenter
139
FIG. 2.13 – Lorsqu’il existe une correspondance m-à-n entre unités textuelles
pertinentes de deux usages, la modélisation en textèmes s’aligne inévitablement à l’une des deux suites de signes.
comme propriétés de ceux-ci. Une situation similaire est envisageable pour la
modélisation graphique de l’écriture arabe :
– si les points et les lettres de base sont représentés par des glyphes séparés ;
– ou alternativement, si les lettres de base sont elles-mêmes assemblées à
partir de traits élémentaires.
Textèmes imbriqués
Étant donné que chacun des composants (glyphes, caractères, etc.) contenus dans le même textème possède un nombre de propriétés (par exemple,
un trait élémentaire peut avoir sa propre position, couleur, taille, etc.), il est
inévitable de considérer chaque composant comme un textème à part entier,
imbriqué dans le textème de niveau supérieur, un fait auquel nous avons déjà
fait allusion par la figure 2.6 (p. 118). Notre modèle théorique n’a pas prévu
cette éventualité. D’autre part, d’un point de vue d’implémentation informatique, rien n’empêche l’organisation des propriétés dans un arbre à deux ou
à plusieurs niveaux, où la valeur de propriété héberge des sous-propriétés18 .
Difficultés pratiques Cependant, du point de vue de certains usages le texte contenant de telles
propriétés imbriquées cesse d’être — du moins en pratique — une chaîne
unidimensionnelle car il devient nécessaire de « descendre » dans les arbres
de propriétés des textèmes afin de parcourir les sous-chaînes. On peut donc
conclure que généralement l’inclusion de multiples éléments textuels au sein
des textèmes rend le modèle plus complexe, en théorie et en pratique.
RÉPARTITION
DES PROPRIÉTÉS ENTRE TEXTÈMES
ET TEXTÈMES « VIRTUELS »
Une approche alternative au problème précédent est l’introduction de
nouveaux textèmes dans la chaîne dans le but de suivre un principe de simplicité de n’avoir qu’un seul élément textuel par textème. Les deux exemples
suivants illustrent deux solutions légèrement différentes :
script = latin
letter = é
glyph = e
script = latin
glyph = ´
18
Si nécessaire, l’arbre peut même être aplati à travers un nommage pertinent des clés de
propriété, mais ceci n’est qu’une astuce implémentationnelle qui ne modifie pas réellement la
structure logique à l’intérieur du textème, qui reste arborescente.
140
script = korean
unicode = U+AC10
glyph =
script = korean
onset =
lat_equiv = k
script = korean
peak =
lat_equiv = a
script = korean
coda =
lat_equiv = m
Dans la première ligne il s’agit d’une lettre « é » dont le glyphe est assemblé à partir de deux composants, notamment le glyphe de base et le glyphe
d’accent (nous avons omis ici les diverses propriétés de fonte et de positionnement). Le glyphe de base est inclus dans le textème d’origine contenant la
lettre « é » alors que l’accent est inclus dans un textème inséré dans l’unique
but de contenir celui-ci. Il faut avouer que du point de vue de notre modèle
théorique, cette solution n’a pas de sens : différentes propriétés du premier
textème réfèrent à différents signes (une lettre « é » et un glyphe « e »).
Dans la seconde ligne, aucune information concernant les composants alphabétiques de la syllabe coréenne n’est incluse dans le textème d’origine :
plutôt, chacun des trois composants reçoit son textème dédié. Cette solution
est plus « propre » vis-à-vis de notre modèle car elle garde la cohérence à l’intérieur des textèmes. En réalité, la cohérence intra-textémique est assurée au détriment de la cohérence inter-textémique car on observe quatre éléments textuels se succéder alors que logiquement les trois derniers sont subordonnés au
premier. Nous avons donc déplacé la complexité du niveau intra-textémique
au niveau inter-textémique.
En reprenant l’exemple de la lettre « é », que se passe-t-il lorsque le texte
formaté est soumis à un usage qui n’est concerné que par la propriété lettre
des textèmes ? Après un filtrage effectuée sur la chaîne précédente on obtient
le résultat suivant :
letter = é
Le textème introduit lors du formatage devient pour le nouvel usage un textème vide. En tant que tel, il devra forcément être considéré comme une « boîte Textème vide
noire » du point de vue du nouvel usage qui ne sait interpréter que les propriétés qui ont participé au filtrage. C’est un artefact gênant au milieu de la
chaîne que l’usage en question ne peut qu’éviter. Alternativement, le changement d’usage peut entraîner non pas le filtrage du texte par l’acte d’« ignorer » le reste des propriétés mais plutôt leur suppression. Ainsi on perd les
informations ajoutées lors des usages précédents mais en même temps on se
débarrasse des textèmes vides qui peuvent également être supprimés automatiquement. Ce processus s’apparente à la normalisation des arbres XML où les
nœuds textuels vides sont supprimés. On a considéré cette particularité des
nœuds textuels XML comme une faiblesse du modèle.
Un deuxième problème concernant l’insertion de nouveaux textèmes, lié Textèmes liés
au premier, est la relation qui se met en place implicitement entre le nouveau textème et son « parent ». Comme nous avons pu voir, les trois textèmes
alphabétiques n’existent pas indépendamment de la syllabe coréenne qu’ils
suivent ; bien au contraire, ils décrivent le même signe de manière différente.
Si, par exemple, la syllabe en question est supprimée du texte, les textèmes alphabétiques doivent également être supprimés. Pour reprendre la métaphore
de la boîte introduite à propos du phénomène de la contextualité (p. 128),
141
par la répartition des propriétés liées aux composants du même signe et/ou la
création de nouveaux textèmes, nous avons contextualisé la complexité en la
déplaçant depuis l’intérieur de la boîte du textème à l’extérieur, qui se manifestent désormais à travers des « liens invisibles » connectant les textèmes.
Ces liens restent invisibles jusqu’au moment où un mécanisme d’indication et de gestion des relations entre textèmes ne se met en place. Sans aucune doute, un tel mécanisme serait décrit par des relations se situant dans
les strates T4 à T7 dans notre cadre de modélisaton, en forme de propriétés
contextuelles qui réfèrent à des chaînes de textèmes (voir fig. 2.10, p. 133).
Nous reviendrons prochainement à cette idée dans la section 2.7 qui porte sur
la notion de dépendance.
LIGATURES
Nos deux chaînes de textèmes précédentes illustrent l’association de plusieurs glyphes ou composants à un seul signe. Le cas contraire est peut-être
encore plus fréquent : la ligature, entre autres, est par définition un glyphe
unique qui représente plusieurs signes d’écriture graphiquement liés. Ainsi,
le mot « affiné » est composé de six lettres mais seulement de quatre glyphes,
dans le cas où la fonte employée contient un glyphe « ffi ». Encore une fois, la
correspondance multiple-à-un peut être représentée de plusieurs manières :
script = latin
letter_1 = f
letter_2 = f
letter_3 = i
glyph = ffi
Cette solution suppose que l’unité pertinente choisie pour le texte est le
glyphe : les trois textèmes initials correspondant aux trois lettres sont remplacés par un seul textème de ligature. Cette solution recourt à la référence
vers plusieurs signes dans le même textème, ce qui entraîne encore une fois
le besoin d’imbriquer des textèmes (ceci n’est pas mis en évidence par notre
exemple). De plus, elle favorise un choix d’unité pertinente dont l’utilité se
limite à un contexte d’usage présentationnel.
script = latin
letter = f
glyph = ffi
script = latin
letter = f
script = latin
letter = i
Ici, on laisse intacte la chaîne de textèmes lors du formatage, ce qui est souhaitable du point de vue de la généralité de la représentation. En revanche,
elle est « impropre » d’un point de vue de modélisation car son premier textème réfère à plusieurs signes à la fois : une fausse relation sémantique est
établie entre la lettre « f » et le glyphe « ffi ». En effet, examiné séparément,
le premier textème, dû à ses propriétés contradictoires, ne représente aucun
signe réel.
script = latin
letter = f
script = latin
letter = f
script = latin
letter = i
142
script = latin
glyph = ffi
Cette troisième solution arrive à garder la propreté sémantique et la simplicité des textèmes individuels, tout en restant cohérente avec le modèle théorique ; par contre, elle ne laisse pas intacte la chaîne : aussi bien un filtrage
linguistique qu’un filtrage typographique de la chaîne crée des textèmes « virtuels » dans le sens où ceux-ci ne pourront être identifiés en tant qu’éléments
textuels « classiques » (lettres, caractères, signes typographiques, glyphes, etc.).
De plus, tout comme dans l’exemple précédent, des relations implicites intertextémiques se mettent en place.
RÉORDONNANCEMENT
Le phénomène de réordonnancement de glyphes, fréquemment mentionné à propos des écritures d’origine brahmique, n’est, en réalité, pas inhérent à ces écritures mais plutôt une conséquence de l’application de la modélisation typographique à celles-ci. Plus précisément, ce sont la méthode typographique de l’alignement linéaire des caractères mobiles combinée avec une
définition phonétique (et non syllabique) des signes élémentaires qui font que
la disposition spéciale de certains signes typographiques exigée par l’écriture
nécessite une opération de réordonnancement de glyphes lors du formatage.
Si, en revanche, on imaginait un modèle typographique capable de définir
des déplacements en contresens du sens de l’écriture ou, alternativement, un
découpage syllabique et non phonétique, alors le réordonnancement ne serait
plus nécessaire.
En se basant sur l’exemple du dévanagari, Richard Sproat [58, p. 46]
conclut que la Small Linguistic Unit (l’unité pertinente linguistique) de cette
écriture est la syllabe orthographique (c’est-à-dire le cluster consonantique et
la voyelle) car les réordonnancements (les changements de la direction de
concaténation) se limitent à l’intérieur de telles syllabes. Le cas est analogue
à celui de l’écriture coréenne où la composition bidimensionnelle se limite à
l’intérieur de la syllabe. En page 119 nous avons déjà présenté une méthode
d’application du modèle de textème à l’écriture hangûl. Inspirés par cette méthode, nous pouvons prendre la syllabe comme unité pertinente correspondant au textème. Celui-ci contiendra, par conséquent, la liste de graphèmes
(qui correspondent aux caractères Unicode) et la liste de glyphes de la syllabe :
grapheme_1 =
grapheme_2 =
grapheme_3 =
grapheme_4 =
glyph_1 =
glyph_2 =
glyph_3 =
(ra)
(reph)
(ta)
(i)
Avec cette solution, nous n’avons pas évité le réordonnancement des
glyphes par rapport aux graphèmes, mais nous avons restreint l’opération à
l’intérieur du textème. L’avantage de cette approche est que la succession des
textèmes suit l’ordre phonétique, inchangé à travers les changements d’usage.
Son inconvénient est que les correspondances graphème-glyphe ne sont plus
assurées au niveau intra-syllabique, à moins que celles-ci ne soient explicitement indiquées à l’aide de propriétés spéciales.
143
Le besoin
de réordonner
est fonction de notre
choix de modèle
La solution alternative consiste à insérer de nouveaux textèmes dans la
chaîne lors du formatage (nous avons abrégé « graphème » par « gr ») :
gr =
Liaisons entre textèmes
(ra)
gr =
(reph)
gr = (ta)
glyph =
glyph =
glyph =
gr =
(i)
Cette chaîne comporte des textèmes sans graphème et des textèmes sans
glyphe ; par conséquent, son filtrage par rapport à un contexte d’usage spécifique donnera des textèmes vides. De plus, les correspondances entre graphèmes et textèmes, à l’exception de la consonne , ne sont pas indiquées
explicitement. Ici encore, on doit considérer que ces textèmes sont « reliés »
les uns aux autres car la modification du textème se référant au graphème
entraîne forcément la modification du textème du glyphe correspondant. Ces
relations devraient être préservées et prises en compte même si dans le cadre
d’un usage particulier certains textèmes paraissent vides.
Notons enfin que dans l’exemple qui intègre la syllabe entière au sein du
même textème, les mêmes relations sont présentes, cette fois-ci en forme intratextémique.
2.6.3 CONCLUSIONS
La conclusion à tirer de nos exemples précédents est que, paradoxalement, l’auto-adaptation aux différents usages est à la fois un point fort et un
point faible du modèle en textèmes. D’une part, l’usage se reflète par les propriétés présentes dans les textèmes, librement modifiables. D’autre part, la
considération du texte en tant que simple chaîne unidimensionnelle de textèmes auto-contenants apporte une certaine rigidité au modèle car elle impose une division a priori de l’écriture en unités pertinentes du point de vue
d’un usage particulier. Lorsque la chaîne de textèmes se prête à deux usages
qui ne partagent pas la même unité pertinente, alors le modèle se complexifie
inévitablement. La complexification se manifeste soit à travers une structure
arborescente de propriétés au sein du textème (lorsque pluiseurs signes y sont
décrits), soit à travers l’apparition de « liens » ou de « dépendances » entre textèmes, relations dont la représentation explicite n’est encore une fois pas prévue par notre modèle. Le changement d’usage peut également introduire de
nouveaux textèmes dans la chaîne dont l’existence est justifiée uniquement
par ce nouvel usage, et qui devient textème vide suivant le filtrage du texte
dans le but d’éliminer les propriétés liées à cet usage.
La source de ces problèmes semble donc être la rigidité de la « boîte » qui
entoure les propriétés : le textème. Le modèle simple consistant en une succession de boîtes isolées, chacun d’elles contenant un simple ensemble de
couples clé-valeur, doit désormais céder sa place à un modèle plus complexe
avec des propriétés en arborescence et avec des textèmes qui dépendent les
uns des autres. Dans la section suivante nous souhaitons donner des éclaircissements sur ce que nous entendons par la complexité du modèle. Nous
allons découvrir que la problématique des correspondances m-à-n est généralisable à travers la notion de dépendance. Il s’agit de nouveau d’une forme de
contextualité, qui est de plus la cause principale et inévitable de nombreuses
difficultés liées à la modélisation de texte.
144
Une question qui se pose à ce point est, cette complexification du problème ne pourrait-elle pas être évitée en remplaçant le textème par une unité
textuelle plus souple qui s’adapte plus facilement au phénomène de changement d’unité pertinente ? En effet, de tels modèles sont envisageables, même
si au détriment de l’allure simple et intuitive qui est propre au textème. On
reviendra à cette possibilité dans le chapitre terminal de la thèse.
2.7 DÉPENDANCES AU SEIN DU TEXTE EN TEXTÈMES
En traitant de la problématique des correspondances m-à-n au sein de
la chaîne de textèmes, introduites par un changement d’usage, nous avons
constaté le besoin de prendre en compte certains types de relations qui se
créent entre textèmes. Les exemples tels que la ligature « ffi » nous ont montré
que les textèmes d’une chaîne ne se succèdent pas toujours en indépendance ;
en d’autres termes, la modification, l’insertion ou la suppression d’un textème
peut entraîner le besoin de modifier, supprimer ou insérer d’autres textèmes
existants afin de maintenir la cohérence des données. Ce sont ces phénomènes de dépendance entre propriétés du même textème, de deux textèmes
adjacents ou même de textèmes plus éloignés que nous allons examiner.
Les dépendances et la cohérence de données sont des problèmes classiques et récurrents de la représentation des connaissances. Dans la théorie
des bases de données, on les appelle dépendances fonctionnelles et on les
prend en compte lors de la conception des modèles de données. Dans la modélisation objet, le principe d’encapsulation et les méthodes servent à assurer
la cohérence des données membres. Dans les systèmes tels que RDF ou OWL,
des règles de logique de description décrivent les catégories, les relations et
les contraintes imposées aux données.
Avant même de mettre en valeur l’importance de la notion de dépendance
entre éléments textuels et d’expliquer ses conséquences pratiques sur l’usage
et l’implémentation du modèle de texte en textèmes, nous allons commencer
par l’examen de quelques exemples précis afin d’avoir une idée plus claire
sur la nature et le fonctionnement des dépendances dans un contexte textuel.
Ceci nous permettra ensuite de formaliser et de généraliser le problème ainsi
que de comprendre son importance dans les usages textuels algorithmiques et
interactifs.
2.7.1 Q UELQUES EXEMPLES DE
DÉPENDANCES
Reprenons l’exemple de la ligature « ffi » et examinons-le de plus près :
script = latin
lang = fr
letter = f
font = Times
glyph = ffi
script = latin
lang = fr
letter = f
font = Times
script = latin
lang = fr
letter = i
font = Times
La présence du glyphe de ligature « ffi » dans le premier textème est, bien
entendu, la conséquence des trois lettres « f », « f » et « i » successives. La suppression ou la modification de ces trois propriétés, ou encore l’insertion d’un
145
Ligatures
et dépendances
nouveau textème entre les trois briserait la ligature et rendrait invalide la propriété glyph. On observe donc qu’il existe une dépendance entre la propriété
glyph et les trois propriétés letter. Cependant, la composition de la ligature
« ffi » dépend non seulement de la présence de la chaîne de trois lettres mais
aussi d’autres conditions, parfois non représentées explicitement dans le texte :
– que la langue courante soit le français et non le turc (puisque ce dernier
ne permet pas la composition de ligatures de type « fi », dû au fait qu’en
turc les lettres « i » avec et sans point sont des graphèmes distincts) ;
– que les trois lettres soient composées en la même fonte, Times ;
– que cette même fonte contienne un glyphe de ligature « ffi ».
Dépendances entre
L’existence de telles dépendances n’est pas restreinte aux textèmes adjatextèmes non-adjacents cents : imaginons le cas hypothétique19 où une diacritique, telle qu’un accent
circonflexe, est ajoutée au premier « f ». Si cette diacritique est représentée par
un textème à part, alors la chaîne devient
script = latin
lang = fr
letter = f
font = Times
glyph = ffi
script = latin
lang = fr
letter = ˆ
font = Times
glyph = ˆ
script = latin
lang = fr
letter = f
font = Times
script = latin
lang = fr
letter = i
font = Times
où l’intercalation de l’accent ne devrait pas empêcher la composition de la
ligature (pourvu que le logiciel de formatage soit capable de gérer les ligatures
accentuées).
Crénage
Ces exemples laissent comprendre que l’existence de dépendances entre
valeurs de propriété est un phénomène courant. L’exemple suivant à propos
du crénage renforce la même observation :
lang = fr
letter = d
font = Times
glyph = d
lang = fr
letter = o
font = Times
glyph = o
lang = fr
letter = r
font = Times
glyph = r
lang = fr
letter = é
font = Times
glyph = é
kern = −0.05em
La propriété de crénage a été insérée dans le textème de la lettre « é » afin
de faire rapprocher son glyphe à celui de la lettre précédente. La condition
de présence de cette propriété est, bien évidemment, que les deux glyphes
soient adjacents. Plus précisément : que les deux glyphes viennent de la même
fonte Times et que le glyphe « é » succède directement au glyphe « r ». La
propriété glyph, à son tour, est sans doute dépendante des propriétés letter
et font ensemble, car c’est en connaissant le code de caractère (qui se déduit,
supposons, de la propriété letter) et la fonte que l’identifiant de glyphe est
calculé.
Notation
Bien que nous soyions encore redevables d’une définition formelle de la
notion de dépendance, pour des raisons pratiques il nous est utile d’introduire
dès maintenant une notation intuitive pour représenter les dépendances entre
propriétés. Si la valeur b d’une clé de propriété φB dépend de la valeur a
d’une clé de propriété φA , nous allons écrire (φA = a) → (φB = b). Ici, la
notation intuitive (φA = a) dénote tout simplement le couple (tA(2) , ta(1) ) (et
19
Dans les textes arabes, par contre, la diacritisation de ligatures est un phénomène réel et
même très courant dans les textes coraniques.
146
non une quelconque égalité de ces deux relations). Le choix de l’opérateur
« → » a été inspiré par celui employé pour les dépendances fonctionnelles à
propos des bases de données relationnelles, auxquelles nous reviendrons prochainement. Puisque les propriétés dépendantes peuvent se trouver dans deux
textèmes différents, il sera utile de marquer pour chaque propriété l’indice du
textème dans lequel elle se trouve : (φA (i) = a) → (φB (j) = b) signifiera que
la propriété (tB(2) , tb(1) ) du textème j dépend de la propriété (tA(2) , ta(1) ) du
textème i.
À l’aide de la notation ci-introduite, reprenons les dépendances présentes
dans le dernier exemple :
(φletter (i) = é, φfont (i) = Times) → (φglyph (i) = é)
(φglyph (i − 1) = r, φfont (i − 1) = Times, φglyph (i) = é, φfont (i) = Times) →
→ (φkern (i) = −0.05em)
Lorsque la dépendance existe « invariablement » pour toutes les valeurs de la
même clé de propriété, nous pourrons simplement écrire :
(φletter (i), φfont (i)) → φglyph (i)
(φglyph (i − 1), φfont (i − 1), φglyph (i), φfont (i)) → φkern (i)
Jusqu’ici, toutes les propriétés en dépendance sont des propriétés présentationnelles, introduites lors du formatage. Bien entendu, la dépendance est
un phénomène général qui ne se limite pas à ce seul usage. En reprenant le
même exemple sans propriétés présentationnelles :
lang = fr
letter = d
lang = fr
letter = o
hyph = true
lang = fr
letter = r
lang = fr
letter = é
Cette fois-ci il s’agit d’un usage linguistique : nous avons inséré une propriété
hyph = true qui autorise la césure du mot suivant le textème marqué. Cependant, le point de césure n’est pas une propriété de la lettre « o » mais du mot
entier ; en d’autres termes, la propriété de césure dépend de toutes les quatre
propriétés de lettre. Si l’on remplaçait la lettre « r » par un « u » dans le textème
suivant pour obtenir « doué », cela rendrait invalide le marquage de césure.
2.7.2 D ÉPENDANCES DANS LES MODÈLES DE
D ’U NICODE ET DE M-TEXT
TEXTE
Après ces exemples, il n’est pas surprenant que même le modèle Unicode Dépendances
n’échappe pas au phénomène de dépendance. En section 1.8.8 nous avons dans les chaînes
déjà montré que les caractères d’une chaîne Unicode entretiennent des rela- de caractères Unicode
tions de différentes sortes, relations qui doivent être comprises et respectées
aussi bien par les logiciels que par les utilisateurs travaillant directement sur
du texte Unicode brut, afin de maintenir la validité de celui-ci. La dépendance entre unités textuelles n’est donc pas une particularité du modèle en
textèmes. Quant à Unicode, à part la reconnaissance implicite du phénomène
et l’interdiction normative de certaines combinaisons de caractères (comme
147
Le M-text reconnaît
l’importance
des dépendances
Volatilité forte et faible
les caractères combinants en début de chaîne), il n’offre aucun mécanisme
d’indication de dépendance.
À la connaissance de l’auteur, le modèle de texte de la bibliothèque m17n,
le M-text (cf. p. 86), est le seul parmi les modèles de texte existants à reconnaître l’importance des dépendances entre propriétés textuelles et à entreprendre une forme de gestion automatique de dépendances. Ce n’est pas
par hasard : puisque le M-text est un modèle ouvert dans le sens où il permet l’ajout de propriétés arbitraires au texte, il fait forcément face au même
genre de problèmes que le modèle en textèmes. La solution fournie par m17n
est une solution d’ingénieur, très simple mais cohérente. Il s’agit d’introduire
des drapeaux associés aux propriétés (aux couples clé-valeur) qui contrôlent
leur comportement. Les deux drapeaux concernés par les dépendances sont
appelés volatilité faible et forte. Ils fonctionnent de la manière suivante : une
propriété faiblement volatile disparaît automatiquement lorsqu’un caractère
« dans sa proximité » est modifié, alors qu’une propriété fortement volatile disparaît lorsqu’un caractère ou n’importe quelle autre propriété est modifiée
dans sa proximité. Il s’agit donc d’un mécanisme rudimentaire mais conservateur qui veille à supprimer les propriétés concernées au premier risque de
dépendance potentiellement violée, sans pour autant vérifier si la violation a
réellement eu lieu. Quant à la signification de « proximité », ce paramètre est
géré en interne et dépend de l’opération en question (insertion, modification,
suppression).
Malgré la simplicité du mécanisme, nous pouvons en voir transparaître un
nombre de choix conceptuels :
– les drapeaux de volatilité s’associent aux instances de propriétés, c’està-dire aux éléments textuels, au lieu d’exister à un niveau schématique
plus élevé, au niveau des clés ou des couples clé-valeur. (On ne parle
pas de la volatilité de la propriété couleur ou couleur = rouge en général
mais toujours en association à un élément particulier de la chaîne.)
– L’incohérence est évitée par la suppression des propriétés volatiles. Le
système ne vérifie jamais si une violation de dépendance a réellement
eu lieu ou non.
– Le paramètre de proximité est choisi non pas en fonction de la propriété
volatile mais de l’opération entraînant sa suppression.
Il sera intéressant de comparer ces solutions à celles que nous allons proposer
suivant notre propre analyse de la problématique.
2.7.3 D ÉPENDANCES ET
REPRÉSENTATION DES CONNAISSANCES
Nous avons déjà fait allusion au fait que notre problème particulier est
généralisable à la problématique de cohérence de données dans le cadre de
la représentation des connaissances. Il serait donc judicieux d’examiner à ce
point les différences entre les approches que prennent les divers systèmes de
ce domaine. Nous allons également considérer la programmation orientée
objets ainsi que la programmation intensionnelle : bien que celles-ci soient
considérées comme des paradigmes de programmation plutôt que des systèmes de représentation des connaissances proprement dits, leur citation ici
n’est guère déplacée car elles s’inspirent fortement de certains principes de
148
ces derniers.
Il n’est pas surprenant que la notion de dépendance que nous sommes
en train de définir soit similaire à celle de la dépendance fonctionnelle entre
attributs dans le cadre de la théorie des bases de données. Tout d’abord, on
constate une analogie évidente entre le textème avec ses propriétés et la ligne
d’une table relationnelle et ses attributs ; de même, le texte en textèmes est
analogue à une table dont les lignes sont ordonnées. Dans le cadre de la
théorie des BD, la dépendance fonctionnelle sert à repérer un certain type
de relation présente entre attributs d’un schéma relationnel dans un but de
structuration optimale des données (e.g., éviter les redondances, et par ceci
réduire la potentialité des incohérences).
Dans la programmation orientée objet, les données membres définies dans
les classes sont encapsulées afin d’interdire toute modification directe depuis
l’extérieur de l’objet, pouvant causer leur incohérence. L’accès aux données
est restreint : il se fait uniquement à travers un ensemble de méthodes bien
définies qui se chargent, de façon algorithmique, de maintenir la cohérence
des données.
En programmation intensionnelle, toute expression est interprétée en fonction d’un contexte multidimensionnel où chaque dimension peut être représentée comme un couple clé-valeur. Il n’est pas surprenant que les dimensions
de contexte puissent également être concernées par le phénomène de dépendance [66].
Les systèmes de représentation de ressources tels que RDF ou OWL sont
basés sur les logiques de description. À travers la classification et la mise en relation des données (instances), mais aussi à travers des restrictions éventuelles
imposées sur les instances et les relations (restrictions de domaine et/ou de
portée, contraintes de cardinalité, propriétés telles que transitivité, etc.), des
assertions logiques sont formulées (dont l’expressivité est réduite à un sousensemble de la logique de première ordre afin de maintenir la décidabilité). À
l’aide d’un mécanisme d’inférence, ces assertions permettent ensuite de faire
des déductions logiques sur les données aussi bien que de maintenir leur cohérence.
Dans certains de ces exemples, le mécanisme de description et de résolution des dépendances fait partie intégrante du système de représentation
des connaissances. La même chose ne peut pas être dite du textème qui
reste, pour le moment, un simple conteneur de données. Faut-il envisager
d’étendre le textème afin qu’il indique également les relations de dépendance
que ses propriétés entretiennent entre elles ainsi qu’avec leur entourage ? Ou
devrions-nous considérer la première comme information contextuelle, « hors
de la boîte » ? Il n’est pas possible de répondre à ces questions avant que nous
n’ayons pas défini et analysé en détail à la notion de dépendance.
2.7.4 Q UELQUES QUESTIONS FONDAMENTALES
La raison fondamentale pour laquelle nous nous intéressons aux dépendances, hormis l’intérêt que présente le phénomène abstrait par soi-même,
est le souhait d’éviter l’introduction de données contradictoires dans le texte,
ou bien de pouvoir y appliquer des mesures correctives. Bref, le but est de
149
Dépendances
fonctionnelles
dans les BD
Encapsulation
Programmation
intensionnelle
Logiques de description
maintenir la cohérence des données, que ce soit entre propriétés à l’intérieur
d’un textème, entre textèmes différents ou même entre propriétés de textème
et propriétés contextuelles. Pour ce faire, la première chose nécessaire est bien
évidemment une bonne compréhension de ce que nous entendons par dépendance. Il ne suffit cependant pas d’en formuler une définition quelconque,
nous devons également répondre à des questions telles que :
– quelle est la raison de leur existence ? Sont-elles la conséquence de
« lois » externes au modèle et a priori existantes ou trouvent-elles plutôt leur origine dans les opérations concrètes effectuées sur le texte ?
– S’agit-il d’informations faisant partie intégrante du texte ? De relations
présentes au niveau des instances de propriétés (comme dans le M-text),
au niveau des couples clé-valeur, au niveau des clés, ou tous les cas
sont possibles ?
– Quelles sont les opérations élémentaires capables d’introduire une incohérence ?
– Par quelles mesures préventives ou correctives peut-on empêcher les
incohérences ?
– Existe-t-il une solution générale et en même temps efficace à la gestion
des dépendances, ou est-il préférable d’avoir des méthodes adaptées à
chaque usage ?
2.7.5 D ÉFINITIONS ET
ANALYSE THÉORIQUE DE LA NOTION
DE DÉPENDANCE
En général, nous pouvons affirmer que la dépendance est un type de relation, mais cette description en soi n’apporte pas grand chose à la compréhension du phénomène. Cependant, dès que nous essayons de caractériser
cette relation — par la nature des entités qu’elle interconnecte, par ses propriétés intrinsèques —, nous nous heurtons à des questions moins évidentes à
répondre.
Dépendances
Tout d’abord, quelles sont les entités qui entretiennent des relations de déentre classes pendance ? S’agit-il de clés de propriété, de couples clé-valeur ou d’instances
ou entre instances de ces derniers ? On trouve facilement des exemples pour les deux premières
éventualités :
(φletter , φfont ) → φglyph
(φlang = french) → (φscript = latin)
où les propriétés φ peuvent tout aussi être des propriétés de textème (comme
φglyph ) que des propriétés contextuelles (comme φlang ), d’autant plus que l’un
peut à tout moment devenir l’autre grâce au mécanisme de contextualisationdécontextualisation.
Certains systèmes de représentation des connaissances reconnaissent également la différence entre relations opérant au niveau des classes et au niveau des instances. La dépendance fonctionnelle dans le cadre des BD ne
concerne, par définition, que les relations existant au niveau des attributs de
schéma. Dans RDF, et en général dans les logiques de description, on distingue systématiquement entre « niveau classe » (T-box, informations terminologiques, RDF schéma) et « niveau instance » (A-box, informations sur les
assertions, instances RDF).
150
Cependant, le problème est encore plus complexe : pour revenir aux
exemples précédents, l’utilisateur peut malgré tout choisir d’employer un
glyphe alternatif dans un textème précis, en contradiction avec la règle cmap
venant de la fonte, ou d’écrire le français en katakana japonais, dans lesquels
cas les dépendances sont annulées au niveau des instances. Dans ces cas,
l’utilisateur a délibérément ignoré une restriction explicite et formelle (la table
cmap) ou une convention implicite et informelle (le français s’écrit en latin) :
il vient de créer le tout premier signe au monde écrit en japonais mais lu en
français. Il n’est peut-être même pas au courant de la catastrophe qu’il a ainsi
causé : à partir de ce moment historique, la dépendance français → latin ne
sera plus jamais valable.
On sent bien que ce raisonnement est, pour dire le moins, exagérée. Ce La dépendance :
que nous avons voulu montrer est que donner une interprétation exacte de la observation empirique
notion de dépendance est loin d’être évident. Tout d’abord, il faut élucider ou idée absolue ?
la nature des observations exprimant une dépendance, telles que « le français
s’écrit en latin ». À la base, nous avons le choix de les considérer soit comme
des observations empiriques, soit comme des règles absolues formulées de
manière abstraite. (Il s’agit donc encore une fois de l’opposition classique entre
empirisme et idéalisme.) Dans le premier cas, nous cherchons les racines du
phénomène de la dépendance dans l’ensemble T0 de notre modèle, qui représente le monde observé, et nous en retirons des règles : nous adoptons
une approche de scientifique qui vise à décrire le monde. Dans le dernier cas,
en revanche, l’origine de la dépendance est une idée, une méthode, un algorithme a priori existant : c’est l’approche de l’ingénieur qui établit lui-même
les règles suivant lesquelles son système doit fonctionner.
Bien que notre objectif principal dans cette thèse soit la conception de
modèles de texte qui soient réalisables en pratique, ce qui présuppose un raisonnement d’ingénieur, nous tenterons dans un premier temps d’adopter un
regard empirique et de définir et d’analyser la notion de dépendance en se
basant sur la structure des strates inférieures de notre cadre de modélisation.
Ceci nous permettra, entre autres, de voir sous quelles conditions pratiques il
est possible de recourir à un raisonnement « scientifique » dans la description
et la gestion des dépendances, et à partir de quel moment ce type de raisonnement doit céder sa place aux approches d’ingénierie. Car nous allons voir
que, une fois de plus, plus nous essayons de résoudre les problèmes dans leur
généralité, moins nos solutions deviennent efficaces.
UNE
DÉFINITION ENSEMBLISTE DE LA DÉPENDANCE
RELATIONS ENTRE PROPRIÉTÉS DU MÊME TEXTÈME
:
La raison pour laquelle une dépendance telle que (φlang = french) →
(φscipt = latin) est « valable » ou non doit être cherchée au niveau de la définition de l’univers de base : parmi tous les signes du monde, quels sont
les signes « pertinents » du point de vue d’une dépendance particulière ? Car
malgré le fait que la langue française a toujours été écrite en latin dans son histoire, il est presque certain que quelqu’un dans le monde a déjà tenté d’écrire
le français à l’aide de lettres grecques, runiques, etc. Ces exceptions sontelles insignifiantes ou pertinentes, invalident-elles vraiment la dépendance
français → latin ?
151
Cela dépend, encore une fois, de l’usage. Puisque nous visons la construction d’un modèle de texte général et global, il n’est pas envisageable en général d’interdire la création de textèmes où φlang = french et φscript = katakana.
Par contre, il est tout à fait raisonnable d’imaginer un logiciel de PAO qui interdise cette sélection, et qui exclue également l’association d’un glyphe « B »
à un caractère « A ». À la base, il s’agit de restreindre l’ensemble de signes,
représenté par l’ensemble T0 , à un sous-ensemble « raisonnable » en taille et
cohérent avec un certain nombre de conventions (telles que « le français s’écrit
en latin, on n’écrit pas une lettre « A » par un glyphe qui ressemble à un « B »,
etc.). Notre ensemble T0 de base est donc choisi de manière qu’il soit pertinent par rapport à l’usage que nous faisons de notre texte. Les dépendances
présentes dans notre texte seront toujours fonctions de ce choix.
La question que nous nous posons est donc la suivante : avec un ensemble
O ⊆ T0 de signes20 donné et leurs propriétés définies dans T1 , comment interpréter la relation de dépendance entre deux ou plusieurs propriétés, l’unique
information que nous possédons étant les extensions respectives de celles-ci ?
Dans un souci de simplicité, nous supposerons dans un premier temps que
toutes les propriétés participant à la relation de dépendance réfèrent au même
signe, en d’autres termes, nous nous intéresserons uniquement aux dépendances entre propriétés au sein du même textème.
Définissons d’abord la notion d’incohérence entre propriétés d’un textème. (Nous entendons par propriété une relation unaire de T1 car pour le
moment nous ne nous intéressons pas à sa clé.)
DÉFINITION 12 (INCOHÉRENCE
DE PROPRIÉTÉS)
Les propriétés φ1 , φ2 , ..., φn ∈ T1 sont incohérentes entre elles si
ext(φ1 ) ∩ ext(φ2 ) ∩ ... ∩ ext(φn ) = ∅
Par conséquent, si un textème contient des propriétés incohérentes, alors forcément il ne dénote aucun signe dans l’ensemble O ⊆ T0 , il « n’a pas de
sens »21 . D’après cette définition, une seule propriété peut être « incohérente »
en soi si son extension est vide (par exemple, φscript = Ööç).
Nous procédons maintenant à une définition formelle de la notion de
dépendance, l’idée étant celle déjà évoquée brièvement en section 2.4.4 :
qu’une propriété φB dépend d’une propriété φA (nous écrirons : φA → φB ) si
tous les signes caractérisés par φA sont forcément caractérisés par φB également (fig. 2.14 illustre le principe). En généralisant à un nombre quelconque
n de propriétés :
DÉFINITION 13 (DÉPENDANCE
EXTENSIONNELLE)
Soit n > 1, φn une propriété de T1 et {φ1 , ..., φn−1 } un ensemble de propriétés de T1 cohérentes entre elles. La propriété φn dépend de l’ensemble
{φ1 , ..., φn−1 } si
ext(φ1 ) ∩ ... ∩ ext(φn−1 ) ⊆ ext(φn )
Nous écrirons alors : {φ1 , ..., φn−1 } → φn , ou si n = 2, alors φ1 → φ2 .
20
Rappelons que T0 contient, par définition, non seulement des signes individuels (ensemble
O) mais aussi des tuples (O2 , O3 , etc.).
21
Frege dirait : il a du sens mais il n’a pas de dénotation !
152
FIG. 2.14 – À partir des intersections des ensembles dans T0 — qui sont les
extensions des trois propriétés de T1 — la dépendance {FUTURA EXTRA BLACK,
LETTRE A MAJUSCULE } → 28PT peut être déduite. (Cette dépendance n’est bien
sûr valable que sur l’ensemble de signes très restreint de notre exemple.)
La dépendance extensionnelle est donc une relation entre un ensemble de
propriétés et la propriété dépendante. Quelques conséquences de la défini- Conséquences
de la définition
tion :
1. ({φA , φB } → φC ) 6⇒ (φA → φC ), ni φB → φC ;
2. l’opérateur « → » est réflexif car ext(φA ) ⊆ ext(φA ) ;
3. si ext(φA ) = ext(φB ) mais φA 6≡ φB (il s’agit de deux relations distinctes
mais extensionnellement égales, ce qui est permis grâce à l’intensionnalité de T1 ), alors φA → φB et φB → φA ;
4. il est transitif : si φA → φB et φB → φC , alors ext(φA ) ⊆ ext(φB ) et
ext(φB ) ⊆ ext(φC ), dont φA → φC est trivial ;
5. il n’est ni symétrique (trivial), ni antisymétrique (cf. (3)) ; par conséquent,
ce n’est pas une relation d’ordre sur T1 ;
6. par contre, les propriétés et ensembles de propriétés extensionnellement
égales forment des classes d’équivalence à cause de (2), (3) et (4).
LA
RELATION DE DÉPENDANCE EST FONCTIONNELLE
Considérons maintenant l’ensemble de dépendances
{φA1 , φB1 , ..., φM1 } → φN1
{φA2 , φB2 , ..., φM2 } → φN2
..
.
{φAn , φBn , ..., φMn } → φNn
153
où chaque Ai (Bi , etc.) représente une valeur particulière appartenant à la
clé de propriété A (B, etc). Il s’agit donc d’un ensemble de dépendances qui
concernent les mêmes clés de propriété, par exemple :
(φletter = F) → (φscript = latin)
(φletter = G) → (φscript = latin)
(φletter = ℵ) → (φscript = hebrew)
(φletter = Ξ) → (φscript = greek)
La dépendance
extensionnelle
est une relation
fonctionnelle
En considérant chaque dépendance individuelle comme un tuple (Ai , Bi , ...,
Mi , Ni ), il est facile à vérifier que l’ensemble des tuples ainsi construit réalise
une relation fonctionnelle dont le domaine est (∪{Ai }, ∪{Bi }, ..., ∪{Mi }) et
la portée est ∪{Ni }. En effet, la non-fonctionnalité signifierait qu’il existe une
suite de valeurs (Ak , Bk , ..., Mk ) de laquelle dépendent plusieurs valeurs Ni ,
ce qui contredit à notre supposition selon laquelle les extensions de deux valeurs de la même clé de propriété sont toujours disjoints, formulée en p. 101 :
ext(Ni ) ∩ ext(Nj ) = ∅ tq. i 6= j
(2.1)
ext(Ak ) ∩ ... ∩ ext(Mk ) ⊆ ext(Ni )
(2.2)
ext(Ak ) ∩ ... ∩ ext(Mk ) ⊆ ext(Nj )
(2.3)
où (2.2) et (2.3) ensemble contredisent à (2.1).
La relation fonctionnelle devient applicative lorsque chaque combinaison
(Ai , Bi , ..., Mi ) de valeurs est couverte par une dépendance. C’est dans ce seul
cas que nous avons droit d’écrire des règles telles que {φletter , φfont } → φglyph ,
comme nous l’avons fait dans la section précédente.
Le fait que la relation de dépendance extensionnelle s’est avérée fonctionnelle est important car il s’agit d’une preuve rétroactive de la pertinence de
notre définition d’origine, conçue de manière intuitive.
INTÉRÊT
PRATIQUE DE LA DÉFINITION EXTENSIONNELLE
DE LA DÉPENDANCE
L’analyse précédente nous a permis de comprendre et de formaliser une
forme de dépendance que nous avons appelée dépendance extensionnelle,
car elle découle des relations de compréhension entre les ensembles de signes
qui correspondent aux propriétés. En d’autres termes, cette forme de dépendance est fonction de l’univers O ⊆ T0 de signes et de notre manière de les
catégoriser.
Du point de vue de l’utilité pratique de notre définition — si elle peut
être utilisée ou non comme un outil pratique afin de décider si une dépendance existe entre deux ou plusieurs propriétés — la taille de cet univers est cruciale : plus de signes que l’on y trouve, plus il devient difficile en pratique d’en comparer deux sous-ensembles, et donc de décerner
les dépendances. Par exemple, en prenant comme ensemble de base de
, alors la dépendance
signes un ouvrage japonais qui contient le signe
(φchar = ) → (φlang = japanese) est facilement vérifiable. Cependant, la
154
même dépendance devient pratiquement invérifiable lorsque l’on étend l’ensemble de base à tous les ouvrages du monde, puisque l’on ne peut pas avoir
la certitude que le même signe n’ait jamais été utilisé en Chine, en Corée ou
au Viêtnam, sans avoir parcouru tous les textes de ces pays22 .
La conclusion que nous tirons des considérations précédentes est qu’avec
un univers restreint — comme par exemple un sous-ensemble des caractères
Unicode — l’approche extensionnelle à la gestion des dépendances est possible. Elle devient néanmoins peu exploitable en pratique dès que la taille de
l’ensemble O augmente, une tendance inévitable si le modèle de texte vise
la généralité. C’est pour la même raison que nous ne tentons même pas de Dépendances
décrire les dépendances entre propriétés de signes différents : si |O| est déjà entre signes différents
élevé, alors il n’est même pas la peine de s’intéresser aux paires ou aux triplets
de signes (etc.) dont le cardinal est |O2 | et |O3 |.
UNE INTERPRÉTATION
ALGORITHMIQUE DE LA NOTION DE DÉPENDANCE
En vue des difficultés que nous venons de présenter, nous allons proposer
une définition alternative à la dépendance, définition qui, au lieu d’être basée
sur des observations du monde écrit, s’inspire de considérations d’ingénierie
de modèles de texte. Au lieu de regarder la dépendance comme un fait empirique, nous allons la considérer comme la conséquence d’une manipulation
algorithmique de texte numérique. Notre motivation de restreindre d’une manière si drastique l’interprétation de la dépendance est le souci de la rendre
modélisable et exploitable par des systèmes informatiques.
DÉFINITION 14 (DÉPENDANCE
ALGORITHMIQUE)
Une propriété φj (pj ) du textème se trouvant dans une position pj quelconque
de la chaîne est en dépendance algorithmique de l’ensemble de propriétés
{φ1 (p1 ), ..., φi (pi )} si elle a été obtenue à l’aide d’un algorithme exécuté par
un logiciel, ayant ces dernières propriétés parmi ses entrées.
En d’autres termes, par l’adoption d’une telle interprétation nous exigeons
non seulement qu’une dépendance soit fonctionnelle, mais aussi que la fonction en question soit connue et ait réellement été appliquée. L’existence de la
dépendance est donc postérieure à l’exécution de l’algorithme. Il faut mentionner que nous employons le terme algorithmique dans un sens précis : il
s’agit d’une opération quelconque exécutée par un logiciel. Bien évidemment,
toute manipulation de texte numérique effectuée par un être humain passe forcément par l’exécution de certains algorithmes d’insertion, de modification,
de suppression, etc., mais ces opérations n’effectuent en général pas de calculs
sur les valeurs d’autres propriétés.
D’un point de vue pratique, pour un logiciel informatique, cela ne pose en
général aucun problème de maintenir les correspondances entre les propriétés
d’entrée et de sortie des fonctions de traitement textuelle qu’il fait exécuter ;
le suivi des dépendances algorithmiques est donc facilement réalisable. En revanche, la définition de la dépendance algorithmique n’est pas du tout utile
22
L’apparition de ce signe à l’extérieur du Japon est improbable car il s’agit d’un « jeu de
mot » typiquement japonais, cf. p. 50.
155
pour décerner l’incohérence due à une propriété introduite ou modifiée directement par l’utilisateur, de manière interactive.
2.7.6 L A
DÉPENDANCE ALGORITHMIQUE DOIT TROUVER
SA PLACE DANS LE CADRE FORMEL DE MODÉLISATION
Ayant arrivés à une définition satisfaisante de la dépendance, il nous reste
encore à voir comment il est possible de représenter celle-ci au sein du système de strates. Rappelons que notre objectif est d’éviter l’incohérence parmi
les données textuelles, ce qui n’est possible que par la connaissance des dépendances entre propriétés, d’où l’intérêt de les considérer, d’un moyen ou
d’un autre, comme faisant partie intégrante du texte. Une première question à
clarifier est si les dépendances sont représentées au sein des textèmes ou s’il
s’agit plutôt d’informations en dehors des éléments textuels tout en étant liées
au texte — ou autrement dit : contextuelles ?
En section 2.5.2 nous avons défini le contexte macroscopique comme un
ensemble de propriétés associées à des éléments textuels ou à des relations
d’éléments (dont des chaînes). Selon si ces éléments textuels sont des signes
(de T0 ) ou des textèmes (de T3 ), les propriétés contextuelles peuvent soit être
dérivées à partir de chaînes de signes observées, soit situées parmi les strates
supérieures, en tant que structures de haut niveau au sein du modèle. On
observe la même dualité entre les définitions extensionnelle et algorithmique
de la dépendance : la première découle de relations de compréhension entre
sous-ensembles de T0 , alors que la dernière est interprétée comme une relation entre propriétés de textèmes en tant qu’éléments du modèle (car c’est le
modèle, et non le monde réel, qui est soumis aux algorithmes).
L’idée de considérer la dépendance — par laquelle nous entendons désormais la dépendance algorithmique — comme une information contextuelle
paraît raisonnable et même intuitive : lorsque les propriétés de deux textèmes
différents entretiennent une relation de dépendance, cette information ne fait
partie de la description d’aucun des deux signes représentés, tout comme la
propriété « langue française » n’est attaché à des lettres individuelles mais à un
mot (ou morphème) entier.
D’autre part, du point de vue de l’accès à l’information, peu importe
si théoriquement (selon le modèle) ou réellement (suivant l’implémentation
concrète) elle se trouve à l’intérieur ou à l’extérieur de la « boîte », puisqu’il
est tout à fait envisageable de permettre sa consultation des deux manières à
la fois, tout simplement par l’intermédiaire d’opérations de contextualisationdécontextualisation. Nous devons néanmoins mentionner un intérêt pratique
de ne pas considérer la dépendance comme information contextuelle : lorsque
tout est intégré dans les textèmes, le texte garde son aspect autocontenant, sérialisé, intuitif. Dans le cas contraire, toute échange de texte (e.g., entre deux
logiciels) devra forcément veiller à également échanger le contexte associé ;
ce qui entraîne la nécessité de créer, dans le cadre de notre système de strates,
un modèle de contexte général.
156
LA
DÉPENDANCE EN TANT QU’INFORMATION CONTEXTUELLE
En quoi consisterait exactement la dépendance algorithmique en tant
qu’information contextuelle ? Est-ce l’algorithme lui-même qui représente la
dépendance ou s’agit-il juste d’une mise en relation de ses paramètres d’entrée et de sortie ? En termes informatiques : la dépendance, est-elle la fonction
entière ou seulement la signature de la fonction ? Les deux interprétations sont
légitimes. En effet, on peut supposer que le contexte englobe tous les algorithmes et règles ayant servis au calcul de propriétés d’un texte, ainsi formant
un ensemble de contraintes autour des données textuelles (qu’elles soient des
propriétés de textème ou contextuelles). Cette approche laisse penser aux principes de la programmation par contraintes, des T-box des logiques de description, ou encore aux dimensions de contexte dépendantes en programmation
intensionnelle [66]. D’autre part, par l’application d’une opération de décontextualisation à l’algorithme représentant la dépendance, on introduit celui-ci
dans le textème : ce que l’on obtient est un ensemble de données couplées
avec les algorithmes qui les manipulent, autrement dit, des objets (de la programmation orientée objets).
Le couplage de données et opérations textuelles, même par l’intermédiaire
d’un contexte, bouleverse notre vision traditionnelle du texte en tant qu’ensemble structuré d’informations statiques, en créant ce qui est à toute vraisemblance une entité dynamique et pourvue d’une certaine dose d’« intelligence ».
Malgré qu’une telle réinterprétation de la modélisation de texte se montre intéressante dans le cadre de certains usages et mérite clairement davantage de
réflexions, nous préférons néanmoins nous tenir à une approche plus sobre et
conservatrice qui permet au texte de garder sa simplicité structurelle et de rester, au fond, donnée et non logiciel. Le contraire nous mènerait certainement
très loin des objectifs principaux de la thèse.
L’autre approche consiste à se contenter de l’indication de la dépendance
par une mise en relation des propriétés d’entrée et de sortie de l’algorithme
dont elle se dérive. Pour chaque propriété créée ou modifiée, il s’agit d’indiquer toutes les autres propriétés textuelles (se trouvant dans le même textème,
dans d’autres textèmes, voire même dans le contexte) qui ont contribué au calcul de sa valeur. L’ensemble de dépendances ainsi indiquées grandit avec la
quantité de traitement que traverse le texte, et devient le « journal » ou l’« historique » des opérations effectuées sur le texte, d’autant plus qu’en étiquetant
la relation des paramètres d’entrée et de sortie d’une opération par un nom
approprié, on obtient l’équivalent d’une signature de fonction. Bien entendu,
les indications de dépendances peuvent (et sont même censées) se disparaître
du texte lorsque les propriétés concernées sont supprimées.
Suivant cette approche, la description d’une dépendance consiste à introduire parmi les propriétés de contexte macroscopique une entrée
dep(étiquette, φN (tN ), {φA (tA ), ..., φM (tM )})
où étiquette peut être quelconque mais elle est typiquement une référence
vers la routine dont l’exécution a créé la dépendance, φN est la propriété
dépendante se trouvant dans le textème tN , et φA ...φM sont des propriétés
sources avec leurs textèmes respectifs. Il y aura donc autant de telles entrées
157
Dépendance = algorithme
en contexte
Le texte devient
logiciel ?
dans le contexte qu’il y a des manifestations de cette dépendance dans le texte.
Par exemple, après l’insertion des identifiants de glyphe dans les textèmes,
récupérés depuis la table cmap de la fonte ArialBold :
..
.
dep(cmap, φglyphID (5), {φchar (5), φfont (5)})
dep(cmap, φglyphID (6), {φchar (6), φfont (6)})
dep(cmap, φglyphID (7), {φchar (7), φfont (7)})
..
.
on finit par avoir autant d’entrées qu’il y a des propriétés φglyphID dans le texte.
Lorsque l’exécution de la routine est invariante par rapport à la position
dans la chaîne, c’est-à-dire que la dépendance est forcément présente pour
tout textème ayant les propriétés indiquées, alors l’intégralité des entrées du
type ci-dessus peut être remplacée par des entrées généralisées qui indiquent
la correspondance des valeurs des propriétés source et de la propriété dépendante :
dep(étiquette, φN (i) = vN , {φA (i + kA ) = vA , ..., φM (i + kM ) = vM })
où 1 ≤ i, i + kA , ..., i + kM ≤ n et n est le nombre de textèmes dans le texte.
On a donc remplacé les dépendances comprenant des indices absolus par des
dépendances comprenant des indices relatives :
..
.
dep(cmap, φglyphID (i) = 123, {φchar (i) = U + 0041, φfont (i) = ArialBold})
dep(cmap, φglyphID (i) = 124, {φchar (i) = U + 0042, φfont (i) = ArialBold})
..
.
Au lieu donc d’avoir autant d’entrées que de propriétés φglyphID dans le texte,
on finit par en avoir autant qu’il y a des φglyphID distinctes.
Lorsque, de plus, toutes les propriétés φN du texte sont calculées invariablement par la même routine à partir des mêmes sources φA , ..., φM , quelle
que soit la valeur vN , alors l’entrée précédente peut être simplifiée davantage,
pour obtenir
dep(étiquette, φN (i), {φA (i + kA ), ..., φM (i + kM )})
ce qui réduit notre exemple à une seule ligne :
dep(cmap, φglyphID (i), {φchar (i), φfont (i)})
Ces simplifications réduisent de manière drastique le nombre de dépendances qui doivent être stockées. Cependant, elles supposent la connaissance
du fonctionnement de la routine en question, ce qui signifie que la gestion des
dépendances ne peut pas être réalisée comme une fonction générique et indépendante (qui ne peut a priori pas savoir que la fonction cmap est appliquée
158
invariablement à tous les textèmes), elle doit être intégrée dans le système qui
fait exécuter les diverses routines de traitement textuel.
Prochainement, nous montrerons quelques implémentations concrètes de
l’approche ci-décrite ; mais avant d’y arriver, nous devrons d’abord nous intéresser aux questions de base de la gestion des dépendances : quelles sont les
opérations susceptibles de violer les dépendances et par quelles mesures la
violation peut être empêchée.
2.7.7 L A
GESTION DES DÉPENDANCES
OPÉRATIONS
ÉLÉMENTAIRES POUVANT INTRODUIRE DE L’INCOHÉRENCE
DANS LE TEXTE
Les opérations élémentaires qui modifient la chaîne de textèmes et qui
sont susceptibles d’y introduire des incohérences sont les suivantes :
1. l’ajout d’une nouvelle propriété à un textème ;
2. la modification de la valeur d’une propriété ;
3. la suppression d’une propriété ;
4. l’insertion d’un textème ;
5. la suppression d’un textème.
Un examen plus détaillé de ces opérations révèle cependant que certaines
parmi elles ne violent jamais la dépendance algorithmique.
′ introduit de l’incohérence :
1. L’ajout d’une nouvelle propriété φB = vB
Ajout de propriété
– si l’on suppose l’existence a priori d’une dépendance (φA = vA ) →
(φB = vB ), la propriété φA = vA est déjà présente dans le texte et
′ ;
vB 6= vB
′ ) → (φ = v ), la
– ou bien, si la dépendance supposée est (φB = vB
C
C
′ est déjà présente dans le texte et v 6= v ′ .
propriété φC = vC
C
C
Cependant, accepter l’existence a priori de dépendances — sans exiger
la présence de données dépendantes — n’est pas conforme à la définition de la dépendance algorithmique qui exige que celle-ci soit le ré′ ne peut être introduite
sultat d’un calcul concret. La propriété φB = vB
que de deux manières : interactive ou algorithmique, où par définition
aucune des deux n’est capable de violer une dépendance de type algorithmique.
2. Si les deux propriétés φA = vA et φB = vB sont déjà présentes dans le Modification
de propriété
texte, ainsi que la dépendance (φA = vA ) → (φB = vB ), alors
′ entraîne une incohérence, que la mo– la modification de vA en vA
dification soit faite par un algorithme ou par intervention humaine
(puisque la valeur de φB doit être recalculée),
′ peut entraîner ou ne pas entraîner une
– la modification de vB en vB
′ ,
incohérence : lorsque c’est un algorithme qui remplace vB par vB
alors on peut considérer que la dépendance (φA = vA ) → (φB = vB )
′ ) ; la modification de φ
a été supplantée par (φA = vA ) → (φB = vB
B
par un humain peut être considérée comme une violation de dépendance mais aussi comme l’outrepassement du calcul algorithmique,
dans lequel cas la dépendance (φA = vA ) → (φB = vB ) est annulée.
159
Suppression
de propriété
Ajout ou suppression
de textème
3. En supposant une dépendance (φA1 = vA1 , φA2 = vA2 , ..., φAn =
vAn ) → (φB = vB ), ni la suppression d’une φAi = vAi ni celle de
φB = vB ne produit de l’incohérence car cette notion n’est pas interprétable à des données non présentes. D’ailleurs, une condition suffisante
de la suppression de la trace d’une telle dépendance est que toutes les
φAi = vAi ou bien φB = vB soit supprimé.
4. et 5. En supposant l’existence d’une dépendance (φA (i) = vA ) →
(φB (j) = vB ) entre propriétés de deux textèmes, l’introduction ou la
suppression d’un textème tk , i < k < j, peut entraîner sa violation.
Cela peut dépendre de nombreux facteurs :
– si la distance des textèmes ti et tj est considérée dans la dépendance
(par exemple, s’il s’agit d’une propriété de crénage qui n’a de sens
que si ti et tj sont adjacents),
– de la nature du textème inséré (l’insertion d’un textème d’accent entre
ti et tj n’invalide pas le crénage, alors que l’insertion d’un textème de
lettre de base l’invalide),
– de la manière d’indiquer la dépendance entre textèmes (il s’agit donc
d’un problème d’implémentation et non de théorie) : une dépendance
indiquée à l’aide d’un « pointeur » vers une position dans la chaîne,
qu’il soit absolu (e.g., position no 27) ou relatif (e.g., « textème suivant »), doit être mise à jour après l’insertion ou la suppression de
textème(s) dans la chaîne.
On peut conclure que les seules opérations qui risquent de violer une dépendance algorithmique sont la modification de propriété, l’ajout et la suppression de textèmes, et ces deux dernières seulement dans la présence de
dépendances inter-textémiques. Nous avons également pu voir que la violation ou non d’une dépendance par l’insertion ou la suppression d’un textème
dans la chaîne dépend de nombreux facteurs.
MESURES CONTRE L’INCOHÉRENCE
ÉVITER, CORRIGER OU IGNORER
DE DONNÉES
:
Étant arrivés à la fin de nos analyses de la problématique des dépendances
et sur le point de proposer des solutions, il est peut-être judicieux de prendre
du recul afin de préciser nos besoins. Tout d’abord, nous devons admettre
que nos analyses n’ont pu être que partielles : derrière le rideau tissé de problèmes très concrets de modélisation de texte, nous avons pu apercevoir le
fonctionnement d’un mécanisme bien plus général et abondamment étudié
dans le cadre de nombreux domaines de la représentation des connaissances
(cf. section 2.7.3). Cette réalisation pourrait nous pousser vers l’emprunt de
certaines notions, voire des solutions complètes développées dans le cadre
de l’intelligence artificielle ou du Web sémantique ; et c’est exactement ce
que nous faisons lorsque nous considérons la dépendance comme une information contextuelle, où lorsque nous faisons recours à une description et un
système d’inférences de type RDF/OWL dans le chapitre suivant, dans le but
de créer des répertoires de propriétés et de signes. Cependant, malgré avoir
identifié et situé la dépendance parmi les phénomènes similaires d’autres systèmes de RC, il faut comprendre que notre objectif principal par l’indication
160
des dépendances n’est pas la description complète et minutieuse de la complexité des relations qu’entretiennent les éléments textuels et leurs propriétés,
afin d’en retirer davantage d’informations à l’aide d’un moteur d’inférences, ce
qui pourrait être le cas d’un système classique de représentation des connaissances. Nous, nous cherchons avant tout un modèle de texte qui se veut général mais qui garde une certaine souplesse et simplicité. Par conséquent, nous
préférons d’adopter à ce point une approche d’ingénieur (plutôt que de scientifique) et de proposer des solutions simples, pratiques, d’exécution rapide,
moins ambitieuses en puissance descriptive, tout en restant conformes aux les
définitions et idées avancées dans les sections précédentes. Bien évidemment,
le compromis entre puissance et simplicité doit être choisi cas par cas, selon
le cadre d’usage : sa généralité, son degré d’interactivité, la puissance de calcul disponible, etc. Pour cette raison, nous considérerons plusieurs méthodes
alternatives de gestion de dépendances.
Au plus général, trois approches fondamentales sont envisageables quant
à la gestion des dépendances. Premièrement : ignorer les incohérences, c’està-dire accepter la potentialité de leur apparition comme une propriété intrinsèque du modèle sans chercher à les éviter. Deuxièmement : prendre des
mesures préventives afin d’empêcher l’introduction de données qui violent
des dépendances. Et troisièmement : au lieu d’empêcher l’acte qui introduit
l’incohérence, appliquer plutôt des méthodes automatiques qui recalculent
les données textuelles concernées afin d’atteindre une nouvelle équilibre sans
incohérences. Il n’est pas forcément nécessaire de choisir parmi ces trois approches de manière absolue ; au contraire, il est probable que le choix dépendra du cadre de l’usage en question :
– dans un contexte procédural (par exemple, formatage par un logiciel
tel qu’Ω2 , voir chapitre suivant) une gestion automatisée (prévention ou
correction) des dépendances est envisageable ;
– dans un éditeur de texte interactif et de bas niveau — qui donne un
accès illimité aux textèmes23 — l’approche qui correspond le mieux à
la fonctionnalité de l’outil est d’ignorer les dépendances ;
– dans un éditeur de texte orienté « grand public », il est possible que le
logiciel prenne des mesures automatiques ou semi-automatiques (en posant des questions simples à l’utilisateur) afin de maintenir la cohérence
des données.
Ignorer les dépendances éventuelles est une approche triviale mais cohérente. Elle peut convenir lors de la création d’un nouveau texte (car l’ajout de
propriétés ne risque pas d’introduire de dépendance algorithmique, cf. plus
haut) ou lorsqu’un accès de bas niveau au texte est autorisé. Rappelons cependant qu’en ne considérant que les dépendances d’origine algorithmique
nous ignorons également toute contrainte d’origine différente, et par conséquent nous n’avons aucune possibilité de détecter l’incohérence entre deux
propriétés introduites dans le texte directement par l’utilisateur.
Éviter l’incohérence peut consister à empêcher complètement les opérations susceptibles d’être ses causes (modification de valeur de propriété, in23
Il n’est pas nécessaire que le texte en textèmes soit forcément exposé à l’utilisateur dans
son intégralité ou « à l’état nu » ; au contraire, on envisage des usages interactifs où l’accès aux
textèmes, aussi bien en lecture qu’en écriture, est restreint par l’interface homme-machine.
161
Le choix de l’approche
dépend de l’usage
Ignorer
les dépendances
Éviter les incohérences
sertion ou suppression de textème), au risque d’éventuellement devoir interdire toute modification du texte. Alternativement, les propriétés correspondant à certains usages peuvent être automatiquement supprimées au moment
où d’autres propriétés dont elles dépendent sont modifiées. Ainsi, dans le
cas d’un texte formaté (contenant des propriétés introduites lors du formatage
telles que glyphe, position (x, y) du glyphe, crénage, etc.) la modification du
contenu textuel (les « caractères ») peut entraîner la suppression des données
de formatage du texte entier qui, de toute manière, risquent de devenir obsolètes. Finalement, une solution plus sophistiquée est de limiter aussi bien
l’interdiction de la modification que celle de la suppression uniquement aux
propriétés qui participent à une dépendance. Cette approche suppose que les
relations de dépendance sont maintenues et que l’outil informatique y a accès
et sait les interpréter.
Corriger
Corriger l’incohérence consiste à découvrir d’abord, et encore une fois de
les incohérences manière automatique, qu’une dépendance a été violée dans le texte et ensuite
à rétablir la cohérence des données tout en respectant la modification qui vient
d’être effectuée. En supposant l’existence d’une dépendance (φA = vA ) →
(φB = vB ), la modification de φA peut rendre la valeur vB obsolète. À part la
suppression de la propriété φB , dans certaines situations il est envisageable de
′ correspondant à la valeur v ′ modifiée. Bien
recalculer la nouvelle valeur vB
A
entendu, si d’autres dépendances (φA = vA ) → (φC = vC ) ou (φB = vB ) →
(φC = vC ) existent, alors la valeur de φC devra également être recalculée,
et ainsi de suite. En revanche, en supposant la même dépendance (φA =
vA ) → (φB = vB ), la modification de φB n’entraîne a priori pas la mise à jour
de φA car la relation de dépendance n’est pas symétrique : la modification
de la propriété φkern (i) qui dépend (entre autres) de φglyph (i) n’entraîne pas
la modification de cette dernière propriété, d’autant plus que l’altération du
crénage par rapport à sa valeur par défaut définie par la fonte peut être une
opération légitime et permise. La modification de φglyph (i) devra par contre
sans doute causer la suppression ou la mise à jour de la valeur de crénage.
En somme, le choix de l’approche quant à la gestion des incohérences
est toujours une question de compromis entre puissance requise par la tâche
de traitement donnée, simplicité exigée et ressources de calcul (et même de
stockage) disponibles. Puisque ces trois paramètres varient avec l’usage, la méthode de gestion de dépendances doit également être choisie cas par cas. Dans
la section suivante nous présenterons quelques solutions pratiques possibles.
2.7.8 M ÉTHODES PRATIQUES DE
GESTION DE DÉPENDANCES
Nous allons terminer l’étude du phénomène de dépendance à travers la
présentation de deux méthodes différentes de gestion des dépendances. Il
s’agit de méthodes développées pour des usages particuliers mais qui peuvent
éventuellement être utilisées tout aussi bien dans d’autres contextes. Notre objectif primaire a été la simplicité des solutions, de manière à permettre une implémentation facile et la réduction au minimum de la charge supplémentaire
qu’ajoute la gestion de dépendances aux autres opérations de traitement textuel. Il est également intéressant à noter que toutes les deux méthodes peuvent
être réalisées avec l’indication des dépendances aussi bien à l’intérieur des
textèmes qu’à l’extérieur, dans le contexte.
162
PARAMÈTRES
DE CONDITION ET TYPOGRAPHIE DYNAMIQUE
La méthode que nous allons présenter a déjà été décrite dans l’article [14]
de l’auteur, dans une forme légèrement différente, à propos de la technique
de typographie dynamique (voir p. 126).
L’idée principale de la méthode consiste à associer un paramètre de condition à chaque propriété de textème qui participe à une dépendance. Dans un
cas général, on peut considérer ce paramètre de condition tout simplement
comme un identifiant unique de la dépendance. Nous allons représenter ici
les paramètres de condition par des symboles αi et βi où l’indice i est un entier
incrémenté à l’introduction de chaque nouvelle dépendance afin d’étiqueter
celle-ci de manière unique, et la distinction entre α et β se justifie par le fait
que la relation de dépendance n’est pas symétrique : α indique les propriétés
sources et β la propriété qui dépend de celles-ci.
Le fait que le paramètre de condition soit « associé » à une propriété textuelle n’entraîne pas forcément son stockage au sein du textème : il est tout
aussi possible qu’il fasse partie du contexte, en indiquant à son côté l’indice
du textème et la propriété auxquels il appartient :
α(i, {φA (tA ), ..., φM (tM )}) → β(i, φN (tN ))
En comparant cette formule avec la description générale offerte par la formule
en page 157, il est clair qu’au fond elles décrivent exactement les mêmes
informations.
Lorsque les paramètres de condition sont intégrés dans les textèmes, attachés à leurs propriétés correspondantes, leur seul argument est l’identifiant
unique « i », le reste étant devenu redondant. Dans nos exemples suivants,
pour des raisons de clarté, nous adopterons cette dernière approche.
char = 0041 (A) [α1 ]
font = lmr [α1 ]
glyphID = 40 (A) [β1 ]
Ici, la relation α1 -β1 indique la dépendance
{φchar (i) = 0041, φfont (i) = lmr} → φglyphID (i) = 40
De même, dans la chaîne
char = 0041 (A) [α1 ]
font = lmr [α1 , α3 ]
glyphID = 40 (A) [β1 , α3 ]
char = 0056 (V) [α2 ]
font = lmr [α2 , α3 ]
glyphID = 61 (V) [β2 , α3 ]
kern = −0.07em [β3 ]
les relations α1 -β1 et α2 -β2 sont indicatrices du même type de dépendance
caractère-glyphe alors que α3 -β3 indique la dépendance de la propriété de
crénage par rapport aux glyphes « A » et « V ».
Un effet secondaire de cette façon d’indiquer les dépendances dans les Nécessité d’indiquer
textèmes est que les références représentées par les indices numériques sont la distance
incapables d’indiquer la distance entre textèmes. En d’autres termes, les pa- entre textèmes
ramètres de condition tels que nous les employons dans l’exemple sont insensibles à l’insertion ou à la suppression de textèmes entre ceux déjà en
163
dépendance. Ce comportement peut être un avantage ou un inconvénient selon le cas ; dans notre dernier exemple, l’insertion d’un nouveau glyphe — et
donc d’un nouveau textème — entre le « A » et le « V » :
char = 0048 (A) [α1 ]
font = lmr [α1 , α3 ]
glyphID = 40 (A) [β1 , α3 ]
char = 0048 (B)
font = lmr
glyphID = 41 (b)
char = 0056 (V) [α2 ]
font = lmr [α2 , α3 ]
glyphID = 61 (V) [β2 , α3 ]
kern = −0.07em [β3 ]
devrait invalider le crénage dans le troisième textème, un fait que ce type
particulier de référencement n’est capable d’indiquer.
Un emploi particulièrement intéressant des paramètres de condition est la
typographie dynamique, présentée brièvement en section 2.4.7, p. 126. Rappelons l’exemple du mot « affiné » dont plusieurs variantes ont été calculées à
travers la composition-décomposition de ligatures, les variantes stylistiques et
les césures :
c = 61 (a)
font = lmr
g=a
Utilité des paramètres
de condition
pour la typographie
dynamique
c = 66 (f)
font = lmr
g=f
g2 = ffi
g3 = ff
font = lmr
g=g2 = ∅
c = 66 (f)
font = lmr
g=f
g2 = ∅
g3 = fi
c = 69 (i)
font = lmr
g=i
g2 = ∅
font = lmr
g=g2 = ∅
c = 6e (n)
font = lmr
g=n
c = e9 (é)
font = lmr
g=é
g2 =
Plus que jamais, il est essentiel d’indiquer les contraintes subordonnées à l’utilisation des glyphes alternatifs, comme par exemple le fait que la présence de
la césure empêche la composition de la ligature « ffi », qu’il faut interdire la
composition simultanée de « ff » et de « fi », etc. À l’aide de paramètres conditionnels, les dépendances qui concernent les glyphes alternatifs s’indiquent de
la manière suivante24 :
c = 61 (a)
font = lmr
g=a
c = 66 (f)
font = lmr
g=f
g2 = ffi
[α1 ]
g3 = ff
[α2 ]
c=∅
font = lmr
g=[α3 ]
g2 = ∅
[β1 , β2 ]
c = 66 (f)
font = lmr
g=f
g2 = ∅
[β1 , β2 ]
g3 = fi
[α4 ]
c = 69 (i)
font = lmr
g=i
g2 = ∅
[β1 , β4 ]
c=∅
font = lmr
g=[α5 ]
g2 = ∅
c = 6e (n)
font = lmr
g=n
c = e9 (é)
font = lmr
g=é
g2 =
[α6 ]
Afin de comprendre comment on obtient les dépendances de l’exemple
précédent, et pourquoi certaines autres dépendances ne sont pas marquées,
il est essentiel de savoir en détail ce qui se passe lors des différentes étapes
de composition de texte. En supposant l’emploi d’une fonte intelligente (telle
qu’OpenType), initialement les seules propriétés de glyphe présentes dans les
textèmes sont les glyphes « par défaut » (indiqués par la table cmap de la fonte)
et dont le nom de propriété est tout simplement « g » dans notre exemple. Lors
de l’application des lookup de la table GSUB au texte, on suit le principe de
composer en même temps toutes les variantes possibles. Ainsi, en arrivant au
premier glyphe « f », deux glyphes alternatifs sont disponibles : les ligatures
« ffi » et « ff ». On marque donc ces variantes, mais non le glyphe par défaut,
24
Notre façon d’indiquer les dépendances dans cet exemple — à l’aide de paramètres αi -βi
— diffère légèrement de celle que nous avons employée dans l’article [14], d’une part, afin de
rester conformes à la notation déjà introduite dans la présente section, d’autre part, parce que
nous trouvons cette nouvelle notation à la fois plus logique et plus facile à mettre en œuvre.
164
par α1 et α2 (en incrémentant l’indice à l’introduction de chaque nouveau
paramètre). La composition de ces ligatures entraîne cependant l’inclusion de
glyphes « vides » dans les textèmes suivants, que l’on marque par β1 et β2 .
Ayant épuisé les possibilités dans ce textème, on passe au textème suivant qui
représente le trait de césure. Le mot peut se composer avec ou sans césure ;
on marque la première éventualité par α3 , dont nous montrerons l’intérêt plus
tard. C’est en appliquant ces mêmes principes aux textèmes suivants que l’on
obtient l’exemple précédent.
Le paragraphe ainsi composé contient toutes les césures, variantes et ligatures possibles, marquées par αi et leurs dépendances indiquées par βi .
Comment en extraire, simplement et rapidement, les différentes versions du
paragraphe ? En considrant tous les paramètres αi comme des variables logiques binaires, chaque version du paragraphe est sélectionnée de manière
unique par une combinaison légale de valeurs des variables logiques. Dans
notre exemple, chacune des six variables α1 , ..., α6 peut prendre vrai ou faux
comme valeur, ce qui a priori donne 26 = 64 combinaisons.
Elles ne sont cependant pas toutes des combinaisons légales. Par exemple,
on ne peut pas à la fois composer une ligature « ffi » (α1 ) et une ligature « fi »
(α4 ). Heureusement, le filtrage des combinaisons illégales est triviale à l’aide
des trois règles suivantes :
Les αi : variables
logiques binaires
Une méthode rapide
de calculer
les paragraphes
candidats légals
1. jamais deux variantes dans le même textème ne peuvent être choisies
simultanément ;
2. si αi est choisi (αi = 1), alors le glyphe marqué par βi doit également
être choisi, à cause de la dépendance ;
3. lorsque aucun glyphe alternatif n’est sélectionné dans un textème (par
exemple, α1 = 0 et α2 = 0), alors le glyphe par défaut est choisi automatiquement.
En suivant ces règles, 40 combinaisons parmi les 64 s’avèrent illégales, le mot
« affiné » possède donc 24 variantes (y compris des très improbables, comme
les quatre variantes doublement coupées : « af-fi-né »).
Remarquons que l’emploi des paramètres de condition dans le cadre de la
typographie dynamique est légèrement différent car il sert surtout à permettre
la sélection facile des versions du paragraphe lors de l’algorithme d’égalisation
des lignes. Néanmoins, une fois que le paragraphe a été composé, en supprimant des textèmes les variantes de glyphes non utilisées ainsi que leurs α∗
et β∗ correspondants, les dépendances indiquées que l’on finit par retrouver
dans le texte restent valables pour les usages subséquents.
Finalement, une remarque d’ordre général concernant l’implémentation
de la gestion de dépendances : aussi bien lors de la composition de paragraphe en typographie dynamique que lors de la simple modification d’une
valeur de propriété marquée par un paramètre αi , il est important d’un point
de vue implémentationnel de retrouver très rapidement dans le texte les propriétés dépendantes marquées par les βi . Même si les positions des textèmes
concernés ne sont pas explicitement indiquées dans le texte, l’application peut
très bien construire et maintenir en interne une table de correspondances entre
αi et la position des βi correspondants. Ceci est, bien évidemment, une forme
de contextualisation des paramètres de condition.
165
Optimisation :
indexation
des paramètres
de condition
LIENS : GESTION
DES DÉPENDANCES INTER-TEXTÉMIQUES
Contrairement à la méthode précédente, plus générale, celle que nous allons montrer par la suite n’adresse qu’un sous-ensemble des dépendances :
celles qui mettent en relation deux textèmes séparés. Par ceci, elle vise avant
tout à adresser la problématique de la violation de dépendances à travers l’insertion ou la suppression de textèmes dans la chaîne.
Texte brut ⇔ pas de
Dans le chapitre précédent, en section 1.8.8, nous avons défini le texte
dépendances brut par rapport à un usage donné comme une chaîne d’éléments textuelles
inter-textémiques (un monoïde libre) sur laquelle les opérations de cet usage ne préservent aucune structure de haut niveau. Cette définition met en valeur l’indépendance
mutuelle des éléments textuels, un critère objectif de la simplicité structurelle
du texte. La présence de dépendances entre textèmes signifie qu’une structure non-triviale est ajoutée au texte, et par conséquent celui-ci ne peut plus
être qualifié comme texte brut. C’est cette complexité que nous souhaitons
indiquer explicitement à l’aide de liens connectant les textèmes concernés.
DÉFINITION 15 (LIEN)
1. Dans notre représentation à strates, le lien est une relation (ti , tj ) entre
deux textèmes adjacents (|i − j| = 1, i et j étant des indices de position
dans la chaîne). En tant que telle, le lien est un élément de T4 .
2. Défini d’une façon plus « visuelle », le lien est une connexion orientée entre deux textèmes adjacents. Lorsqu’il existe une dépendance
φA (i) = vA → φB (i + 1) = vB entre les textèmes ti et ti+1 , alors le
lien entre les deux est dirigé vers ti+1 . Lorsque la dépendance est entre
deux propriétés contenues dans ti et ti+n , |n| > 1 (les deux textèmes ne
sont pas adjacents), alors on introduit n − 1 liens orientés vers ti+n afin
d’interconnecter tous les textèmes intermédiaires.
La raison pour laquelle les textèmes intermédiaires sont également connectés par le lien est la rareté des « interactions distantes » où il existe une dépendance entre propriétés lointaines (c’est le cas des voyelles scindées de certaines écritures du Sud-Est asiatique) et la rareté encore plus prononcée des
cas où les signes intermédiaires ne font pas également partie de la dépendance.
Liens orientés
Lorsqu’il existe une dépendance depuis ti vers tj mais aussi depuis tj
et non orientés vers ti , alors on parle de lien non orienté. Ce type de lien peut être utilisé
non seulement pour indiquer qu’il existe des dépendances dans les deux sens
mais aussi lorsque l’orientation du lien n’est pas importante. Par exemple, on
a intérêt de représenter la dépendance qui résulte d’un crénage à l’aide d’un
lien orienté :
font = lmr
glyph = A
t
font = lmr
glyph = V
kern = −0.08em
car la modification du deuxième textème n’a aucun effet sur le premier. Par
contre, dans l’exemple suivant
166
c = 61 (a)
g=a
font = lmr
c = 66 (f)
g = ffi
font = lmr
p
c = 66 (f)
g=∅
font = lmr
p
c = 69 (i)
g=∅
font = lmr
c = 6e (n)
g=n
font = lmr
c = e9 (é)
g=e
font = lmr
p
c=∅
g=´
font = lmr
on trouve des dépendances bidirectionnelles aussi bien entre les trois composants de ligature qu’entre le glyphe de base et l’accent, l’emploi de liens non
orientées est donc justifié.
Les liens peuvent très facilement être indiqués dans une chaîne de tex- L’implémentation
tèmes sans même devoir étendre notre modèle de texte. Pour mettre en place des liens
un lien, il suffit d’inclure une propriété (φlien_droite = vrai) ou (φlien_gauche =
vrai) dans le textème concerné, selon son orientation. Un lien non orienté est
réalisé entre les textèmes ti et ti+1 par une propriété de lien droite dans ti et
une propriété de lien gauche dans ti+1 . Bien évidemment, les liens peuvent
être contextualisées sans problème ; le lien n’étant en fait qu’un cas spécial de
la dépendance telle qu’elle est représentée en page 157 :
lien(ti±1 , ti ) ⇔ ∃A, ..., N t.q. dep(φN (ti±1 ), {φA (ti ), ..., φM (ti )})
Les liens sont particulièrement utiles pour marquer les ligatures et d’autres
groupes de textèmes fortement liés, comme par exemple un cluster de signes
indiens réordonnés ou des signes assemblés de composants graphiques élémentaires. Nous les avons employés pour les mêmes raisons dans le logiciel
Ω2 (cf. section 3.2.2).
2.7.9 SYNTHÈSE DE L’ANALYSE DES
DÉPENDANCES
ET DES SOLUTIONS PROPOSÉES
Dans cette section nous avons examiné le phénomène de dépendance qui
lie les valeurs de certaines propriétés dans le texte. Nous avons pu comprendre
que ce problème n’était en réalité qu’un cas particulier d’un phénomène plus
général, et, par sa généralité, omniprésent dans les différents systèmes de représentation des connaissances. Qu’il soit question de conception de bases
de données ou de conception orientée objet, la compréhension, la prévention
et la gestion des dépendances entre données est un problème incontournable.
Dans cette thèse, nous avons voulu examiner par quels moyens et jusqu’à quel
point il est possible de détecter la dépendance de manière automatique dans
le cadre de la modélisation textuelle. Nous avons trouvé qu’en face d’un ensemble de base de signes et de combinaisons de signes (T0 ) non restreint, et
par conséquent énorme, la notion de dépendance dans sa généralité — que
nous avons réussi à formaliser sous le nom de dépendance extensionnelle —
ne peut être exploitée en pratique. Nous avons donc restreint notre intérêt aux
dépendances d’origine algorithmique, qui montrent désormais un bon potentiel de gestion automatique.
Quant aux approches préventives ou correctives de l’incohérence au sein
du texte, nous avons voulu éviter d’adopter une solution « toute faite » disponible dans la littérature (dans un contexte d’intelligence artificielle, par
exemple), car la difficulté majeure était beaucoup moins de trouver diverses
méthodes de gestion de dépendances mais plutôt de garder notre modèle le
167
plus simple que possible. Le texte étant une forme de communication si basique, nous tenons à éviter que sa complexification n’introduise plus de problèmes qu’elle n’en puisse résoudre. Dans cette optique, nous avons proposé
plusieurs méthodes — suppression des propriétés, paramètres de condition,
liens — qui peuvent être ou ne pas être combinées avec les différents usages
selon l’équilibre que l’on souhaite atteindre entre puissance et simplicité.
168
CHAPITRE 3
RÉALISATIONS INFORMATIQUES
DE MODÈLES DE TEXTE EN TEXTÈMES
Le chapitre précédent a été consacré à la construction d’un cadre formel
de modélisation, à l’aide duquel nous avons conçu ce que nous avons appelé
un modèle de texte fondé sur le concept de textème. En réalité, comme nous
avons déjà remarqué, ce modèle en textèmes ne peut être considéré comme
un modèle particulier prêt à être implémenté, mais plutôt comme une base
théorique au-dessus de laquelle on met en œuvre des modèles concrets qui
s’adaptent à des usages et à des contraintes technologiques variés. En d’autres
termes, le modèle en textèmes est une famille particulière de modèles conçue
par l’intermédiaire du cadre formel à strates, à son tour capable de se décliner
en une multitude de réalisations potentielles simples ou complexes, suivant
les besoins.
Dans le présent chapitre, nous arrivons enfin aux considérations d’implémentation qui permettent d’évaluer les différents aspects de cette famille de
modèles en textèmes d’un point de vue d’ingénierie informatique. Les idées
théoriques seront confrontées aux contraintes de réalisation, il sera question
de structures de données, d’économie de stockage, de complexité algorithmique et de compatibilité avec les modèles existants.
En comparant les modèles en textèmes au codage Unicode, il ne faut
cependant pas se laisser tromper par la simplicité apparente de ce dernier.
Comme nous avons montré, derrière le rideau de la chaîne uniforme de codes
de caractère, d’une simplicité séduisante, se cachent des interdépendances,
des structures hiérarchiques et toute une base de données d’informations, sans
lesquelles le texte Unicode ne peut être manipulé ni affiché. Le modèle en textèmes n’est donc pas, ou du moins pas entièrement, responsable de la complexité qu’il semble introduire car il ne fait que ressortir et assumer ce qui est
une réalité de la représentation textuelle à laquelle le développeur informatique fait (ou aurait dû faire) déjà face depuis longtemps.
Il faut également ajouter qu’aujourd’hui, grâce à la capacité calculatoire et
de stockage des ordinateurs, les éventuels problèmes d’économie et de per- Puissance théorique
formance, bien que toujours importants, sont nettement moins décisifs que contre performance
dans les années 1960 ou 1970, lors de l’établissement des bases de la modélisation textuelle informatique à travers les notions de caractère, de fonte, etc.
Nous considérons que dans notre ère où la vidéo et l’audio numériques sont
omniprésentes, il est temps d’enfin consacrer plus d’attention à la souplesse,
à l’utilité, à la puissance des moteurs de représentation textuelle qui tournent
dans nos ordinateurs, éventuellement même au détriment de la simplicité de
169
leur implémentation ou aux considérations d’économie de stockage1 . Il suffit
tout simplement d’accepter que l’augmentation des calculs et de l’espace de
stockage est le prix à payer pour un modèle de texte plus versatile.
3.1
L’APPLICABILITÉ DU MODÈLE
AUX SYSTÈMES EXISTANTS
Ce que nous devons clarifier dans un premier temps est, à quoi servira le
modèle que nous souhaitons introduire ? Pour poser la question autrement :
pour quels pratiques et dans quels contextes est-il censé remplacer les modèles
actuels ? Plusieurs scénarios sont envisageables, en voilà trois voies possibles,
de la plus conservatrice à la plus ambitieuse :
Trois scénarios
d’application
du modèle
1. le modèle serait utilisé en tant que représentation interne dans des applications de manipulation de texte et de préparation de documents afin
de les rendre plus puissantes.
2. Le modèle serait appliqué dans des documents de représentation finale,
comme par exemple un « PDF étendu » où les glyphes seraient remplacés par des textèmes. Il pourrait aussi être employé dans des documents
de représentation d’échange tels que le format HTML, ou dans les documents d’entrée de logiciels de préparation de documents.
3. Le modèle de textèmes deviendrait un modèle de texte générique et
remplacerait la chaîne de caractères au niveau du système d’exploitation, dans les bibliothèques de base, etc., de préférence en gardant la
compatibilité avec le modèle antérieur, le modèle à chaînes de caractères.
Textèmes uniquement
La première approche est la plus simple à réaliser car, l’utilisation du moen interne dèle restant confinée à l’intérieur de l’application, il n’y a aucun problème
de compatibilité vers le monde extérieur à considérer. Néanmoins, certains
aspects du modèle — sa capacité d’adaptation aux différents usages textuels,
son extensibilité par des propriétés arbitraires — sont sous-exploités.
Documents en textèmes
Lorsque l’utilisation du modèle s’étend à certains types de document et
devient leur format textuel de fond, alors de nombreux usages nouveaux deviennent possibles : dans un document qui sert comme entrée d’un logiciel,
l’utilisateur peut enrichir le texte par des propriétés qui ensuite interviendront
dans le traitement. Un texte formaté en textèmes peut se retrouver dans un document de sortie à partir duquel l’utilisateur peut extraire aussi bien le contenu
d’origine que des informations de formatage. Cependant, puisqu’un format de
document numérique n’est autre qu’un moyen standardisé d’échange d’informations, l’utilisation de documents en textèmes présuppose l’existence d’une
représentation normative de ceux-ci, jusqu’au niveau de la représentation des
propriétés individuelles. Entre autres, il devient nécessaire de normaliser un
sous-ensemble bien défini (un « noyau dur ») de clés de propriété ainsi que les
valeurs possibles associées.
1
Comme le remarquent Plaice et Rowley dans [55] par rapport au même sujet mais de
manière plus frappante, « computers are for computing », les ordinateurs sont là pour que l’on
exploite leur capacité de calcul.
170
C’est en implémentant le modèle de textèmes au plus bas niveau (celui du
système d’exploitation et des bibliothèques de base de gestion textuelle) qu’il
pourra être exploité à son vrai potentiel, car cela rend la même interface de Support des textèmes
programmation accessible depuis toutes les applications. Fort heureusement, au niveau du système
le modèle en textèmes peut être parfaitement intégré derrière les coulisses d’exploitation
avec les modèles textuels de base courants qui reposent sur les chaînes de caractères Unicode : une chaîne de caractères Unicode peut être simulée de façon triviale par une chaîne de textèmes comportant une seule propriété, celle
de la valeur Unicode. Ainsi, on peut envisager une bibliothèque de gestion de
texte « combinée » dont la structure de données serait construite autour du modèle à textèmes mais qui soit accessible aussi bien par des méthodes anciennes
correspondant au modèle Unicode que par de nouvelles méthodes propres au
nouveau modèle. Il faut noter cependant que, le textème étant une structure
relativement complexe comparée à un simple code de caractère, le texte doit
être sérialisé lors de son passage entre applications (à travers le presse-papiers,
par exemple). De plus, certaines opérations textuelles, triviales sur des chaînes
de caractères (comme la comparaison de deux chaînes), peuvent devenir très
complexes sur des chaînes de textèmes, en termes de complexité calculatoire.
Ce chapitre couvrira en détail les trois niveaux d’implémentation que nous
avons envisagés en début de section. Le niveau « textèmes en interne » sera
présenté à travers une étude de cas consacrée au logiciel Ω2 , une version
étendue et modulaire (développée par l’auteur) du logiciel Ω. Les niveaux
« document en textèmes » et « textèmes dans le système d’exploitation » seront
étudiés sans avoir d’exemples de logiciels de démonstration implémentés.
3.2 IMPLÉMENTATION DU MODÈLE DE TEXTÈMES
DANS LE LOGICIEL Ω2
Le logiciel Ω, extension de TEX signée par John Plaice et Yannis Haralambous [54], propose deux nouveautés majeures par rapport à TEX : la compatibilité Unicode à travers la gestion de caractères multi-octets d’une part, et d’autre
part, l’introduction des ΩTP (Omega Translation Process), des machines à états
finis qui effectuent des transformations sur le texte d’entrée d’Ω.
Même si ces deux extensions permettent à Ω la création de documents
multilingues, elles ne sont pas suffisantes pour le support de certaines technologies plus modernes comme les fontes intelligentes, ni pour la création de
documents « interactifs » (dont on est toujours capable d’extraire le contenu,
c’est-à-dire le texte en caractères). Ces deux technologies n’existaient pas encore au moment de la conception initiale du modèle de texte interne de TEX
qu’Ω a repris au quasi-identique ; néanmoins, depuis les années 1990 ils sont
devenus indispensables. C’est (entre autres) à cause de ces lacunes que la
refonte du modèle de texte d’Ω est devenue inévitable.
Nous avons présenté le modèle de texte de TEX en section 1.5.1. La raison
de l’incompatibilité de celui-ci avec les fontes intelligentes est qu’au moment
de la création des nœuds de caractère, les codes des caractères d’entrée sont
substitués par des identifiants de glyphe venant de la fonte. Grâce à l’organisation particulière des fontes de TEX, les deux types de code y coïncident pour
171
Quelques lacunes d’Ω
Un point faible
du modèle de texte
de TEX
l’alphabet latin, ce qui permet ensuite d’effectuer la césure (qui est une opération d’usage linguistique) sur le texte en glyphes (qui correspond à l’usage
typographique). Avec d’autres formats de fonte (TrueType, OpenType, etc.), et
surtout dans le cas de fontes non-latines, cette approche ne fonctionne plus
car les codes de caractère et de glyphe sont distincts, ou si elle fonctionne, ce
n’est que grâce à des solutions bricolées comme les fontes virtuelles. La substitution des caractères par des glyphes entraîne donc une perte d’information,
le passage d’un usage à l’autre est à sens unique. C’est pour la même raison
que le document PDF de sortie de TEX ou d’Ω ne se prête à la recherche ou
à d’autres usages interactifs que si les codes de caractère et de glyphe coïncident, ou alternativement, si les codes de caractère peuvent être déduits à
partir des noms de glyphe, lorsque ceux-ci sont présents dans le document
et/ou dans la fonte (cf. section 1.5.2).
3.2.1 L E
Le remplacement
du nœud de caractère
par le nœud de textème
Caractère et glyphe
ensemble
dans le textème
Le nœud de textème
simplifie le modèle
considérablement
NŒUD DE TEXTÈME DANS Ω2
Le modèle de texte en textèmes permet d’effectuer les opérations de multiples usages sur le même texte simultanément. Nous avons procédé à l’extension d’Ω par le remplacement des nœuds de caractère par des nœuds de
textème [34]. Ceux-ci contiennent par défaut trois propriétés : le code de caractère, l’identifiant de glyphe et l’identifiant de fonte. Mis à part celles-ci, le
nœud de textème est une structure extensible par des propriétés arbitraires,
par l’intermédiaire d’une liste chaînée. Pour chaque propriété, la clé ainsi
que la valeur sont représentées par des chaînes de caractères. Nous avons
implémenté un ensemble de fonctions gestionnaires de textèmes (création, recherche, modification, suppression de propriétés, etc.) dans une bibliothèque
écrite en C.
Le code de caractère d’origine et l’identifiant de glyphe correspondant sont
inclus dans le nœud de textème dès sa création. Il y a deux avantages à garder
les deux informations côte-à-côte : d’une part, le texte en caractères reste disponible pour des opérations linguistiques subséquentes éventuelles (comme
la césure). D’autre part, le texte d’origine en caractères peut ensuite être inclus
dans le document de sortie, ce qui permet la création de documents formatés
dont le contenu textuel peut être extrait (ce qui est un critère de l’interactivité
du document). C’est en effet une méthode robuste qui permette le passage à
partir de la représentation finale vers la représentation d’échange, étant donné
que le nommage de glyphes n’est pas toujours fiable (cf. section 1.5.2).
Un effet secondaire et bienvenu de l’introduction des textèmes est la simplification de la liste de nœuds : il devient possible de réduire le nombre de
types de nœud (il en existe une vingtaine) en stockant certaines informations
en tant que propriétés de textème. Ainsi, les nœuds de pénalité, de crénage ou
de glue peuvent devenir des propriétés dans le textème contenant le glyphe
précédent. La conversion du nœud de glue en propriété a l’avantage de garder des blancs explicites dans le texte. Les nœuds de glue de TEX et d’Ω sont
convertis en opérateurs de déplacement horizontal (ou vertical dans du texte
composé verticalement) dans le document DVI de sortie et par conséquent
dans les documents PostScript et PDF. Ceci rend difficile l’extraction efficace
du contenu textuel, car distinguer un déplacement qui résulte d’un vrai es172
pace et un autre qui correspond, par exemple, à un crénage n’est possible
qu’à travers des approches heuristiques.
3.2.2 L A
GESTION DES DÉPENDANCES DANS Ω2
Dans Ω2 nous avons choisi d’indiquer les dépendances entre textèmes à Liens dans Ω2
l’aide de liens (cf. p. 166). Ceux-ci peuvent, entre autres, indiquer qu’une
correspondance multiple-à-un (un-à-multiple, multiple-à-multiple) existe entre
caractères et glyphes d’une chaîne, dans lequel cas sont des textèmes à glyphe
ou à caractère vide sont employés dans la liste de nœuds. Les liens permettent
d’expliciter les correspondances dans la chaîne, ce qui est nécessaire pour
deux raisons. Premièrement, dans le document PDF de sortie, les mêmes
correspondances doivent être indiquées afin que l’extraction du contenu (par
copier-coller, par exemple) puisse se faire correctement dans le logiciel de visualisation (Adobe Reader). Deuxièmement, puisque les nœuds de ligature de
TEX et d’Ω sont remplacés par des nœuds de textème dans Ω2 , un moyen alternatif est nécessaire pour indiquer à l’algorithme de paragraphage la présence
d’une ligature que celui-ci peut potentiellement briser par une césure. Plus
généralement, toute règle de substitution ou de positionnement de glyphes
contextuelle de la forme
g1 g2 ...gn → action
où n > 1, et qui puisse être définie, entre autres, par une fonte intelligente,
nécessite l’interconnexion des textèmes t1 ...tn par des liens, puisqu’une coupure de ligne éventuelle à un endroit quelconque entre t1 et tn entraîne l’invalidité de l’action déterminée par la règle contextuelle. Dans un tel cas, le
lien indique au moteur typographique que les deux lignes concernées (avant
et après la coupure) peuvent potentiellement contenir des informations invalides et doivent donc être recalculées. Par exemple, une règle de substitution
contextuelle chaînée OpenType telle que
a f ’ i’ → fi
où les glyphes à remplacer ont été marqués par des apostrophes et le glyphe
« a » appartient au contexte, les trois textèmes doivent être connectés par des
liens au cas où la ligne serait coupée entre le « a » et le « f ».
3.2.3 M ODULES ET
TEXTÈMES
Mis à part la refonte de son modèle de texte, Ω2 innove par sa modularité : comme expliqué dans [34], des processus externes peuvent être appelés
à trois moments précis lors de la composition, à savoir : sur les listes de token
(comme pour les ΩTP), sur les listes de nœuds avant le paragraphage, et enfin sur les nœuds correspondant aux lignes candidates lors du paragraphage.
Ces modules servent à exécuter différents types d’opérations sur le texte interne : traitements linguistiques ou typographiques, application des règles de
substitution et de positionnement de fontes intelligentes, etc. Jusqu’à présent,
uniquement le deuxième type d’appel externe a été implémenté.
La communication entre Ω2 et les modules est réalisée en XML : les listes Sérialisation en XML
de nœuds correspondant aux paragraphes sont sérialisées, chaque type de de la liste de nœuds
173
nœud ayant son élément équivalent en XML, y compris les nœuds de textème. Un exemple simple de liste de nœuds en XML se trouve en fig. 3.1.
Après un préambule (contenant la liste de fontes utilisées par le document),
un nœud quésaco (whatsit) et un nœud de liste horizontale, on y trouve deux
nœuds de textème représentés par des éléments <t>. Chaque sous-élément
<p> correspond à une propriété, dans notre cas des propriétés de caractère, de
glyphe et de fonte. Les attributs linkl et linkr indiquent éventuellement des
liens entre textèmes (cf. pp. 166 et 173).
Le module externe peut bien évidemment modifier la liste de nœuds, entre
autres par l’insertion de nouvelles propriétés dans les textèmes :
<p n="clé">valeur</p>
Ces propriétés peuvent ensuite être prises en compte par d’autres modules ou
par le moteur de composition d’Ω2 . Grâce à la syntaxe XML et au fait que les
modules sont implémentées en tant qu’exécutables à part entière, un module
peut être implémenté en n’importe quel langage de programmation, même
comme simple transformateur XSL.
3.2.4 T EXTÈMES DANS
LA SORTIE D ’Ω2
Le fait d’ignorer les caractères stockés dans les textèmes afin de créer une
sortie DVI classique qui ne contienne que des glyphes diminuerait largement
l’intérêt de passer à un modèle de texte en textèmes. Pour cette raison, nous
avons conçu un format DVI légèrement altéré (et incompatible avec le format
ancien) qui garde le code de caractère à côté du code de glyphe correspondant. Les liens gérés par Ω2 permettent (au moment de la création du DVI)
d’indiquer explicitement la correspondance entre caractères et glyphes lorsΩ2 génère qu’il ne s’agit pas de correspondance un-à-un. Ensuite, une version modifiée
des documents PDF du convertisseur dvipdfmx génère des documents PDF contenant des couples
interactifs caractère-glyphe à travers l’opérateur PDF ActualText (cf. section 1.7.3).
Ainsi, on obtient des PDF dont le contenu textuel est accessible, quels que
soient le système d’écriture et la technologie de fonte utilisés, ce qui est rarement le cas des documents générés par les différents manifestations de TEX.
Bien que ceci n’a pas été réalisé, il serait facile d’optimiser la sortie PDF de
sorte qu’elle utilise par défaut une table ToUnicode pour les correspondances
glyphe-caractère et qu’elle ne recoure à l’opérateur ActualText que si le caractère proposé par ToUnicode ne correspond pas à celui indiqué par le fichier
DVI.
3.2.5 O PTIMISATIONS DE
LA GESTION DES TEXTÈMES DANS Ω2
Les besoins en mémoire
Dans Ω, un nœud de caractère n’occupe que 8 octets sur une architecture
d’Ω2 à 32 bits : deux octets pour le code de glyphe, deux octets pour l’identifiant de
fonte, et quatre octets pour le pointeur vers le nœud suivant de la liste, ce qui
correspond à un « taux d’efficacité de stockage » de 50% (la taille des données
utiles divisée par l’espace de mémoire total occupé). Le nombre de propriétés
par textème n’étant pas prédéfini, le nœud de textème d’Ω2 est par définition
une structure de données extensible, implémentée à l’aide d’une liste chaînée. Afin de réduire le temps d’accès ainsi que la mémoire occupée par les
174
<?xml version="1.0"?>
<buffer version="0.1">
<preamble>
<fontlist>
<font id="51" name="ptmr"
size="1310720"/>
<font id="52" name="pala"
size="655360"/>
...
</fontlist>
</preamble>
<nodelist>
<!-- whatsit node -->
<wha st="6" intpnl="0" brkpnl="0"
pardir="0">
<lbl></lbl><lbr></lbr>
</wha>
<!-- hlist node -->
<hls wd="1310720" dp="0" ht="0"
shift_amount="0" gse="0" gsi="0"
go="0" dir="0">
</hls>
<!-- texteme node -->
<t linkl="0" linkr="0">
<p n="c">74</p> <!-- char: L -->
<p n="g">12</p> <!-- glyph -->
<p n="f">52</p> <!-- font -->
</t>
<t linkl="0" linkr="0">
<p n="c">101</p> <!-- char: o -->
<p n="g">142</p>
<p n="f">52</p>
</t>
...
</nodelist>
</buffer>
FIG. 3.1 – Un début de liste de nœuds Ω2 sérialisé en XML, syntaxe dans
laquelle communiquent Ω2 et ses modules externes.
175
propriétés le plus souvent utilisées, les propriétés de caractère, de glyphe et
de fonte, ainsi que les liens, sont codés « en dur » dans chaque textème : elles
sont présentes par défaut, ce qui les rend directement accessibles. Grâce à
cette optimisation, un nœud de textème occupe 36 octets sur une architecture
à 32 bits lorsqu’aucune propriété à part celles codées en dur n’y est présente :
le taux d’efficacité est de 34%. Ce chiffre pourrait très facilement être réduit à
27 octets si l’on interdisait les codes de caractère, de glyphe et de fonte plus
larges que 16 bits (23% d’efficacité). En sachant qu’Ω2 n’a à aucun moment
plus de deux pages de texte en mémoire (car il génère le document de sortie
page par page), l’augmentation en mémoire consommée par rapport à Ω ne
dépasse pas les 280 kilooctets environ, en comptant 36 octets par textème et
5000 textèmes par page (ce qui correspond à des pages extrêmement denses).
Optimisations diverses
Le stockage en mémoire interne des propriétés non codées en dur a également été optimisé, afin de réduire l’espace consommé par les clés de propriété
récurrentes. Au lieu de garder celles-ci en tant que chaînes de caractères dans
les textèmes, on emploie des identifiants de type entier, et des tables de hâchage qui permettent de retrouver très rapidement les clés textuelles à partir
des identifiants numériques et vice versa.
Représenté en XML, le même nœud de textème (uniquement avec les propriétés codées en dur) occupe environ 70 octets selon nos statistiques (environ 12% d’efficacité), et ceci en atteignant un maximum d’économie sur les
longueurs de noms d’élément et d’attribut, comme dans l’exemple suivant :
<t l="0" r="0"><p n="c">74</p><p n="g">12</p><p n="f">52</p></t>
Néanmoins, en codant les propriétés sous forme d’attributs, la longueur totale
d’un élément de textème peut se réduire davantage :
<t l="0" r="0" c="74" g="12" f="52"/>
La verbosité relative de la représentation XML pose des problèmes lorsque
la communication entre Ω2 et le module externe se fait à travers un fichier
tampon sur le disque dur : la taille effective du document XML généré est en
général 50 à 100 fois plus élevée que le nombre de caractères contenus dans
le paragraphe communiqué au module. Puisque la lecture-écriture sur disque
est le goulot d’étranglement de loin le plus important en termes de vitesse
de traitement, une compression préalable des données XML nous paraît une
solution souhaitable. En revanche, l’abandon du format XML en faveur d’un
format binaire signifierait une perte de souplesse significative quant à la diversité des outils et des moyens par lesquels les modules externes peuvent être
implémentés.
3.3
DOCUMENTS EN TEXTÈMES
La création de formats de documents en textèmes suppose une approche
conceptionnelle et normalisatrice face aux problèmes d’implémentation, davantage que la création d’applications qui adoptent le modèle de textèmes en
interne. Alors que les usages internes du texte sont bien circonscrits et a priori
restreints, un document se prête, par sa nature, à des pratiques très variées :
176
– il est lu ou consulté par l’utilisateur (à travers une interface) ;
– il est rédigé ou modifié (plus ou moins librement) par l’utilisateur ;
– il est la source d’une opération de traitement textuel ;
– il est le résultat d’une telle opération.
Un des avantages déclarés du modèle en textèmes (p. 111) est sa capacité
de s’adapter à plusieurs représentations textuelles, et de fusionner ainsi les
représentations d’échange et finale du même texte2 . Si les différentes manifestations d’un même texte partagent le même modèle, alors il devient essentiel
de catégoriser les propriétés y apparaissant selon les usages auxquels elles appartiennent, selon le type de leurs valeurs potentielles, selon les clés qui les
identifient, etc. De même, l’accès en lecture ou en écriture au document par
l’utilisateur suppose des modes d’accès normalisés, indépendamment du degré d’abstraction qui peut exister entre la structure du modèle et les usages
offerts par l’interface du logiciel d’édition.
Pour les raisons évoquées, la création d’un standard centralisé qui définisse
et catégorise les propriétés de textème nous paraît essentielle. L’existence d’un
tel standard ne contredit en rien à l’intensionnalité de l’ensemble des propriétés : tout en maintenant la possibilité pour tout utilisateur ou application
de créer de nouvelles propriétés et de les intégrer dans son texte, l’avantage
d’adhérer à une convention sur l’emploi de certaines propriétés récurrentes
est indéniable.
3.3.1 U N
CADRE DE NORMALISATION DES PROPRIÉTÉS
À TRAVERS UNE DESCRIPTION BASÉE SUR RDF ET
Les opérations majeures
effectuées
sur un document
Le document
en tant que médium
d’échange nécessite
la normalisation
des propriétés
OWL
Nous nous permettons d’insister sur le fait que la normalisation que nous
prévoyons n’a pas pour but de restreindre l’usage des propriétés à un ensemble
fermé. Au contraire, la méthode que nous allons présenter établit non seulement une description formelle d’un « noyau dur » de propriétés a priori désignées mais aussi un cadre formel qui permet à tout usager de créer et de
décrire de nouvelles propriétés avec la même rigueur formelle. Cette description — à condition d’être disponible en ligne — permettra à des applications
tierces d’interpréter et de manipuler des textes contenant de telles propriétés,
ce qui augmente considérablement l’interopérabilité entre applications.
Il est clair que nous faisons face à un problème pratique qui concerne, une
fois de plus, la représentation de connaissances : nous avons un ensemble ouvert de ressources — les propriétés — que nous souhaitons décrire de manière
formelle et extensible. Plus particulièrement, nous cherchons à formaliser les
informations suivantes :
1. l’identification globale et unique des clés de propriété. Toute propriété Les informations
se trouvant dans un texte en textèmes doit posséder une identité non- à normaliser
ambiguë. Puisqu’un texte peut à tout moment être enrichi par de nouvelles propriétés, il se peut que deux usagers (ou applications) créent
indépendamment deux propriétés qui s’identifient par la même clé, que
2
Bien entendu, la fusion ne peut être complète à tous les niveaux du document électronique,
ne serait-ce que car nos modèles ne sont pas concernés par les aspects globaux de mise en
page.
177
cet identifiant soit numérique ou textuel. Par exemple, la propriété accent introduite par un usager chinois peut indiquer les quatre accents
mandarins, alors qu’un usager russe peut utiliser exactement la même
clé pour marquer la syllabe accentué de certains mots russes. Afin d’éviter les collisions de nommage de ce genre, il faut assurer l’unicité de
chaque clé de propriété de manière globale.
2. Les catégories fonctionnelles auxquelles appartient une clé donnée.
Dans le chapitre où nous avons introduit les bases théoriques de notre
modèle de texte nous avons catégorisé les propriétés d’abord par clé
(strate T2 ), puis les clés par usage (strate T3 et éventuellement T4 ). Ces
dernières catégories sont essentielles car elles donnent une première interprétation sémantique des clés de propriété (même si cette méthode
d’interprétation reste rudimentaire). En pratique, la connaissance de l’appartenance d’une propriété donnée à une catégorie peut aviser les logiciels quant à l’emploi d’une propriété inconnue, sans avoir recours à
la consultation de l’utilisateur. Par exemple, le logiciel peut décider si
la propriété en question est pertinente ou non par rapport à l’usage actuel, si elle peut être supprimée ou non, si l’utilisateur peut ou non être
autorisé à la modifier, etc.
3. Les valeurs pouvant être associées à une clé donnée. Il s’agit d’introduire, si nécessaire, le typage des valeurs de propriétés (entier, réel, énumération, etc.) et la possibilité éventuelle de l’imbrication des propriétés
(cf. section 2.6.2).
4. En général, des relations intensionnelles entre propriétés. Nous visons
à formaliser les informations que l’on possède des propriétés et qui
se trouvent dans les strates supérieures à T1 et à T2 . Autrement dit, il
s’agit de définir l’intension de la propriété : son éventuelle équivalence
à d’autres propriétés, sa description textuelle destinée à l’utilisateur, etc.
La catégorie fonctionnelle déjà mentionnée fait également partie de l’intension de la propriété.
Application
Le problème que nous avons entrepris à résoudre — donner une desde technologies cription formelle des informations que nous venons de présenter, et ceci de
existants à un problème manière qu’elle soit algorithmiquement exploitable — est loin d’être concepclassique tuellement nouveau. Il existe des méthodologies et des outils informatiques
conçus et développés pour exactement ce genre de problèmes, entre autres
dans le cadre du Web sémantique. Sans vouloir prendre place dans le débat (souvent religieux) qui questionne la possibilité théorique et/ou pratique
d’une sémantisation générale du Web, nous reprendrons tout simplement
quelques outils informatiques fondamentaux de la représentation de connaissances, notamment RDF et le langage OWL. Puisqu’il s’agit de technologies
bien connues — qui font même partie des normes W3C —, au lieu d’une introduction détaillée, nous nous contentons de proposer au lecteur les documents
[56] et [53].
RDF ET OWL
L’intérêt particulier
de RDF
Bien évidemment, il serait également envisageable de se contenter d’une
approche descriptive plus générale et plus neutre que celle de RDF/OWL, par
178
exemple à travers un simple document XML dont nous fournirions le schéma,
comme fait d’ailleurs Unicode pour décrire sa base de données. Ce qui rend
RDF plus intéressant par rapport à notre problème particulier est justement
qu’il vise à résoudre exactement le genre de problème auquel nous faisons
face : qu’il propose un vocabulaire tout fait pour décrire nos ressources ainsi
que leur relations, qu’il offre un moyen naturel d’identification unique du
contenu décrit (à travers les URI et les espaces de nommage), et qu’il est
entouré d’outils informatiques déjà implémentés servant à interpréter les données ainsi décrites et à en déduire des inférences logiques de manière algorithmique.
RDF et ses schémas seraient suffisants pour définir et pour créer une onto- OWL
logie relativement simple de propriétés de textème. Ce que le langage OWL
peut offrir en addition à RDF (dont il est l’extension) sont la possibilité de
formuler des contraintes sur les données décrites (par exemple, une propriété
donnée ne peut avoir qu’une seule valeur, il s’agit donc d’une contrainte de
cardinalité), d’exprimer l’égalité entre deux éléments distincts (les propriétés arab_form et forme_arabe sont équivalentes), d’appliquer des opérations
ensemblistes sur des classes d’éléments (définir une catégorie de propriété
comme étant l’union ou l’intersection d’autres catégories), et ainsi de suite
[56, section 5.5]. Dans le schéma RDF/OWL que nous allons mettre en œuvre,
nous emploierons quelques éléments OWL sans pour autant réellement exploiter la richesse descriptive offerte par ce langage. Notre but n’est pas de
mettre sur la table une solution « clé en main » mais d’illustrer comment RDF
et OWL peuvent être appliqués à notre problème de normalisation des propriétés de textème.
DEUX
VISIONS DE MODÈLE
Les schémas RDF/OWL servent à définir un vocabulaire restreint, autre- Les schémas RDF/OWL
ment dit : un modèle, qui consiste principalement en des classes et des relations3 entre classes et/ou autres données. La conception de notre schéma
RDF/OWL — sa complexité, le choix des différents aspects du modèle de
texte à prendre en compte ou à négliger — a une profonde influence sur la
puissance avec laquelle les propriétés de textème individuelles pourront ensuite être décrites.
Notre point de départ est la considération selon laquelle la définition et la Schéma centralisé
description de nouvelles propriétés est une activité répartie parmi tous les uti- et descriptions réparties
lisateurs de documents et du Web. Afin de permettre l’interopérabilité de ces
définitions, l’utilisation d’un langage commun est essentiel. Nous fournirons
ce langage par le cadre formel d’un schéma RDF/OWL centralisé. Le même
schéma met en place le vocabulaire nécessaire pour décrire les catégories de
propriétés.
Les définitions des propriétés, des catégories et de l’appartenance des premières aux dernières se trouvent dans des documents RDF/OWL répartis sur le
3
Dans le jargon RDF, les relations qui interconnectent des classes et d’autres types de données s’appellent propriétés. Pour éviter une confusion inévitable avec les propriétés de textème
(définies en tant qu’instances de classes et non en tant que propriétés RDF), nous avons choisi
de les appeler relations dans cette thèse.
179
FIG. 3.2 – Un serveur central (tel que http://omega.enstb.org) stocke le
schéma RDF/OWL ainsi qu’un document RDF/OWL décrivant un ensemble
de propriétés « cœur ». Ce document, ainsi que des définitions d’autres propriétés réparties sur le Web, font recours à cet unique schéma.
Web. Chaque utilisateur souhaitant publier la définition d’une nouvelle propriété (voire d’une nouvelle catégorie) devra créer un tel document RDF/OWL,
en conformance avec le schéma central. En même temps, il serait sans doute
très pratique de publier sur le même serveur que celui du schéma central un
« ensemble cœur » de propriétés et de catégories qui couvrent les usages les
plus communs. Une telle distribution des définitions entre machines est illustrée en fig. 3.2. L’URL du schéma, http://omega.enstb.org/TextemePropertySchema.owl, sert non seulement à accéder à celui-ci mais également
comme espace de nommage du vocabulaire que le schéma définit. Les trois
URL des documents RDF/OWL de définition de propriétés, eux, joueront également le rôle d’espaces de nommage permettant l’identification unique et
globale des propriétés qu’ils décrivent.
Schémas répartis :
L’approche que nous venons de décrire suppose que l’ontologie des provers une sémantisation priétés — la structure et les relations entre propriété, nom de propriété, catotale du texte ? tégorie de propriété ; en un mot : les connaissances — sont décrites dans un
seul schéma central et que les documents RDF/OWL répartis décrivent les différentes propriétés en tant que ressources, sans qu’ils aient la possibilité de
raffiner ou d’étendre le schéma. Bien que l’on assure ainsi la compatibilité
des descriptions RDF/OWL réparties, on empêche, par contre, la formulation
d’autres connaissances sur les propriétés et les catégories que celles explicitement prévues par le schéma central.
Une vision plus audacieuse et plus proche de la philosophie du Web sémantique serait de permettre la création de schémas individuels répartis à
travers lesquels la description des nouvelles propriétés et catégories peut être
détaillée et adaptée à leurs futurs usages. Autrement dit, il s’agirait de permettre la création de nouvelles ontologies qui étendent l’ontologie centrale.
Par exemple, le créateur d’une nouvelle propriété forme_arabe pourrait décrire les quatres valeurs (initial, médian, final, isolé) individuellement, les lier
180
à d’autres ontologies linguistiques existants, et ainsi de suite.
Une extrapolation naturelle à laquelle nous sommes inévitablement ame- Textèmes
nés est l’application de la description RDF/OWL non seulement aux proprié- en tant que ressources
tés individuelles mais au texte entier : il s’agit de regarder les textèmes in- RDF
dividuels d’un texte comme étant des ressources RDF/OWL. Cette approche
paraît d’autant plus séduisante que la considération du texte comme une suite
de ressources RDF permettrait d’exprimer des relations (de dépendance, de
contexte, etc.) entre propriétés et entre textèmes d’une façon simple et naturelle. Ceci étant dit, aussi charmante que soit, d’un point de vue de cohérence
théorique, l’idée de décrire notre modèle de texte à tous ses niveaux par le
même cadre informatique de représentation des connaissances, nous devrons
la rejeter pour des raisons pragmatiques de simplicité d’implémentation. Les
documents dont chaque élément textuel est décrit par une ressource RDF sont
clairement au-delà de ce qui est aujourd’hui réalisable en pratique. Nous nous
tiendrons donc à l’architecture RDF que nous avons esquissée initialement,
comprenant un seul schéma central.
LE
SCHÉMA CENTRAL
Notre schéma RDF/OWL central contiendra les définitions suivantes (voir
fig. 3.3 pour le contenu du fichier RDF/OWL correspondant au schéma cidécrit) :
– la définition d’une classe TextemePropertyKey, avec une relation hasKeyName qui permet d’y associer un identifiant de clé. Les instances de
la classe TextemePropertyKey sont les éléments de la strate T2 (les clés
de propriété).
– La définition d’une classe TextemePropertyCategory qui modélise la Le schéma définit
catégorie de propriété. L’appartenance à une super-catégorie est réalisée une catégorisation
par une relation hasSuperCategory. Cette relation n’est pas fonctionnelle, il est donc possible qu’une catégorie hérite de multiples supercatégories.
– L’appartenance d’une clé de propriété à une catégorie est représentée
par une relation hasPropertyCategory dont le domaine est égal à
l’ensemble d’instances de la classe TextemePropertyKey et la portée
à celles de TextemePropertyCategory. Bien entendu, une propriété
peut appartenir à plusieurs catégories à la fois.
– Le type des valeurs associables à une clé de propriété doit être défini par
la relation hasValueType qui pourrait désigner, par exemple, un type
de données XML Schéma (XML Schema Datatype) en tant que ressource
RDF.
L’APPLICATION
DU SCHÉMA
: CRÉATION
DE DÉFINITIONS DE PROPRIÉTÉS
Comme nous avons expliqué, lorsqu’un développeur ou utilisateur crée
une nouvelle propriété qu’il souhaite ensuite inclure dans ses documents, il a
tout intérêt de décrire cette propriété à l’aide d’un fichier RDF/OWL. Ainsi, à la
réception du document utilisant la propriété en question, toute application sachant récupérer sur le Web sa description RDF/OWL et l’interpréter sera plus
apte à prendre des décisions vis-à-vis de l’usage de la propriété : de la sup181
<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [
<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">
<!ENTITY owl "http://www.w3.org/2002/07/owl#">
]>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns="http://omega.enstb.org/TextemePropertySchema.owl#"
xml:base="http://omega.enstb.org/TextemePropertySchema.owl">
<owl:Ontology rdf:about=""/>
<!-- CLÉS DE PROPRIÉTÉ -->
<owl:Class rdf:ID="TextemePropertyKey"/>
<owl:FunctionalProperty rdf:ID="hasKeyName">
<rdf:type rdf:resource="&owl;DatatypeProperty"/>
<rdfs:domain rdf:resource="#TextemePropertyKey"/>
<rdfs:range rdf:resource="&xsd;string"/>
</owl:FunctionalProperty>
<owl:ObjectProperty rdf:ID="hasValueType">
<rdfs:domain rdf:resource="#TextemePropertyKey"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasPropertyCategory">
<rdfs:range rdf:resource="#TextemePropertyCategory"/>
<rdfs:domain rdf:resource="#TextemePropertyKey"/>
</owl:ObjectProperty>
<!-- CATÉGORIES -->
<owl:Class rdf:ID="TextemePropertyCategory"/>
<owl:TransitiveProperty rdf:ID="hasSuperCategory">
<rdf:type rdf:resource="&owl;ObjectProperty"/>
<rdfs:domain rdf:resource="#TextemePropertyCategory"/>
<rdfs:range rdf:resource="#TextemePropertyCategory"/>
</owl:TransitiveProperty>
</rdf:RDF>
FIG. 3.3 – Le contenu du fichier http://omega.enstb.org/TextemePropertySchema.owl.
182
primer, de la cacher ou de l’afficher à l’utilisateur d’une manière conviviale,
etc.
Un tel exemple de fichier RDF/OWL se trouve en fig. 3.4 (voir fig. 3.5 pour
une représentation graphique). L’élément <owl:imports> indique au logiciel
interprétant ce fichier que le schéma auquel il s’adhère se trouve à l’URL précisé. Notre fichier exemple définit quatre catégories : linguistique, culturelle,
graphique et typographique, cette dernière étant une sous-catégorie de graphique. Le même document définit trois propriétés : Script, Color et Case, y
compris leurs noms de clé textuels, leurs catégories et leurs types de valeurs
associés. Ces derniers peuvent pointer vers des ressources diverses : vers des
définitions « XML Schema Datatype » ou vers des types définis au sein d’ontologies extérieurs (dans notre exemple, le type « casses typographiques » est de
ce genre).
RÉFÉRENCE
À L’ONTOLOGIE DEPUIS LE DOCUMENT
Dans les sections précédentes, nous avons décrit nos propriétés à l’aide
d’une ontologie RDF/OWL répartie sur le Web. Lors de l’édition d’un document en textèmes, il est essentiel que les propriétés employées soient identifiables en tant qu’éléments de cette ontologie. Par conséquent, chaque propriété dans le document doit être explicitement identifié en indiquant son
espace de nommage préalablement défini dans la description RDF/OWL correspondante. (Dans notre exemple, pour des raisons pratiques, nous avons
supposé que l’espace de nommage d’une propriété était identique à l’URL du
document RDF/OWL la décrivant.) Les applications de traitement textuel ayant
accès au Web pourront ainsi récupérer et analyser les descriptions RDF/OWL
de propriétés inconnues, en déduire leurs catégories d’usages et d’autres informations leur permettant soit de prendre des décisions automatiquement, soit
d’aider l’utilisateur en lui fournissant les informations récupérées.
USAGES
SUPPLÉMENTAIRES DE
RDF/OWL
Jusqu’ici nous avons utilisé RDF et OWL pour créer une ontologie de des- Ontologie de signes
cription de propriétés. Nous avons également fait allusion à une possibilité de d’écriture
considérer le texte comme étant une suite de ressources RDF/OWL. Même si
cette approche nous paraît forte intéressante, nous n’avons pas la possibilité
de l’explorer en détail dans le cadre de cette thèse. Par contre, ce que nous
ne manquerons pas d’examiner est la possibilité et l’intérêt de décrire un répertoire de signes d’écriture — tel que le codage Unicode — à l’aide d’une
ontologie RDF/OWL similaire qui se connecte, bien évidemment, à celle que
nous venons de définir. Nous reviendrons à cette idée en section 3.4.3.
3.3.2 O PTIMISATIONS AU
SEIN DES DOCUMENTS EN TEXTÈMES
Nous avons déjà considéré certaines méthodes d’optimisation par rapport
à l’implémentation réalisée au sein du logiciel Ω2 . Étant donné qu’Ω2 ne garde
jamais en mémoire plus de texte que la quantité de deux pages, l’optimisation
de la consommation de mémoire avait nettement moins d’intérêt que celle de
la rapidité de traitement. Un document, en revanche, est une ressource inerte
183
<?xml version="1.0"?>
<!-- ==================== DÉFINITIONS D’ENTITÉS ====================== -->
<!DOCTYPE rdf:RDF [ <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">
<!ENTITY typo "http://typo.nexistepas.org/Typo-Ontology#"> ]>
<!-- ====================== ESPACES DE NOMMAGE ======================= -->
<rdf:RDF
xmlns="http://localhost/CoreProperties.owl#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:tx="http://omega.enstb.org/TextemePropertySchema.owl#"
xml:base="http://omega.enstb.org/CoreProperties.owl">
<!-- ==================== IMPORTATION DU SCHÉMA ====================== -->
<owl:Ontology>
<owl:imports rdf:resource="http://omega.enstb.org/TextemePropertySchema.owl"/>
</owl:Ontology>
<!-- =================== INSTANCES DE CATÉGORIES ===================== -->
<tx:TextemePropertyCategory rdf:ID="CatLinguistic"/>
<tx:TextemePropertyCategory rdf:ID="CatCultural"/>
<tx:TextemePropertyCategory rdf:ID="CatGraphic"/>
<tx:TextemePropertyCategory rdf:ID="CatTypographic">
<tx:hasSuperCategory rdf:resource="#CatGraphic"/>
</tx:TextemePropertyCategory>
<!-- =============== INSTANCES DE CLÉS DE PROPRIÉTÉ ================= -->
<tx:TextemePropertyKey rdf:ID="PropScript">
<tx:hasKeyName>Script</tx:hasKeyName>
<tx:hasValueType rdf:resource="&xsd;string"/>
<tx:hasPropertyCategory rdf:resource="#CatLinguistic"/>
<tx:hasPropertyCategory rdf:resource="#CatCultural"/>
<tx:hasPropertyCategory rdf:resource="#CatTypographic"/>
</tx:TextemePropertyKey>
<tx:TextemePropertyKey rdf:ID="PropColour">
<tx:hasKeyName>Color</tx:hasKeyName>
<tx:hasValueType rdf:resource="&xsd;integer"/>
<tx:hasPropertyCategory rdf:resource="#CatGraphic"/>
</tx:TextemePropertyKey>
<tx:TextemePropertyKey rdf:ID="PropCase">
<tx:hasKeyName>Case</tx:hasKeyName>
<tx:hasValueType rdf:resource="&typo;Cases"/>
<tx:hasPropertyCategory rdf:resource="#CatTypographic"/>
</tx:TextemePropertyKey>
</rdf:RDF>
FIG. 3.4 – Le contenu du document http://omega.enstb.org/CoreProperties.owl qui définit les propriétés Script, Color et Case et les catégories linguistique, culturelle, graphique et typographique. Les entités définies en début
de document servent à abrévier les URL des espaces de nommage de notre
schéma.
184
FIG. 3.5 – Les classes du schéma RDF et leurs instances.
à laquelle on n’exige en général pas la possibilité d’accès aléatoire : qu’il
s’agisse d’un document déjà formaté (PDF) ou dans son état brut (HTML),
on suppose qu’il est d’abord lu et traité par un logiciel qui en crée sa propre
représentation interne. Par conséquent, lorsqu’il est question d’optimisation de
documents, on raisonne uniquement en termes d’espace de stockage occupé.
Dans la suite, nous examinerons donc les possibilités de réduire l’espace de
stockage des documents en textèmes.
Une suite de textèmes implémentée dans sa forme « brute » est très redondante car de nombreuses informations similaires se répètent textème par
textème :
– les clés de propriété ;
– des valeurs plus ou moins invariantes au long du texte ;
– des valeurs relativement complexes, comme par exemple la description
de la structure d’un logogramme chinois, même si non répétitives, occupent cumulativement un espace mémoire relativement important ;
– des textèmes entiers ayant exactement les mêmes propriétés (clés et valeurs) peuvent se répéter de nombreuses fois.
La clé de propriété est un identifiant sémantique unique qui réfère, d’après
le système proposé dans la section précédente, à une ressource RDF/OWL.
En tant que tel, conceptuellement, il est composé d’un identifant d’espace
de nommage et d’un identifant de ressouce à l’intérieur de ce dernier. Il faut
noter que le nom textuel de clé, tel que nous l’avons utilisé dans tous nos
exemples (comme par exemple arab_form ou glyph_id), n’a rien à voir avec
ces identifiants et sert principalement comme étiquette destinée à l’utilisateur
humain (et au lecteur du présent texte).
Il est donc envisageable de garder dans le document en textèmes un tableau qui met en correspondance le couple (espace de nommage, identifiant
de ressource) avec un simple identifiant numérique, unique au sein du docu185
Aspects redondants
d’un document
en textèmes
La clé de propriété
ment. C’est cette valeur à taille réduite qui servira comme clé de propriété
dans les textèmes.
Ontologie
Bien évidemment, pour garantir l’interprétabilité des différentes propriétés
dans le document textuelles du document même en l’absence de connexion au Web, il est tout à
fait possible d’inclure dans le document les données RDF/OWL les décrivant,
en forme compressée si nécessaire. L’inclusion de ces données n’augmente
pas considérablement la taille totale du document, à l’exception de documents
courts contenant un grand nombre de propriétés différentes.
Valeurs invariantes
En pratique, il arrive souvent que la valeur de certaines propriétés ne
change que très rarement ou pas du tout dans le document. Typiquement,
le système d’écriture, la couleur de glyphe, la fonte, le corps, etc., sont des
propriétés dont la valeur est relativement constante. Une manière d’optimiser
leur stockage est de les représenter non pas textème par textème mais chacun
en tant qu’un ensemble d’intervalles : en supposant que les textèmes du document sont numérotés (l’ordre choisi n’a pas d’importance), à chaque couple
clé-valeur on associe une suite d’intervalles :
(c, v) 7→ (d1 , f1 ), (d2 , f2 ), ..., (dn , fn )
Propriétés et relations
contextuelles
Indexation de valeurs
Indexation de textèmes :
retour au caractère ?
où à partir du textème tdi jusqu’au textème tfi la propriété identifiée par c
prend la valeur v. Lorsqu’une propriété donnée est présente dans tous les
textèmes du document (parce que, par exemple, tous les signes d’un document appartiennent à un système d’écriture donnée), et une certaine valeur
est beaucoup plus fréquente que les autres (parce que le document est écrit
presque exclusivement en latin), alors il est possible de considérer et de signaler explicitement la valeur par défaut de cette propriété et de n’indiquer que
les intervalles où la valeur diffère de celle-ci.
Lorsque le document en question possède des propriétés ou des relations
« contextuelles » (e.g., dépendances), celles-ci peuvent également être représentées à travers des intervalles. Rappelons qu’en section 2.5.2 nous avons
défini le contexte macroscopique comme étant l’ensemble de relations d’arité
supérieure, associées à des tuples de signes ou de textèmes (figures 2.9 sur la
page 132 et 2.10 sur la page 133). Il faut cependant faire attention aux deux sémantiques bien distinctes que peut représenter un intervalle (d, f ) de textèmes
donné : il peut autant désigner l’ensemble de textèmes entre les positions d
et f (où leur ordre n’a pas d’importance) que la relation de ces mêmes textèmes (où la relation compte). Autrement dit, dans le premier cas, la propriété
s’associe à chacun des textèmes de l’intervalle séparément, alors que dans le
second cas, elle s’associe à la chaîne même. Cette distinction doit être reflétée
par l’implémentation.
Lorsque les valeurs d’une propriété ne se répètent pas entre textèmes successifs mais elles occupent une quantité de mémoire relativement importante,
il est envisageable d’indexer l’ensemble de valeurs par une table externe et d’y
référer dans les textèmes individuels par ces indices. Cette technique n’est efficace que si le coût de l’indexation en termes d’espace occupé ne compense
pas le gain qu’elle apporte (les valeurs n’occupant que quelques octets n’ont
pas besoin d’être indexées).
Jusqu’ici, nous avons ignoré de prendre en compte une particularité fondamentale de l’écrit, à savoir que celui-ci est composé d’un ensemble fini de
186
latin_letter = A
case = upper
color = red
latin_letter = M
case = lower
latin_letter = A
case = lower
latin_letter = Y
case = lower
latin_letter = A
case = lower
FIG. 3.6 – Représentation du texte « Amaya » par un trie où chaque niveau
correspond à une propriété et chaque arête à une valeur apparue dans le texte.
Au niveau inférieur on obtient autant de feuilles qu’il y a de textèmes distincts
dans le texte.
signes qui se répètent. La taille de cet ensemble peut montrer des variations
très fortes selon la nature du texte et selon la gamme de propriétés qui nous en
intéressent — bref : selon l’usage. Par exemple, l’ensemble de base des signes
d’un programme informatique est le plus souvent limité à moins que 128 éléments (le codage ASCII).
Dans le cas de tels documents — où la plupart des signes sont décrits par
les mêmes propriétés et le nombre de signes utilisés est petit — et plus particulièrement dans le cadre d’un modèle de texte en textèmes, on a tout intérêt
d’envisager l’indexation des textèmes entiers, et non (ou non seulement) celle
des propriétés individuelles. Mais alors, une telle approche ne signifie-t-elle un
retour au principe de codage de caractères d’Unicode où le code numérique
sert comme abréviation d’un ensemble de propriétés ? Certes, d’un point de
vue d’optimisation de stockage il s’agit d’une approche très similaire, sans cependant que cette similarité ne se traduise au niveau conceptuel ou même au
niveau de l’accès au contenu du document. En effet, qu’il s’agisse d’une interface de programmation ou d’une interface utilisateur, l’indexation de textèmes
n’exclut point l’accès au document à travers une interface « orientée textème ».
A priori, en partant d’un document en textèmes non-optimisé dont on ne Le coût de l’indexation
possède aucune information concernant la répartition ou la nature de ses propriétés, une telle indexation peut être relativement coûteuse en calculs puisqu’il faut comparer tous les textèmes avec tous les autres, propriété par propriété, ce qui correspond à une complexité de O(n2 p2 ) où n est le nombre
de textèmes et p est le nombre moyenne de propriétés par textème. Ce coût
très élevé correspondant à un algorithme de « force brute » peut être réduit
à O(pn log v) où v est le nombre moyen de valeurs par propriété (qui apparaissent dans le texte), avec le facteur log v ≈ 1 dans les cas pratiques. L’idée est
de construire un trie spécial dont chaque parcours racine→feuille correspond
187
à un textème distinct et présent dans le texte (voir fig. 3.6). Le trie se construit
en parcourant le texte textème par textème, et à l’intérieur de chaque textème
propriété par propriété. (On suppose que l’ordre des propriétés dans les textèmes est invariable, une contrainte qui est facile à satisfaire.) Chaque arête du
trie qui part d’un nœud correspondant à une propriété pi représente une valeur distincte rencontrée dans le texte. Puisque l’on visite chaque propriété de
chaque textème une seule fois, le nombre total d’ajouts ou de déplacements
dans le trie est égal à pn. Cependant, le nombre d’arêtes partant d’un nœud
donné peut être très élevé (par exemple, une propriété unicode_character dans
un texte chinois peut prendre des milliers de valeurs différentes). Par conséquent, le coût de retrouver l’arête correspondant à la valeur de la propriété
courante n’est pas toujours négligeable. Pour la plupart des cas, ce coût peut
être réduit à O(1) à l’aide d’une table de hâchage (dont il faut un exemplaire
pour chaque nœud à partir duquel sort un grand nombre d’arêtes), mais dans
le cas de propriétés qui possèdent un très grand nombre de valeurs différentes
(comme les codes Unicode dans un texte chinois), le coût de la recherche
d’arête doit être majoré par O(log v).
3.4
LE MODÈLE DE TEXTÈMES
EN TANT QUE MODÈLE DE TEXTE GÉNÉRIQUE
Le caractère est un des types de données le plus élémentaires de l’ingénierie informatique. Grâce à sa simplicité, il est considéré si trivial qu’il est
souvent utilisé comme brique de base de structures plus complexes (telles que
les documents XML). Cependant, nous avons pu constater que la simplicité
apparente et superficielle du texte Unicode pouvait cacher une complexité
considérable, davantage que les codages antérieurs (tels que le codage ASCII).
Le modèle de texte introduit dans cette thèse remplace le caractère par une
structure de données, le textème, et à travers cet acte il assume ouvertement
la complexité inhérente du texte. Nous avons déjà examiné les implications
théoriques de ce fait dans le chapitre précédent. Cette fois-ci, nous adoptons
le point de vue du développeur d’applications, directement intéressé par des
problèmes tels que la compatibilité, la performance, la simplicité de manipulation. Est-ce que la complexité et la nature ouverte du textème représentent
un obstacle à son adoption en tant que remplaçant du caractère, c’est-à-dire
en tant qu’unité textuelle de bas niveau ? Est-ce que « char *str » pourrait
éventuellement être substitué par « texteme *str »4 , ou bien la notion de caractère comme unité textuelle atomique est-elle inévitable dans la pratique ?
Comment serait construite une bibliothèque de base de gestion textuelle basée sur les textèmes ? Voici les questions que nous tenterons de répondre dans
cette dernière partie du présent chapitre.
4
La question est, bien entendu, rhétorique : le type de données char du langage C ne pourra
jamais être remplacé par d’autres types, étant donné qu’il est, par convention, le seul type à
avoir une taille fixe d’un octet, indépendamment d’architecture et d’implémentation.
188
3.4.1 O PÉRATIONS ÉLÉMENTAIRES DE
MANIPULATION DE TEXTE
Commençons par une énumération rapide de ce que l’on peut considérer
comme les opérations élémentaires de manipulation de texte. Nous n’avons
la prétention de donner ici ni une liste exhaustive de primitives, ni une méthodologie formelle et analytique de décomposition des opérations textuelles.
Nous sommes toutefois convaincus que les opérations ci-décrites pourront au
moins nous servir comme un point de départ dans l’objectif de comparer les
implémentations respectives du modèle Unicode d’une part et du modèle en
textèmes d’autre part. Ceci dit, il ne faut pas oublier que ce que nous appelons « modèle en textèmes » dénote en réalité une famille de modèles qui se
distinguent par de nombreux paramètres de réalisation. Au présent, dans l’attente de définitions plus élaborées de ces modèles concrets (auxquelles nous
arriverons bientôt), toute comparaison entre modèle Unicode et modèle en
textèmes ne pourra être que partielle.
Le point commun le plus évident entre la chaîne de caractères et la chaîne
de textèmes est, bien entendu, qu’il s’agit de chaînes, c’est-à-dire de suites
unidimensionnelles d’éléments du même type. Au-delà de la simplicité apparente de cette structure, la plupart des opérations textuelles s’avèrent être tout
sauf triviales :
LE
CALCUL DE LA LONGUEUR DE LA CHAÎNE est une opération triviale s’il
s’agit tout simplement d’indiquer le nombre de caractères ou le nombre
de textèmes dans la chaîne. Cependant, on sait très bien que ce chiffre
ne coïncide pas forcément avec le nombre de « signes » ou de « graphèmes » dans le texte. Dans le cas du texte Unicode, il faut tenir
compte, entre autres, des caractères combinants. Dans le cas de textèmes, souvent on s’intéressera non pas au nombre total de textèmes
mais au nombre d’apparitions d’une propriété ou d’un ensembe de propriétés précis. Par exemple, on voudrait savoir le nombre de « glyphes »
dans le texte, sachant que pas tous les textèmes contiennent forcément
une propriété glyph_id, et qu’il se peut qu’un textème en contienne plusieurs si le modèle permet l’usage de propriétés récursives.
L’INSERTION
D’UN NOUVEL ÉLÉMENT dans la chaîne, qu’il s’agisse d’un ca-
ractère ou d’un textème, peut présenter des difficultés lorsque l’insertion s’effectue entre deux éléments qui entretiennent une relation de
dépendance. Le modèle Unicode n’est pas dépourvu de la notion de
dépendance (entre, par exemple, un caractère de base et ses caractères
combinants), bien qu’il n’existe aucun mécanisme pour indiquer ceci de
manière explicite. Dans le modèle en textèmes, nous avons considéré la
dépendance comme une information de nature contextuelle. Par conséquent, et pourvu que nous souhaitions l’existence d’une forme de gestion de dépendances, l’insertion d’un nouveau textème dans la chaîne
ne peut se faire sans la prise en compte du contexte.
LA
SUPPRESSION D’UN ÉLÉMENT TEXTUEL engendre la même sorte de pro-
blèmes que l’insertion.
LE
TEXTÈME EST UNE STRUCTURE DE DONNÉES, puisqu’il est composé de
propriétés ; à cette structure est lié un nombre d’opérations élémentaires
189
intra-textémiques. Un de nos objectifs est de définir la structure de données qu’est le textème de sorte que la performance des opérations les
plus fréquentes soit optimale, sans que l’espace de mémoire qu’elle occupe ne soit trop important. La « liste de propriétés » dont est constitué
le textème peut, en effet, être conçue de nombreuses manières : triée ou
non, avec accès linéaire ou aléatoire aux propriétés individuelles, avec
ou sans indexation des clés et des valeurs, etc.
LA
RECHERCHE D’UNE PROPRIÉTÉ au sein d’un textème est sans doute
parmi les opérations les plus courantes. Pratiquement toutes les
autres opérations y font recours : le filtrage de textème, ainsi que
l’insertion, la suppression et la modification de propriété, commencent par vérifier si la propriété en question est déjà présente
ou non dans le textème. La récurrence extrêmement fréquente de
l’opération de recherche de propriété suggère la nécessité de garder la liste de propriétés triée par défaut.
L’INSERTION
ET LA SUPPRESSION DE PROPRIÉTÉ sont des opérations
relativement simples dont l’implémentation est, bien évidemment,
fonction de la structure de données choisie pour la liste de propriétés.
LA
MODIFICATION DE LA VALEUR DE PROPRIÉTÉ a la particularité —
contrairement aux autres opérations telles que l’ajout ou la suppression de propriété — de pouvoir briser la dépendance algorithmique
dans le texte (cf. section 2.7.7, p. 159).
PAR
VÉRIFICATION DE L’ÉGALITÉ DE DEUX PROPRIÉTÉS on n’entend
pas forcément la vérification de leur identité. En section 2.4.4 nous
avons déjà parlé des différentes formes d’égalité entre propriétés
qui découlent des extensions et des intensions de celles-ci. La vérification de ces formes d’égalité peut être ou ne pas être réalisable en pratique, encore une fois en fonction de l’implémentation
concrète du modèle de texte.
LE
FILTRAGE DU TEXTÈME est une opération fréquemment employée :
entre autres, elle précède la comparaison de textèmes ou de textes,
elles-mêmes opérations de base de la recherche textuelle (cf. cidessous).
LA
COMPARAISON DE DEUX TEXTES Unicode, afin de vérifier leur égalité,
ne se limite pas à la comparaison des codes de caractère respectifs. Il est
souvent nécessaire de prendre en compte les propriétés définies dans la
BD d’Unicode, par exemple pour les comparaisons indépendantes de
casse ou pour obtenir la décomposition canonique de caractères combinés. De même, la comparaison de deux chaînes de textèmes ou tout
simplement de deux textèmes ne se limite pas à vérifier que les deux
contiennent les mêmes couples clé-valeur. Un filtrage préalable de propriétés peut être nécessaire, suivi par une éventuelle comparaison des
extensions communes ou des intensions des textèmes en question. De
plus, une éventuelle différence entre la segmentation des deux chaînes
de textèmes (e.g., entre un textème de ligature « fi » et une chaîne de
deux textèmes « f i ») peut rendre la comparaison encore plus complexe.
190
LA
RECHERCHE TEXTUELLE , enfin, est une opération complexe qui se dé-
compose en comparaisons élémentaires entre textèmes individuels.
La liste ci-dessus nous sera utile dans la suite en tant que « pense-bête »
lorsque nous devrons déterminer les aspects implémentationnels de notre modèle : la performance d’une implémentation donnée dépendra de la complexité des algorithmes qui réalisent les opérations élémentaires.
3.4.2 L A
COMPATIBILITÉ DE LA CHAÎNE DE TEXTÈMES
ET DE LA CHAÎNE DE CARACTÈRES
Sur notre chemin vers la caractérisation des aspects implémentationnels Unicode est inévitable
du modèle en textèmes, notre point de départ est une considération d’ordre
pragmatique, à savoir que l’introduction d’un nouveau modèle de texte aux
systèmes informatiques en général ne peut se faire qu’en assurant une parfaite
compatibilité avec le modèle actuel : celui des chaînes de caractères Unicode. Si au niveau du modèle interne d’une application ou d’un format de
document on peut encore envisager un éloignement des standard actuels en
faveur de modèles alternatifs, nous devons nous plier devant l’impossibilité incontestable d’un tel changement de modèle au niveau global, du moins dans
le court et moyen terme. En effet, même l’adoption mondiale du codage Unicode a été le fruit d’efforts considérables, non seulement sur un plan technique
mais aussi sur des plans commercial, politique et même diplomatique. En face
des difficultés conséquentes de normalisation liées à la moindre modification
du standard Unicode, la perspective de remplacer celui-ci par un modèle « révolutionnaire » reste, au mieux, une utopie. Bref, la proposition de modèles
alternatifs n’a donc d’intérêt pratique que si ceux-ci restent compatibles avec
Unicode.
Or, nous avons déjà montré (p. 171) qu’une chaîne de caractères (Unicode ou autre) peut être simulée de façon triviale par une chaîne de textèmes
ayant comme seule propriété le code de caractère. Inspirés de ce fait, nous
examinerons dans la suite cinq scénarios ou niveaux de compatibilité entre Cinq niveaux
le modèle en textèmes et le modèle en caractères, le premier niveau étant le de compatibilité
plus proche du modèle Unicode et le cinquième le plus éloigné. Bien évidemment, ces quatre scénarios n’épuisent pas toutes les voies de convergence
possibles entre textèmes et Unicode. Ainsi, nos observations relatives aux niveaux de compatibilité nous mèneront ensuite à la considération d’un codage
de signes qui tente d’établir un compromis entre les approches intensionnelle
et extensionnelle.
1. COMPATIBILITÉ
STRICTE. Nous exigeons un maximum de compatibilité
entre les deux modèles : les textèmes ne peuvent contenir qu’une seule
propriété, celle du code de caractère. Dans ce cas, des bibliothèques
de base de gestion de chaînes de caractères peuvent être mises à jour
sans qu’aucune application les utilisant ne change de comportement.
Bien que ce niveau de compatibilité interdise l’ajout de nouvelles pro- Accès à l’intension
priétés aux textèmes, il peut par contre permettre l’accès aux caractères du caractère
individuels comme s’ils y étaient représentés en tant qu’ensembles de
propriétés. Cette approche est particulièrement utile pour les caractères
Unicode qui possèdent un grand nombre de propriétés contenues dans
191
la base de données d’Unicode. Déjà à ce niveau de compatibilité, le
concept de textème arrive à présenter quelques avantages.
Le filtrage des propriétés
de caractère est permis
2. COMPATIBILITÉ
SOUSTRACTIVE . Comme précédemment, on exige la présence du code de caractère dans chaque textème mais on permet le filtrage des propriétés du caractère référencé (lorsque celui-ci possède une
description intensionnelle, comme dans le cas du codage Unicode). En
d’autres termes, on permet l’« annulation » des propriétés de caractère.
Ce qui motive la définition de ce niveau de compatibilité est le fait que
de nombreuses opérations textuelles courantes font recours à une forme
de filtrage : il suffit de penser aux opérations indépendantes de casse
(case folding), à l’utilité de la classification de signes (lettres, signes de
ponctuation, chiffres, etc.) et ainsi de suite. La soustraction de propriétés
est donc un type d’opération fréquemment employé.
L’ajout de propriétés
est permis
Similarité à M-text
3. COMPATIBILITÉ
ADDITIVE . Cette fois-ci, l’annulation de propriétés est interdite, par contre on permet l’ajout de nouvelles propriétés. Le modèle
M-text de la bibliothèque m17n [40] est équivalent au modèle de texte
de ce niveau de compatibilité.
4. COMPATIBILITÉ
ADDITIVE -SOUSTRACTIVE. Il est évident que les opéra-
tions d’addition et de soustraction de propriété correspondent à la généralisation et à la spécialisation du textème, respectivement. Les deux
opérations étant très communes, nous avons tout intérêt à définir un
niveau de compatibilité où elles sont permises simultanément, tout en
exigeant la présence du code de caractère dans le textème.
5. SANS
RESTRICTIONS. On n’impose aucune restriction sur l’emploi de propriétés : la présence du code de caractère dans le textème — ou des
propriétés équivalentes — est facultative.
Nous avons de bonnes raisons d’établir les niveaux de compatibilité de
cette manière précise. Rappelons que l’ensemble de signes dans T0 représentés par un textème t = {(tclé1 , tvaleur1 ), ..., (tclé n , tvaleurn )} donné s’obtiennent
en calculant l’extension commune de celui-ci (cf. p. 104) :
extc(t) = ext(tvaleur1 ) ∩ ... ∩ ext(tvaleurn )
Il s’ensuit que l’addition d’une nouvelle propriété φ au textème t réduit l’ensemble de signes que le textème représente au sous-ensemble
extc(t) ∩ ext(φ)
il s’agit donc de la spécialisation du textème. Puisque le caractère n’est
qu’un cas particulier du textème (une catégorie fonctionnelle de T3 ), la même
chose peut être dite d’un caractère tc décrit à l’aide de propriétés φc1 , ..., φcn
(fig. 3.7(a)). De la même manière, la soustraction (suppression, annulation)
d’une propriété φci depuis le même tc relève d’une généralisation de la sémantique du textème car on obtient un surensemble de extc(t) (fig. 3.7(c)).
Compatibilité additive
Supposons maintenant qu’un textème ti est la spécialisation d’un autre
textème tj :
extc(ti ) ⊆ extc(tj )
192
Cette relation est en réalité une variante de la relation « est-un » fréquemment
employée en représentation des connaissances (à savoir, il s’agit de sa variante ensembliste, voir le fameux article [18]). En considérant maintenant
un textème tc comprenant une seule propriété de caractère (telle que Unicode = U+0041), il est clair que l’ajout d’une nouvelle propriété φ crée un
nouveau textème qui entretient une relation de spécialisation avec tc , autrement dit, qui « hérite de » tc . Nous avons donc le droit de parler de compatibilité additive précisément parce que (1) il s’agit de l’ajout d’une nouvelle propriété au textème, et (2) parce que le nouveau textème ainsi obtenu possède
toutes les propriétés que possède le caractère initial, il est donc compatible
avec celui-ci. Il se peut, par contre, que l’extension commune de tc et l’extension de la propriété φ soient disjointes, en d’autres termes, que ces propriétés
soient incohérentes entre elles (fig. 3.7(b)), dans lequel cas le textème étendu
ne dénote aucun signe existant. Le niveau 3 de compatibilité additive nécessite donc déjà une forme de gestion d’incohérences (ou de dépendances, ce
qui réfère au même phénomène), comme en témoigne d’ailleurs l’emploi de
drapeaux de volatilité par le modèle M-text (p. 148), modèle qui opère également au niveau de compatibilité additive.
Le cas de la compatibilité soustractive est le cas inverse : le textème est Compatibilité
la généralisation du caractère, et pour cette raison il peut arriver qu’il désigne soustractive
non pas un mais plusieurs caractères à la fois (fig. 3.7(c)). Par exemple, en supprimant la propriété de casse d’un caractère A majuscule, le textème obtenu
désignera en même temps la capitale et le bas-de-casse. La relation « est-un »
est donc inversée par rapport au cas de la compatibilité additive, ce qui signifie
que, strictement parlant, le textème généralisé ne peut être considéré « compatible » avec le caractère initial dans un sens de substituabilité. La raison pour
laquelle nous continuons, malgré tout, d’appeler un tel textème « compatible »
avec le caractère dont il contient le code est la certitude que le caractère reste
toujours une « sous-classe » spécifique du textème : même si le caractère possède des propriétés non représentatives du textème, ils continuent à garder
une certaine « proximité sémantique ».
La relation d’héritage entre le textème et le caractère n’est plus forcément
valable lorsque l’ajout de nouvelles propriétés et l’annulation de celles du caractère sont permis simultanément. Comme on peut voir en fig. 3.7(d), une
généralisation suivie par une spécialisation peut créer un textème dont l’extension, bien que non vide, est disjointe de l’extension du caractère auquel il
fait référence. En d’autres termes, dans un textème contenant l’ensemble de
propriétés φc1 , ..., φcn décrivant un caractère (le code de caractère peut être
considéré comme l’abréviation de l’ensemble précédent), l’annulation de certaines de ces propriétés couplé avec l’ajout de nouvelles peut créer la description d’un signe qui n’a plus « rien à voir » avec le caractère initial. Par exemple,
dans le textème
Unicode = 0041
− letter = A
+ letter = B
on a annulé la propriété letter = A et on a ensuite ajouté une propriété letter = B. Le signe ainsi décrit existe (il s’agit de la lettre latine majuscule « B »)
mais il est incohérent avec le code Unicode contenu dans le textème.
193
tc
φ
tc + φ tc
(a)
φ
tc − φci
tc
(b)
(c)
tc − φci
(tc − φci ) + φ
tc
φ
(d)
FIG. 3.7 – Les extensions de textèmes conformes aux différents niveaux de
compatibilité. tc est un textème qui représente un caractère particulier, dont
les propriétés sont φc1 , ..., φcn . φ est une propriété supplémentaire que l’on
ajoute à ce textème. tc − φci signifie la suppression de la propriété φci à partir
du textème, tc + φ signifie l’ajout de la propriété φ au textème. (a) spécialisation par ajout de propriété, (b) incohérence entre un caractère et une propriété
ajoutée, (c) généralisation par soustraction de propriété, (d) ajout et soustraction simultanés où le résultat est incohérent avec le caractère initial.
Les niveaux 4 et 5 sont
Il est facile à prouver que le 4e niveau de compatibilité où l’addition et la
équivalents soustraction simultanées sont permises est équivalent au 5e niveau où aucune
contrainte n’est posée sur l’usage des propriétés de textème : il suffit d’annuler
d’abord la totalité des propriétés de caractère, pour ensuite ajouter de nouvelles propriétés arbitrairement. De même, l’annulation d’une propriété suivie
par l’ajout d’une autre avec la même clé mais une valeur différente équivaut
à une modification. Il s’avère donc que ni dans le cas du 5e niveau, ni dans
celui du 4e , on ne peut garantir la compatibilité entre le modèle Unicode et
le modèle en textèmes. Cette constatation est d’autant plus déconcertante que
le 4e niveau de compatibilité semble, au premier regard, être d’une utilité très
significative : aussi bien l’enrichissement des caractères par de nouvelles propriétés que le filtrage des propriétés de caractère sont des opérations textuelles
très courantes. Devoir interdire leur application simultanée afin de maintenir
un degré de compatibilité minimum avec le modèle Unicode paraît donc un
compromis mal choisi.
Dans la suite, nous allons étudier plus en détail les différents niveaux de
194
compatibilité, notamment en ce qui concerne la gestion de dépendances et
les enjeux de l’implémentation des opérations textuelles élémentaires.
COMPATIBILITÉ
STRICTE (NIVEAU
1)
Rappelons que ce niveau assure une compatibilité totale entre le codage
de caractères et le texte en textèmes : chaque textème doit représenter ni plus
ni moins qu’un caractère Unicode. Cela se réalise par l’inclusion d’une seule
propriété dans le textème, celle du code de caractère, l’intérêt étant toujours
une représentation textuelle simple et économique, avec la possibilité d’accéder aux caractères en tant qu’ensembles de propriétés. Par « accès » nous entendons avant tout la lecture des valeurs de propriétés ; la modification, l’ajout
et la suppression de propriétés, si permis, doivent être sévèrement restreints
afin d’éviter la création de textèmes qui ne représentent aucun caractère. Plus Condition nécessaire
précisément, on peut permettre une modification (ajout, suppression) si le de la modification
des propriétés
nouveau textème t′ ainsi produit vérifie que
de textème
′
|extc(t )| = 1
c’est-à-dire qu’il représente un et un seul caractère. Ceci est vérifiable en un
temps proportionnel à O(pS) où p est le nombre de propriétés dans t′ et S
est un paramètre dont la valeur montre des variations fortes, entre 1 et le
nombre total de caractères dans le codage. (En réalité, S est égal à |ext(φmin )|
où φmin ∈ t′ est la propriété de t′ qui caractérise le moins de caractères du
codage. L’algorithme de calcul d’extension commune, ainsi que son coût, seront détaillés dans la section 3.4.6.) La vérification de cette condition n’est
moins, en fait, qu’une forme de gestion de dépendance, avec comme critère
supplémentaire de non seulement interdire l’incohérence (où extc(t′ ) = ∅)
mais aussi les textèmes référant à plusieurs caractères (où |extc(t′ )| > 1).
Ce dernier critère semble cependant être trop restrictif car la généralisation
est une opération textuelle très courante. Rappelons que celle-ci consiste à
élargir l’extension commune d’un textème par la soustraction de certaines de
ses propriétés : à le rendre plus général, justement.
COMPATIBILITÉ
SOUSTRACTIVE (NIVEAU
2)
Puisque la soustraction d’une propriété de textème ne peut jamais introduire d’incohérence (tant que le textème d’origine n’est pas déjà incohérent),
cette opération peut être permise sans vérification d’incohérence préalable. En
pratique, un caractère généralisé peut être représenté par un textème au sein
duquel on permet la soustraction de propriété :
Unicode = 0041
− case = upper
La généralisation crée un grand nombre de nouveaux éléments textuels :
un caractère ayant un nombre p > 1 de propriétés peut être à l’origine de
p−1 X
p
i=1
i
= 2p − 3 (i est le nombre de propriétés soustraites)
195
textèmes généralisés (ne pas comptant le caractère lui-même et le textème
vide).
Du coup, la vérification de l’égalité de deux textèmes devient un problème
non trivial. En mode de compatibilité stricte, les textèmes sont limités à représenter des caractères codés uniques et individuels : chaque textème correspond à un et un seul élément du codage. L’égalité de deux textèmes n’est
donc possible que si les deux signes correspondants — et donc leurs codes
— sont identiques5 . En revanche, lorsque la généralisation est permise, l’égalité extensionnelle de deux textèmes doit être vérifiée par la comparaison de
leurs extensions communes respectives, une opération d’une complexité plus
élevée (cf. section 3.4.6).
COMPATIBILITÉ
Propriétés externes
et internes au codage
Spécialisation
par propriété externe
Spécialisation
par propriété interne
ADDITIVE (NIVEAU
3)
La possibilité d’ajouter des propriétés supplémentaires aux textèmes représentant des signes — autrement dit : de les spécialiser et d’ainsi enrichir le
texte — est également une opération fréquente et nécessaire, d’où l’intérêt de
la compatibilité additive. Comme signalé précédemment, le modèle M-text
mis en œuvre par la bibliothèque m17n fonctionne à ce niveau : il permet
l’ajout arbitraire de propriétés aux chaînes de caractères Unicode.
Dans la suite, nous aurons besoin de distinguer entre deux types de propriétés : les propriétés internes au codage de caractères sont celles qui sont
présentes dans la BD d’Unicode, dans le sens où elles sont employées dans la
description d’au moins un caractère. Les propriétés externes au codage, elles,
sont typiquement les propriétés venant de diverses opérations de traitement
de texte, et n’apparaissent nulle part dans l’intension des caractères.
La spécialisation par propriété externe est un cas bien particulier car elle
ajoute au textème une propriété « inconnue » du point de vue du codage. (Il
peut s’agir, par exemple, d’une propriété de couleur ajoutée lors du formatage.) Du coup, ce nouveau textème ne sera plus équivalent à aucun caractère
codé. La relation qu’entretiennent le caractère et le textème est une relation de
type « est-un » (d’héritage) : le caractère spécialisé hérite du caractère d’origine.
La propriété externe ajoutée se distingue facilement (par sa clé) des propriétés
internes, elle n’interfère pas avec le caractère d’origine.
Une propriété interne, en revanche, possède une extension connue (déterminée par la BD d’Unicode), et il se peut que celle-ci soit disjointe de
l’extension commune du caractère d’origine : si t est un textème représentant
un caractère Unicode, et t est spécialisé par une propriété interne φ, alors
l’extension du textème résultant, extc(t) ∩ ext(φ), peut être vide. En d’autres
termes, il se peut que la propriété interne φ soit incohérente avec le codage de
caractères parce qu’il n’existe pas de caractère dans le codage qui soit caractérisé par un tel ensemble de propriétés. Ceci est encore facilement détectable
(il suffit de vérifier si extc(t) ∩ ext(φ) = ∅) et le système peut décider l’action à
prendre : soit considérer cela comme une incohérence et interdire l’ajout de la
propriété φ, soit considérer le nouveau textème comme la première manifes5
Pourvu que le codage ne contienne des signes extensionnellement ou intensionnellement
égales. Même dans ce cas, une table pré-calculée des classes d’équivalence — à laquelle nous
reviendrons bientôt — peut accélérer la vérification d’égalité.
196
tation d’un nouveau caractère, créé « à la volée » pour le temps du traitement
du texte en question.
En pratique, la spécialisation par propriété interne est une opération fréquemment employée. Par exemple, un utilisateur peut ajouter une propriété
no_break = true à un caractère U+0020 SPACE qui par défaut permettrait la
coupure de ligne à travers sa propriété « SP » (espacement ordinaire, coupure
indirecte permise) indiquée par la BD d’Unicode. Dans ce cas particulier, le
comportement raisonnable de la part du moteur de texte serait sans doute de
supplanter la propriété par défaut par celle voulue par l’utilisateur. Cependant,
dans le cas d’une autre combinaison de propriétés telle que script = arab et
character = U+0644, l’insertion par l’utilisateur d’une propriété script explicite ayant la valeur (disons) hebrew résulte en un ensemble de données où
il est moins évident de prévoir le comportement souhaité6 . Il est donc essentiel d’établir une politique de résolution d’incohérence non-ambigu entre
propriétés implicites du caractère Unicode et propriétés explicitement ajoutées, comme par exemple un ordre de priorité préétabli (e.g., les propriétés
explicites supplantent toujours les propriétés implicites).
Ayant constaté le comportement différent au sein du textème entre propriétés externes et internes, une question importante se pose : comment peut-on
décider pour une propriété donnée si elle est externe ou interne ? L’identité
de la clé et de la valeur à celles d’une des propriétés Unicode peut indiquer
qu’il s’agit d’une propriété interne, mais ceci n’est pas une condition nécessaire : dans l’exemple précédent, no_break et SP ont la même sémantique
alors qu’elles s’identifient par des clés différentes. La réponse générale à ce
problème se trouve, encore une fois, dans la création d’une base de description formelle de propriétés qui décrivent, entre autres, les relations d’équivalence qu’elles entretiennent.
Ces considérations nous amènent au problème plus général des relations
d’égalité entre textèmes et entre propriétés que nous avons examinées pour
la première fois en section 2.4.4 et que nous avons également mentionnées à
propos des opérations textuelles élémentaires. Nous avons pu voir qu’en théorie il existe deux manières de vérifier ces relations : soit en les dérivant à partir
des relations ensemblistes dans T0 engendrées par T1 , soit par leur indication
à travers des règles sémantiques explicites. Cette indication de l’équivalence
pourrait venir de la description RDF/OWL distribuée des propriétés en question (si un tel cadre sémantique de description de propriétés est disponible),
sinon, d’une base de données centralisée (c’est-à-dire intégrée dans la bibliothèque de gestion textuelle) d’un éventuel « noyau dur » de propriétés. L’autre
solution, c’est-à-dire la dérivation des relations à partir des extensions des propriétés dans O ⊆ T0 , n’est possible que si l’ensemble O en question est connu
en pratique : il comprend un nombre limité d’éléments dont chacun possède
sa propre description intensionnelle. Tel est le cas des caractères Unicode
(dont la description intensionnelle, fournie par la BD d’Unicode, reste cependant assez limitée). C’est également le cas du codage de signes intensionnel
que nous allons introduire très prochainement, en section 3.4.3.
Si la relation d’égalité entre propriétés peut se définir de plusieurs ma6
Il est inutile de mentionner que la résolution de tels conflits arabo-hébraïques s’est montrée
souvent très difficile dans l’histoire.
197
Exemples
de spécialisation
Externe ou interne :
comment décider ?
Deux méthodes
de vérification
de l’incohérence
et de l’égalité
entre propriétés
nières, c’est encore plus le cas de celle entre chaînes de textèmes conformes
Égalité entre chaînes au niveau 3 de compatibilité. À part l’égalité extensionnelle entre deux texde textèmes tèmes (extc(t1 ) = extc(t2 )), les diverses formes d’égalité intensionnelles et
Dépendances
au niveau 3
Contraintes
informatiques
même l’égalité superficielle (où toutes les propriétés sont identiques), la présence du code de caractère permet de comparer deux textèmes en « mode de
compatibilité », comme si l’on avait à comparer deux chaînes de caractères.
La vérification de l’égalité des codes de caractère en ignorant le reste des propriétés est évidemment la méthode la plus rapide, mais son utilité est limitée :
on a souvent intérêt à comparer des caractères filtrés (e.g., comparaison indépendante de casse) où le filtrage se manifeste par la présence de propriétés
soustraites (annulées). Ainsi, en fin de compte, la comparaison entre caractères
Unicode présente des difficultés similaires à celle entre ensembles de propriétés, ce qui n’est guère surprenant : la BD d’Unicode n’est autre qu’une forme
de description intensionnelle, quoique restreinte, de l’ensemble de caractères
à travers leurs propriétés et parfois même leurs relations.
Contrairement au niveau de compatibilité soustractive, le niveau 3 est atteint par la problématique de la dépendance. D’une part, comme nous venons de voir, l’ajout de propriétés internes peut créer une incohérence entre
celles-ci et le caractère référencé depuis le textème. Cette forme de violation
de dépendance, de nature extensionnelle (cf. page 152) — car elle découle
des relations ensemblistes entre les extensions respectives du caractère et de
la propriété interne —, peut être évitée d’une façon préventive si l’on interdit
l’ajout de propriétés internes aux textèmes. Il reste à résoudre cependant la
gestion de dépendances algorithmiques qui peuvent exister entre tous genres
de propriétés.
Dans le chapitre précédent nous avons proposé quelques méthodes informatiques de gestion automatique de dépendances ; cependant, dans le
contexte d’une bibliothèque textuelle générique de bas niveau, de telles approches ne sont pas forcément appropriées, aussi bien pour des raisons de
perte de performance que parce que différents usages demandent différentes
politiques de gestion. L’implémentation d’un système simple et léger de gestion de dépendances peut, malgré tout, être envisageable si son emploi reste
optionnel, comme c’est le cas dans la bibliothèque m17n, certes sur un niveau très basique. Notamment, le drapeau de volatilité faible semble être très
utile dans le but de demander la suppression automatique d’une propriété
lorsque le caractère contenu dans le textème est modifié. Alternativement, la
méthode de liens que nous avons présenté en section 2.7.8 est à peine plus
complexe, aussi bien au niveau de mise en œuvre qu’au niveau de son application, même si elle ne peut indiquer que les dépendances inter-textémiques.
La méthode de paramètres de condition (section 2.7.8) est une méthode plus
puissante et plus générale que les précédentes, mais elle aurait certainement
un effet négatif considérable sur la performance des opérations textuelles.
COMPATIBILITÉ
SOUSTRACTIVE- ADDITIVE (NIVEAU
4)
Précédemment dans cette section nous avons annoncé et prouvé la « mauvaise nouvelle » selon laquelle la permission simultanée de l’addition et de
la soustraction de propriété équivaut à n’imposer aucune restriction sur le
contenu des textèmes. Autrement dit, même si la présence d’un code de ca198
ractère y est exigée, rien n’empêche la modification arbitraire de la sémantique
du textème en annulant d’abord certaines propriétés Unicode pour ensuite y
ajouter d’autres, incohérentes avec le caractère référencé.
Ainsi, lorsque le textème t représente un signe codé dont on annule une
propriété φg et que l’on spécialise ensuite par l’ajout d’une propriété φs , l’extension du textème t′ résultant peut être non-vide même si t et φs sont incohérents entre eux, de manière analogue à l’exemple sur la fig. 3.7, p. 194. Le
4e niveau de compatibilité est donc en réalité un niveau de non-compatibilité,
dans ce sens équivalent au 5e niveau.
Fort heureusement, à travers l’ajout d’une légère contrainte supplémentaire à la définition du 4e niveau, on peut arriver à avoir et le beurre et l’argent
du beurre, c’est-à-dire d’assurer la cohérence entre caractères et textèmes tout
en permettant l’addition et la soustraction simultanées. Il suffit de préciser que
seul l’ajout de propriétés externes est permis.
Comment gérer alors les cas d’utilisation tels qu’un caractère d’espacement ordinaire (U+0020 SPACE) auquel l’utilisateur souhaite ajouter une propriété d’insécabilité ? Il s’agit, bien entendu, d’une propriété qui apparaît dans
la BD d’Unicode, d’une propriété interne. L’interdiction de l’ajout de cette
propriété est sans doute fort gênante d’un point de vue d’utilisabilité. Afin de
rendre ce critère moins restrictif, on peut envisager un système qui, au moment
de l’ajout de la propriété d’insécabilité, remplace le caractère U+0020 SPACE
par U+00A0 NO-BREAK SPACE possédant cette propriété interne7 et ainsi évite
l’incohérence.
CHAÎNES
DE TEXTÈMES SANS RESTRICTIONS (NIVEAU
5)
Le fait que le textème se dissocie complètement du caractère rend la compatibilité avec le modèle Unicode nettement plus problématique.
Un caractère est toujours représentable en forme de textème. Dans le cadre
du 5e niveau, le contraire n’est pas vrai : puisque rien ne garantit la présence
du caractère dans le textème — ni la présence de son code numérique ni celle
des propriétés le décrivant n’est assurée —, tout textème n’est pas convertible
en un caractère spécifique.
Par conversion, on entend plus exactement une opération qui vérifie une
forme d’égalité — extensionnelle, intensionnelle, etc. — entre le textème et
l’ensemble de caractères. Le problème est que cette opération n’est envisageable que si une description intensionnelle « suffisamment détaillée » et formalisée de l’ensemble des caractères est disponible, ce qui n’est pas du tout
le cas pour la plupart des codages de caractères existants. Même dans le cas
d’Unicode, la description intensionnelle reste très limitée et pour la plupart
restreinte à des propriétés de formatage8 . Plus que jamais, la construction
d’une base de connaissances intensionnelle de caractères semble être incontournable.
Le problème est que notre ensemble de base de signes, O ⊂ T0 , est radicalement étendu (car nous n’imposons aucune restriction à ce qu’un textème
7
L’automatisation de cette procédure, y compris le coût de l’algorithme, sera le sujet des
sections suivantes.
8
Certes, le nom informel du caractère Unicode (tel que LATIN CAPITAL LETTER A ), si analysé,
pourrait éventuellement fournir davantage d’informations.
199
Conversion du textème
en caractère
L’ensemble T0 devient
illimité
peut exprimer), et par conséquent il n’est plus possible de vérifier l’égalité
ou la dépendance de deux textèmes en comparant leurs extensions communes dans T0 . Prenons l’exemple d’un textème contenant une seule propriété glyph = a ; peu importe la manière dont le glyphe est référencé en pratique (par son identifiant numérique employé dans une fonte, par un pointeur
vers une zone de mémoire contenant son image bitmap, etc.). Le caractère
Unicode correspondant à ce glyphe est bien évidemment le U+0061 LATIN
SMALL LETTER A, mais cette égalité est loin d’être évidente pour l’ordinateur.
L’extension de ce textème dans T0 est inconnue, T0 lui-même étant inconnu
car trop grand pour être entièrement déterminé. En d’autres termes, il existe effectivement une dépendance extensionnelle (glyph = a) → (char = U+0061)
mais elle n’est pas formellement dérivable. La même dépendance peut cependant exister en forme algorithmique : d’une part, le code de caractère peut
être déduisible de l’identifiant de glyphe lorsque la table cmap de la fonte est
disponible, d’autre part, le caractère peut être obtenu à partir du glyphe par reconnaissance optique. Dans les deux cas, il s’agit de dépendances formulées
en tant que relations de rang supérieur (cf. section 2.7.6). Cependant, l’existence de telles relations, c’est-à-dire la disponibilité de telles algorithmes, ne
peut être supposée comme cas universel.
Correspondances m-à-n
Une autre difficulté de conversion depuis la chaîne de textèmes vers la
entre caractère(s) chaîne de caractères est le manque de bijection dans certaines situations : le
et textème(s) textème peut représenter des unités pertinentes textuelles plus petites ou plus
grandes que le caractère. Encore une fois, l’indication explicite des dépendances algorithmiques peut être utile : supposons qu’une fonte assemble un
signe coréen à partir de trois glyphes correspondant aux jamos : + + = .
La chaîne de textèmes se présente alors de la manière suivante :
glyph =
glyph_id = 120
p
glyph =
glyph_id = 213
p
glyph =
glyph_id = 46
Les liens indiquent la dépendance entre les trois glyphes et peuvent signaler
que ceux-ci correspondent à un seul caractère. Ensuite, un algorithme ayant
accès à la fonte peut calculer le code de caractère à partir des trois identifiants
de glyphe.
3.4.3 U N
CODAGE DE SIGNES INTENSIONNEL
À LA BASE DU MODÈLE DE TEXTE GÉNÉRIQUE
Nous arrivons ici à ce qui est en quelque sorte la synthèse des résultats jusqu’ici annoncés dans cette thèse. Initialement, nous avons introduit le modèle
de texte en textèmes en tant qu’alternative aux modèles actuels. Nous avons
extensivement argumenté pour les avantages des modèles intensionnels, s’inspirant de certaines approches de la représentation des connaissances, en les
comparant au modèle caractère-glyphe représenté par Unicode et aux technologies de fontes intelligentes. En même temps, nous avons également pu
voir que la généralité, l’intensionnalité et la nature ouverte de nos modèles
entraînent de nouvelles difficultés, souvent semblables aux problèmes classiques de la RC :
200
– la vérification de l’égalité de deux textèmes est très complexe et peut
même être impossible en pratique ; celle de deux caractères Unicode
est toujours possible mais peut également être complexe (cf. character
folding, décomposition canonique, etc.) ;
– la dépendance entre propriétés est un phénomène avec lequel il faut
compter et qu’il faut savoir reconnaître et gérer ;
– de même, il devrait être possible de reconnaître l’équivalence entre propriétés non identiques (un cas spécial de la dépendance) ;
– il est parfois nécessaire de connaître les catégories fonctionnelles des
propriétés (lors d’un changement de contexte d’usage, par exemple) ;
– etc.
Nous avons pu remédier à certaines de ces difficultés par la proposition de méthodes de gestion de dépendances et par la description des propriétés à l’aide
de ressources RDF/OWL. En même temps, nous nous sommes rendus compte
que l’efficacité de ces solutions est toujours bornée par la « surpuissance » du
modèle : que l’ensemble de signes que le textème peut potentiellement représenter est illimité. Bien sûr, cette liberté peut également être vue comme
un avantage — elle fournit au modèle, entre autres, le potentiel d’être à la
source d’usages textuels novateurs (cf. section 2.4.7) — mais dans certaines
situations il paraît plus intéressant de limiter les signes de base à un ensemble
bien circonscrit et décrit (sans cependant que celui-ci soit forcément fermé).
En somme, ce qui semble souvent être le plus souhaitable d’un point de vue
implémentationnel est un compromis entre les mondes extensionnel et intensionnel, un modèle hybride qui profite à la fois des avantages d’Unicode que
de ceux offerts par le modèle de texte en textèmes.
Toujours dans le contexte de la construction d’un modèle de texte générique et d’usage universel, nous examinerons la possibilité d’un codage de
signes intensionnel. Ce nouveau codage, quelque peu similaire au codage de
caractères Unicode mais plus formel, plus général et plus ouvert, se distingue
par les particularités suivantes :
– les signes y contenus n’appartiennent pas forcément à la même catégorie fonctionnelle : c’est pour cette raison que nous ne parlons pas de
codage de caractères ou de glyphes mais de signes en général ;
– chaque signe possède une description sémantique (intensionnelle) extensive, à travers ses propriétés ; cette description est plus large et plus
générale que celle fournie par la BD d’Unicode ;
– les propriétés possèdent également leur propre description sémantique ;
– aussi bien la description des signes que celle des propriétés est formalisée.
Tout d’abord, une précision regardant l’appellation codage de signes. La L’usage du mot « signe »
raison pour employer le terme signe au lieu de textème est la volonté de dis- au lieu de « textème »
tinguer entre l’élément textuel en tant que membre d’un répertoire (le signe,
remplaçant du caractère) et en tant qu’élément d’une chaîne (le textème), bien
que les deux entités soient définies en tant qu’ensembles de propriétés. En effet, conformément aux niveaux de compatibilité 2.(a) et 3, il se peut qu’un textème, élément textuel générique, contienne un signe mais également d’autres
propriétés ajoutées, d’où le besoin de clarifier la différence entre les deux
concepts.
201
En quelque sorte, rien que l’extension de la BD d’Unicode par de nouvelles propriétés — aussi bien en nombre qu’en usages couverts — présente
un intérêt considérable, puisque celles-ci peuvent fournir des informations
liées à de nouveaux usages et d’ainsi rendre le texte Unicode plus polyvalent.
Mais l’augmentation du nombre des propriétés crée une situation similaire à
l’augmentation de la taille de codage : il devient essentiel d’y « faire l’ordre »
par l’introduction de propriétés de propriétés ou des relations entre propriétés
(e.g., relation d’équivalence). Notamment, les propriétés peuvent être catégorisées selon de nombreux critères, y compris l’usage, dans lequel cas nous
parlons de catégories fonctionnelles. Celles-ci sont indispensables notamment
lorsque le texte subit des changements de contexte d’usage (cf. section 2.6),
entre autres pour filtrer les propriétés non pertinentes.
Codage
L’adoption d’un codage de signes ne représente pas forcément un retour
de signes 6= modèle vers un modèle de texte équivalent à celui d’Unicode. Les considérations de
Unicode compatibilité entre caractère et textème de la section précédente s’appliquent
naturellement à des éléments textuels codés autres — plus générals, plus formalisés — que les caractères Unicode, ce qui sera le cas des signes que nous
sommes sur le point d’introduire. Notamment, le troisième niveau de compatibilité reste disponible afin de permettre la spécialisation ou la généralisation
des signes codés, tout en assurant la maintenance d’une compatibilité entre
textèmes et signes. Le textème en tant que conteneur général de propriétés
permet donc la conception de nombreux différents modèles de texte basés sur
l’idée de codage de signes, tout comme le caractère Unicode peut être à la
base du modèle caractères-glyphes de la technologie OpenType, de Graphite,
de M-text, etc.
Dans la suite, nous donnerons d’abord une solution pratique — qui est
loin d’être la seule possible — d’implémentation d’un codage de signes intensionnel. Ensuite, nous considérerons les intérêts et les difficultés que présente
une telle approche en comparaison avec l’emploi du codage Unicode.
La polyvalence
du codage de signes
DESCRIPTION
DU CODAGE EN
RDF/OWL
La nécessité
Le critère peut-être le plus important que nous exigeons vis-à-vis du codage
d’une définition de signes est qu’il possède une description formelle9 . Rappelons que dans le
formelle du codage cas d’Unicode, ce critère n’est satisfait qu’à moitié : d’une part, chaque pro-
priété possède un identifiant unique et les associations entre points de code et
propriétés sont formalisées ; d’autre part, les propriétés elles-mêmes sont décrites informellement, à travers des documents destinés au lecteur humain. La
maintenance des propriétés disponibles, leur documentation et la description
des caractères par elles sont prises en charge exclusivement par la Consortium
Unicode.
Description du codage
Dans le cas du codage de signes, les propriétés possèdent également leur
en RDF/OWL description formelle en forme de ressources RDF/OWL, déjà présentées en
section 3.3.1. En possession d’un document RDF/OWL de définition de propriétés tel que celui de la figure 3.4, p. 184, le codage de signes intensionnel
9
Par « description formelle » nous entendons un format de représentation directement interprétable par l’ordinateur, tel qu’un document XML, qui adhère à un schéma structurel ainsi
qu’à un certain ensemble de conventions sémantiques.
202
se représente tout simplement comme un autre document RDF/OWL (voir
fig. 3.8) qui fait recours aux ressources définies dans le document précédent.
Bien entendu, les classes Texteme et TextemeProperty ainsi que les relations hasProperty, hasKey et hasValue doivent être définies dans un schéma
RDF/OWL centralisé, comme c’était le cas du schéma de description des propriétés.
En théorie, on pourrait envisager l’extensibilité décentralisée du codage
de signes, d’une manière similaire à ce que nous proposons pour la liste de
propriétés. Cependant, un codage ouvert et réparti présente un inconvénient
majeur par rapport à un codage fermé et centralisé tel qu’Unicode : il n’est pas
capable d’assurer l’unicité des codes numériques. En effet, la motivation principale pour abandonner les codages de caractères nationaux en faveur d’Unicode était justement la pénibilité de jongler avec une multitude de codages
mutuellement incompatibles, de devoir indiquer pour chaque bout d’information textuelle son codage, etc. Dans le cas d’un codage de signes ouvert, on
fait face au même problème : tout identifiant de signe, qu’il soit numérique
ou autre, doit être attaché à une référence unique vers l’emplacement de sa
définition, à la manière d’un espace de nommage. Même si en théorie cela ne
pose pas de problème — puisque les textèmes peuvent toujours représenter
cette information en tant que propriété —, il nous semble plus réaliste d’abandonner l’idée d’un codage de signes dont l’extension est ouvert au public, et
de préférer un codage centralisé.
Finalement, nous tenons à remarquer que le format RDF n’est bien évidemment pas le seul outil possible pour la description d’un codage de signes.
Nous avons choisi ce cadre précis principalement parce qu’il est simple, il fait
partie des normes W3C, il s’inscrit dans le cadre des outils de la représentation
des connaissances, il a un format textuel en XML favorisant la publication sur
le Web, et finalement parce que plusieurs moteurs d’inférence adaptés existent
sur le marché. Typiquement, après qu’une application (ou bibliothèque) a récupéré et interprété le (ou les) document(s) décrivant le codage de signes, elle
gardera celui-ci en mémoire dans un format rapidement accessible.
Un standard
décentralisé : est-ce
possible ?
Téléchargement
et représentation
en mémoire du codage
de signes
3.4.4 U TILISATION DU
CODAGE DE SIGNES
AVEC LE MODÈLE DE TEXTE EN TEXTÈMES
Un codage de signes associe un code numérique à chacun de ses élé- L’importance du code
ments. Ce code, suivant le principe russellien de nommage (p. 94), peut être numérique
considéré comme l’abréviation de l’ensemble de propriétés qui décrivent le
signe. Qui parle d’abréviation parle d’économie de stockage : l’emploi des
codes de signes permet une réduction drastique de l’espace occupé par le
texte en mémoire vive. Compte tenu du nombre potentiellement très élevé de
propriétés décrivant chaque signe, et aussi du fait que le signe peut également
appartenir à des relations non-unaires (comme des propriétés contextuelles ou
des relations d’équivalence non-extensionnelles) qui font néanmoins partie de
sa définition, une implémentation de modèle qui ne recourt pas à une forme
d’abréviation de ces informations serait, pour dire le moins, difficilement envisageable.
Les considérations d’optimisation seront le sujet de la section 3.4.6 ; pour
203
<?xml version="1.0"?>
<!-- ==================== DÉFINITIONS D’ENTITÉS ====================== -->
<!DOCTYPE rdf:RDF [ <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">
<!ENTITY cp "http://omega.enstb.org/CoreProperties.owl#">
<!ENTITY typo "http://typo.nexistepas.org/Typo-Ontology#"> ]>
<!-- ====================== ESPACES DE NOMMAGE ======================= -->
<rdf:RDF
xmlns="http://omega.enstb.org/TextemeEncoding.owl#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xml:cp="http://omega.enstb.org/CoreProperties.owl#"
xml:base="http://omega.enstb.org/TextemeEncoding.owl">
<owl:Ontology rdf:about=""/>
<!-- ============================ SCHÉMA ============================= -->
<rdfs:Class rdf:ID="Signe"/>
<rdfs:Class rdf:ID="TextemeProperty"/> <!-- couple clé/valeur -->
<owl:ObjectProperty rdf:ID="hasProperty">
<rdfs:range rdf:resource="#TextemeProperty"/>
<rdfs:domain rdf:resource="#Signe"/>
</owl:ObjectProperty>
<owl:FunctionalProperty rdf:ID="hasKey">
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
<rdfs:domain rdf:resource="#TextemeProperty"/>
<rdfs:range rdf:resource="&cp;TextemePropertyKey"/>
</owl:FunctionalProperty>
<owl:ObjectProperty rdf:ID="hasValue">
<rdfs:domain rdf:resource="#TextemeProperty"/>
</owl:ObjectProperty>
<!-- ================ DESCRIPTION DES SIGNES CODÉS =================== -->
<Signe rdf:ID="00041"> <!-- lettre latine A majuscule -->
<hasProperty><TextemeProperty>
<hasKey rdf:resource="&cp;PropLatinLetter"/>
<hasValue rdf:resource="&cp;letter_a"/>
</TextemeProperty></hasProperty>
<hasProperty><TextemeProperty>
<hasKey rdf:resource="&cp;PropCase"/>
<hasValue rdf:resource="&typo;upper"/>
</TextemeProperty></hasProperty>
<hasProperty><TextemeProperty>
<hasKey rdf:resource="&cp;PropScript"/>
<hasValue rdf:datatype="&xsd;string">latin</hasValue>
</TextemeProperty></hasProperty>
<hasProperty><TextemeProperty>
<hasKey rdf:resource="&cp;PropUnicode"/>
<hasValue rdf:datatype="&xsd;int">65</hasValue>
</TextemeProperty></hasProperty>
</Signe>
</rdf:RDF>
FIG. 3.8 – Une description (partielle) du signe « A majuscule » en RDF, à l’aide
des propriétés PropLatinLetter (lettre « a »), PropCase (casse majuscule),
PropScript (système d’écriture latin) et PropUnicode (référence vers le caractère Unicode équivalent). Les propriétés sont définies dans un fichier à part,
nommé CoreProperties.owl (cf. fig. 3.4, p. 184).
204
le moment, il nous suffit d’accepter que le seul véritable moyen pratique de Cas analogue :
représenter un signe au sein d’un textème est d’y inclure son code numé- caractères Unicode
rique. Bien entendu, conceptuellement, on considère toujours qu’un tel tex- dans les textèmes
tème comporte, d’une façon comprimée, la totalité des propriétés décrivant
le signe en question. Nous avons déjà examiné certaines conséquences d’une
telle approche à propos de la compatibilité entre textèmes et caractères (section 3.4.2) où il s’agit également de fusionner un codage, à savoir le codage
Unicode, avec le modèle en textèmes. Il n’est pas très surprenant que les enjeux sont très similaires dans les deux cas, et que les niveaux de compatibilité
que nous avons définis précédemment restent pertinents pour le codage de
signes.
3.4.5 R ELATIONS DE
COMPOSITION ENTRE SIGNES
Jusqu’ici, nous n’avons considéré que des relations d’égalité entre textèmes
et signes individuels. Cependant, à chaque contexte d’usage correspond une
segmentation particulière de l’écriture, segmentation dont nous appelons les
éléments unités pertinentes de l’usage donné. Puisque nous permettons dans
le codage l’apparition de signes appartenant à des usages différents, il se peut
que le codage permette la représentation d’un signe donné aussi bien comme
une seule unité composée que comme la suite de plusieurs signes élémentaires. D’ailleurs, c’est également le cas d’Unicode qui contient aussi bien les
jamo coréens que les syllabes entières, ou encore les traits élémentaires chinois et les caractères précomposés. Par contre, pendant qu’Unicode n’offre
aucun moyen formel d’établir une liaison entre le caractère composé et les caractères composants, la description RDF/OWL formelle du codage de signes
permet la définition de telles relations10 sans problème. L’indication de ces
relations est essentielle pour pouvoir vérifier l’égalité de deux chaînes de textèmes lorsqu’elles sont composées d’unités pertinentes non-équivalentes.
3.4.6 STRUCTURES DE DONNÉES ET OPTIMISATIONS
DANS L’ IMPLÉMENTATION D ’ UN MODÈLE DE TEXTE
GÉNÉ -
RIQUE
Lors de l’examen des possibilités d’optimisation dans le contexte de stockage de documents en textèmes, notre but était principalement la réduction
de la taille des documents. Cette fois-ci, nous partons de l’idée que le texte à
traiter a déjà été chargé en mémoire vive. Nous employons le mot traitement
dans un sens général pour référer à la recherche, à la modification interactive,
à l’affichage (et donc au formatage), à la transformation et même à l’échange
de l’information textuelle. Ces opérations sont parmi les plus courantes exécutées par un ordinateur personnel : lors de l’affichage d’une interface utilisateur
textuelle (e.g., un menu), lors de la visualisation d’une page Web dans un navigateur, lors du traitement de texte, lors de l’affichage des sous-titres d’un film,
lors de l’envoi d’un e-mail, etc. Malgré l’importance toujours grandissante de
10
Ces relations appartiennent, en fait, à la strate T4 puisque chaque entrée du codage des
signes est un textème, élément de T3 .
205
l’audio, de la vidéo et des interfaces graphiques dans notre expérience quotidienne, le texte en reste un ingrédient incontournable.
Dans cette optique, l’accès et le traitement rapides de texte sont essentiels
et doivent, par conséquent, faire partie de nos critères d’évalution de la performance des différents modèles de texte, compte tenu du fait que ce n’est pas
la structure formelle de ces modèles qui doivent être comparées, mais plutôt
leurs implémentations optimisées respectives.
REPRÉSENTATION
EN MÉMOIRE DU TEXTE EN TEXTÈMES
ET DES PROPRIÉTÉS CONTEXTUELLES
La structure interne
du textème
Table associative
Liste chaînée triée
Nous avons pu voir que le modèle théorique du texte en textèmes peut se
décliner en de nombreux différents modèles concrets, chacun d’eux adapté
à des besoins particuliers : il suffit de penser aux différents niveaux de compatibilité Unicode ou aux modèles employant un codage de signes. Bien évidemment, la mise en œuvre et les optimisations possibles varient considérablement de modèle à modèle, ce qui nous oblige à prendre en considération
plusieurs implémentations alternatives.
Il faut tout d’abord préciser que le stockage des propriétés internes et externes ne se fait pas de la même manière. Lorsqu’un textème fait référence à
un caractère ou à un signe donné par l’intermédiaire de son code, il faut bien
évidemment considérer que la totalité des propriétés de ce dernier font partie
du textème. Ces propriétés internes, contenues dans la BD d’Unicode ou dans
une autre ressource, doivent également être stockées de manière optimisée
afin d’être rapidement accessibles. Nous tournerons vers cette problématique
lors de la section suivante ; pour le moment, nous allons restreindre notre
intérêt aux propriétés externes, explicitement ajoutées aux textèmes.
Nous tenons également à mentionner que certaines techniques d’indexation (de clés et de valeurs de propriété, etc.) — déjà expliquées à propos de
l’optimisation des documents en textèmes, cf. p. 183 — peuvent être adoptées
par les bibliothèques de gestion textuelle de bas niveau.
Lorsque nous avons énuméré les opérations élémentaires sur les textèmes
en section 3.4.1, p. 189, nous avons considéré la recherche de propriété (par
clé) au sein du textème comme celle qui est le plus fréquemment employée.
Ce fait semble suggérer une structure associative pour le stockage des propriétés, implémentée par l’intermédiaire d’une table de hâchage ou un arbre trié.
Cependant, de telles structures ont tendance à occuper un espace de mémoire
important en comparaison avec le contenu utile.
Une solution différente est d’employer une simple liste chaînée de propriétés, peu gourmande en consommation de mémoire. La liste chaînée permet
des insertions et des suppressions très rapides, son parcours est par contre linéaire. Il semble donc essentiel de maintenir la liste triée, ce qui augmente la
vitesse non seulement de la recherche (de O(n) à O(log n)) mais aussi d’autres
opérations telles que la comparaison entre textèmes propriété par propriété (de
O(n2 ) à O(n)). Peu importe le critère de tri (lexicographique ou un autre ordre
préétabli), mais il semble utile de garder les propriétés les plus souvent accédées — comme par exemple le code de caractère ou de signe — en début de
liste, dans des positions fixes. Cette solution est d’ailleurs équivalente à celle
des propriétés codées en dur au sein des nœuds de textème d’Ω2 (p. 176).
206
Bien entendu, l’approche qui considère le texte comme une chaîne de
listes (tables de hâchage, arbres, etc.) indépendantes n’est pas la seule possible : lorsque l’occupation de mémoire est un critère plus important que la
performance des opérations textuelles, des structures de données alternatives
peuvent devenir nécessaires. En page 186 nous avons mentionné la possibilité de représenter les propriétés qui présentent une variation peu fréquente au
long de la chaîne non pas textème par textème mais comme des suites d’intervalles (début, fin), en dehors de la structure de données propre au textème.
L’implémentation du modèle M-text suit un principe très similaire. Là, le
texte se présente comme une chaîne de caractères Unicode sur laquelle on
définit une suite d’intervalles par propriété [40, cf. les commentaires dans le
fichier textprop.c]. Si cette solution rend pratiquement toutes les opérations
textuelles de base relativement compliquées, y compris le simple accès à une
propriété attachée à un caractère dans une position donnée, cela est compensée par une implémentation efficace de la bibliothèque m17n en langage C et
par une économie importante d’espace de stockage.
L’implémentation de la liste de propriétés par intervalles est d’autant plus
intéressante comme idée qu’elle offre la possibilité d’intégrer le concept de
propriété de textème avec celui de propriété contextuelle. Rappelons que la
propriété contextuelle peut être définie comme la généralisation de la propriété de textème aux arités supérieures à l’unité. Autrement dit, une propriété
contextuelle s’associe non pas à un signe (ou textème) individuel mais à un
tuple de signes (ou textèmes). Ainsi définie, il y a donc une différence conceptuelle importante entre l’intervalle de propriété et la propriété contextuelle :
alors qu’un intervalle de longueur n n’est qu’une « abréviation » pour un ensemble de n relations unaires, une propriété contextuelle associée à n éléments textuels représente une seule relation d’arité n. Malgré cette différence,
l’intégration des deux types de structure dans un cadre informatique commun
semble être une idée prometteuse.
Cette idée de fusionner au niveau implémentationnel les propriétés de
textème et contextuelles, dans un but de simplification et d’optimisation, nous
amène également vers des considérations conceptuelles. Nous pouvons en
effet nous interroger sur la nécessité même du concept de textème en tant
qu’unité structurelle figée. Il nous semble possible d’imaginer un modèle de
texte dépourvu d’un tel unité atomique textuelle prédéfinie : un modèle qui
décrit le texte non pas comme une suite de textèmes mais comme un ensemble d’intervalles de propriétés qui se chevauchent. Nous explorerons cette
idée à la fin de cette thèse, à propos des perspectives de notre travail.
REPRÉSENTATION
EN MÉMOIRE DU CODAGE DE SIGNES
Nous avons vu que le codage de signes est une représentation formelle
des relations entre les strates T0 (signes) et T1 (propriétés). Nous appelons
table des intensions la table de correspondance qui énumère pour chaque
signe l’ensemble de propriétés le caractérisant, par exemple11 :
11
Ici et dans la suite, pour des raisons de simplicité, nous omettrons de marquer les clés de
propriété, puisque nous ne nous intéresserons qu’aux relations entre les strates T0 et T1 . Les φi
représentent donc des propriétés de T1 .
207
La chaîne de textèmes
Propriétés
en tant qu’intervalles
Intervalles
dans le modèle M-text
Propriétés contextuelles
Intervalles
sans textèmes
s1
s2
s3
..
.
φa , φc , φf , φk , ...
φb , φc , φj , φm , ...
φa , φb , φg , φh , ...
..
.
L’inverse de cette table, que nous appelons table des extensions et qui
met en œuvre la correspondance propriété 7→ signes, sera également gardé en
mémoire afin d’accélérer certaines opérations fréquentes :
φa
φb
φc
..
.
s1 , s3 , s7 , s8 , s12 , ...
s2 , s3 , s4 , s5 , s10 , s15 , ...
s5 , s8 , s12 , s18 , s21 , ...
..
.
S’il existe dans le codage des signes extensionnellement égaux, une table
des classes d’équivalence peut indiquer pour chaque signe la liste de tels
autres signes :
s8
s12
..
.
s12 , s31 , ...
s8 , s31 , ...
..
.
Si l’on possède une description sémantique de propriétés correspondant aux niveaux T2 (clés) et T3 (catégories fonctionnelles), ces informations
peuvent être incluses dans des tables séparées :
– une table qui donne pour chaque clé l’ensemble de valeurs tombant
dessous ;
– une table qui donne pour chaque clé sa ou ses catégorie(s) fonctionnelle(s) ;
– une table inverse qui donne pour chaque catégorie fonctionnelle les
clés y appartenant.
Dans la suite, nous supposerons que pour chaque table l’accès à une entrée donnée se fait en O(1) opérations (à l’aide de hâchage, par exemple), et
aussi que dans les textèmes d’un texte donné, les propriétés sont triées afin de
permettre l’accès à n’importe quelle propriété en temps O(log p), p étant le
nombre moyen de propriétés par textème.
3.4.7 C ALCUL
DE L’ EXTENSION COMMUNE D ’ UN TEXTÈME
Le calcul de l’extension commune d’un ensemble de propriétés s’est montré incontournable pour la vérification de l’égalité extensionnelle, de la dépendance extensionnelle et aussi de l’incohérence des propriétés d’un textème.
Puisqu’il s’agit d’une opération si fréquemment employée, on a certaines exigeances quant à sa performance.
Supposons, pour simplifier notre exemple, que la table des intensions dérivée du codage de signes est la suivante :
208
φa
φb
φc
φd
φe
s2 , s4 , s5
s1 , s2
s1 , s2 , s4
s2
s1 , s2 , s4 , s5
et que le textème dont nous cherchons l’extension commune contient
quatre propriétés, φa , φc , φe et φz . Les étapes de l’algorithme sont les suivantes :
1. On filtre les propriétés externes du textème, leurs extensions étant inconnues. Dans notre exemple, φz est une propriété externe car elle n’est
pas présente dans la table des intensions. Coût : O(p) (p est le nombre
de propriétés dans le textème).
2. On parcourt l’extension de chaque propriété du textème (φa , φc et φe )
en parallèle, en y cherchant la présence de signes communs. Un signe
si fait partie de l’extension commune si et seulement si toutes les lignes
parcourues le contiennent. Puisque les signes se succèdent en ordre,
avec un seul parcours des lignes on arrive à déterminer l’extension commune ; plus précisément, l’algorithme s’arrête lorsque l’on arrive à la
fin de la ligne la plus courte (avec le moins d’éléments). Dans notre
exemple, l’extension commune obtenue est {s2 , s4 }. Le coût de cette
étape de l’algorithme : O(pmin∀i {|ext(φi )|}), où les φi sont les propriétés du textème.
3.4.8 C ALCUL
DE L’ ÉGALITÉ ET DE LA DÉPENDANCE
EXTENSIONNELLES ENTRE TEXTÈMES ET SIGNES
Dans la suite, nous donnerons un algorithme pour calculer l’égalité extensionnelle entre deux textèmes ; une variante simplifiée du même algorithme
peut être utilisée pour le calcul de la dépendance extensionnelle. Il suit, bien
évidemment, le même principe que l’algorithme de calcul d’extension commune, à part quelques optimisations et avec la particularité que les extensions
communes des deux textèmes se calculent en parallèle pour que l’algorithme
puisse s’arrêter à la première différence.
Le temps d’exécution de cet algorithme est fortement dépendant des textèmes actuels à comparer, mais il peut en général être majoré par le nombre
de signes dans le codage multiplié par le nombre de propriétés par textème.
Le coût d’exécution typique peut être bien en-dessous de cette valeur majorée.
En possession des tables des extensions et des intensions, la vérification de
l’égalité de deux textèmes peut se faire à l’aide de l’algorithme suivant :
1. filtrer les propriétés « externes » : leur extensions étant inconnues, elles
ne seront prises en compte dans le calcul.
2. Parcourir les propriétés des deux textèmes en parallèle (y compris l’éventuelle propriété indiquant le code de signe), à la recherche de propriétés identiques (clé1 = clé2 , valeur1 = valeur2 ) ou contradictoires
(clé1 = clé2 , valeur1 6= valeur2 ). Si l’on trouve du premier, les éliminer des deux textèmes, leurs extensions étant naturellement identiques.
Si l’on trouve du dernier, alors on peut conclure sur la non-égalité des
209
deux textèmes, et l’algorithme s’arrête ici12 . Coût : le parcours des deux
textèmes, O(p).
3. Si nécessaire, filtrer les propriétés selon les critères de comparaison (par
exemple, égalité indépendante de casse). Coût : O(f + p), f étant le
nombre de propriétés à filtrer et p le nombre de propriétés par textème.
4. Si un textème contient un code de signe, alors obtenir à partir de la table
des intensions l’ensemble de propriétés correspondantes. Coût : O(1).
5. À partir des propriétés restantes, comparer les extensions communes des
deux textèmes. On calcule l’extension commune respective des deux
ensembles de propriétés. On suppose que chaque liste de signes associée à chaque propriété dans la table des extensions est triée de la même
manière, par exemple selon son code numérique. Voici un exemple
d’entrées de la table des extensions pour les propriétés des textèmes
t1 et t2 à comparer, respectivement :
t1
t2
φa
φc
φd
φb
φk
φl
s4 , s5 , s88 , s154 , s160
s2 , s3 , s5 , s16 , s88 , s154 , s200
s3 , s5 , s17 , s88 , s100 , s154 , s320
s1 , s5 , s16 , s88 , s111 , s404
s4 , s5 , s17 , s88 , s111 , s234
s5 , s88 , s90 , s111
Prenons la propriété de t1 dont l’extension est la plus petite, dans notre
cas φa . Pour t2 , cette propriété est φl . Prenons le premier signe dans la
ligne de φa , à savoir s4 . En parcourant les lignes φc et φd en parallèle, on
vérifie si s4 est présent dans toutes les deux. La réponse est négative (le
parcours s’arrête à s5 car les signes sont en ordre croissant). On continue par s5 : cette fois-ci, la réponse est positive. On passe au textème
t2 , afin d’y trouver, à la même manière, le signe le plus petit caractérisé
à la fois par φb , φk et φl . Il s’agit également de s5 , donc pour le moment
on n’a pas trouvé de différence au niveau des extensions communes de
t1 et de t2 . En continuant, on trouve que s88 satisfait les mêmes critères,
donc pour le moment extc(t1 ) = extc(t2 ) = {s5 , s88 }. Ensuite, extc(t1 )
s’étend par s154 et extc(t2 ) par s111 : cette première différence suffit pour
conclure sur t1 6= t2 , l’algorithme s’arrête donc ici. Dans le cas contraire,
il aurait fallu continuer avec le même procédé jusqu’au parcours complet de φa et de φl . Quant au coût de cette étape de l’algorithme, il
est très difficile d’en donner une estimation correcte car le nombre de
comparaisons élémentaires à effectuer dépend de nombreux facteurs,
dont le nombre et la distribution de signes par propriété et le nombre de
propriétés. Il peut néanmoins être majoré par


|t1 |
|t2 |
X
X
|ext(φ1i )| +
|ext(φ2j )|
O
i=1
j=1
12
Nous supposons toujours (cf. p. 101) que les valeurs d’une clé de propriété sont « disjointes », c’est-à-dire que pour deux valeurs (t(1)1 , t(1)2 ∈ T1 ) quelconques non-identiques
(t(1)1 6≡ t(1)2 ) apparentant à la même clé (∃t(2) ∈ T2 tq. t(1)1 , t(1)2 ∈ ext(t(2) )), elles ont
une intersection vide : ext(t(1)1 ) ∩ ext(t(1)2 ) = ∅.
210
φ1i et φ2j étant les propriétés de t1 et de t2 , respectivement. Ce coût, à
son tour, peut être majoré par O(2SP ), S étant le nombre total de signes
et P le nombre total de propriétés dans le codage, mais il s’agit d’un cas
aberrant : aussi bien les deux textèmes que tous les signes du codage
sont caractérisés par toutes les propriétés à la fois.
3.4.9 R ECHERCHE DE
RELATIONS DE SPÉCIALISATION
OU DE GÉNÉRALISATION ENTRE UN TEXTÈME DONNÉ
ET LES ÉLÉMENTS DU CODAGE DE SIGNES
Parmi les algorithmes liés à la compatibilité entre le texte en textèmes et le
texte en signes codés, le dernier que nous allons considérer sert à trouver pour
un textème t donné les signes du codage qui lui sont soit extensionnellement
égaux, soit en relation d’héritage avec lui (généralisation ou spécialisation).
En résumé, il s’agit de parcourir toutes les lignes de la table des intensions en
parallèle (une ligne de la table contient toutes les propriétés qui caractérisent
un signe précis), une seule fois.
Prenons comme exemple un textème t = {φa , φc , φe , φg } et la table des
intensions suivante :
s1
s2
s3
s4
s5
φb , φc , φe , φf
φa , φc , φe , φf
φa , φc , φe
φb , φd , φf
φa , φe
Tout d’abord, comme dans les algorithmes précédents, on élimine depuis
le textème les propriétés externes au codage, dans notre cas φg . À partir des
propriétés restantes, on attend que l’algorithme fournisse le résultat suivant : t
est extensionnellement égal à s3 , il est la spécialisation de s5 et la généralisation de s2 .
Ces résultats seront obtenus à l’aide d’un tableau que nous allons remplir
au fur et à mesure :
s1
s2
s3
s4
s5
φa
φc
φe
La cellule (φi , sj ) contiendra « X » si l’intension du signe sj contient φi ,
sinon elle contiendra « × ». Le parcours commence par la première propriété
de textème, φa , que nous appellerons propriété courante. (Comme jusqu’ici,
nous supposons qu’il existe une relation d’ordre totale entre propriétés, à l’aide
de laquelle sont triées aussi bien les propriétés de textème que les propriétés de signe de la table des intensions.) Les lignes de la table des extensions
sont parcourues en parallèle, dans chaque ligne jusqu’à la première propriété
identique ou supérieure à la propriété courante. (Le symbole « ⌊ » indiquera la
position courante dans la table des extensions.) Les lignes qui contiennent la
propriété courante (φa ) sont marquées dans le tableau de résultat par « X », le
reste par « × » :
211
s1
s2
s3
s4
s5
⌊φb , φc , φe , φf
φa , ⌊φc , φe , φf
φa , ⌊φc , φe
⌊φb , φd , φf
φa , ⌊φe
φa
φc
φe
s1
×
s2
X
s3
X
s4
×
s5
X
Ensuite, on prend la propriété courante suivante, φc . On avance dans
chaque ligne jusqu’à ce que l’on ne rencontre φc ou une propriété supérieure.
Si entretemps on dépasse une propriété (forcément absente du textème t), alors
on « marque » le signe correspondant (ici par une étoile) :
s1 ∗
s2
s3
s4 ∗
s5
φb , φc , ⌊φe , φf
φa , φc , ⌊φe , φf
φa , φc , ⌊φe
φb , ⌊φd , φf
φa , ⌊φe
φa
φc
φe
s1 ∗
×
X
s2
X
X
s3
X
X
s4 ∗
×
×
s5
X
×
La dernière propriété du textème t est φe , qui maintenant devient propriété
courante :
s1 ∗
s2
s3
s4 ∗
s5
φb , φc , φe , ⌊φf
φa , φc , φe , ⌊φf
φa , φc , φe ⌊
φb , φd , ⌊φf
φa , φe ⌊
φa
φc
φe
s1 ∗
×
X
X
s2
X
X
X
s3
X
X
X
s4 ∗
×
×
×
s5
X
×
X
À ce point, toutes les propriétés de t ont été considérées, et notre tableau
est rempli. Il faut cependant continuer le parcours de la table des intensions,
ou du moins de ses lignes non encore marquées : dans notre cas, s2 , s3 et s5 .
Ces deux dernières sont terminées, mais dans la ligne de s2 il reste encore une
dernière propriété φf . Celle-ci est une propriété absente du textème t, il faut
donc marquer s2 également. Le parcours se termine ici, et donne le résultat
suivant :
s1 ∗
s2 ∗
s3
s4 ∗
s5
φb , φc , φe , φf ⌊
φa , φc , φe , φf ⌊
φa , φc , φe ⌊
φb , φd , φf ⌊
φa , φe ⌊
φa
φc
φe
s1 ∗
×
X
X
s2 ∗
X
X
X
s3
X
X
X
s4 ∗
×
×
×
s5
X
×
X
Le tableau que nous avons rempli s’interprète de la manière suivante :
– une colonne non marquée (par une étoile) qui ne contient que des « X »
représente un signe qui est extensionnellement égal à t ;
– une colonne marquée qui ne contient que des « X » représente un signe
qui est la spécialisation de t ;
– une colonne non marquée qui contient au moins un « X » et au moins
un « × » représente un signe qui est la généralisation de t.
Pour calculer le coût de l’algorithme, soit S le nombre total de signes dans
le codage (le nombre de lignes de la table des intensions), P le nombre total
de propriétés utilisées dans le codage, et p le nombre de propriétés dans t.
(Dans notre exemple, S = 5, P = 6 et p = 3.) Chaque ligne de la table des
extensions est parcourue une seule fois, et le nombre de comparaisons faites
212
dans la ligne i est max{|int(si )|, p}. Le coût est donc


|S|
X
max{|int(si )|, p} ≤ O(SP )
O
i=1
parce que max{|int(si )|, p} ≤ P .
3.4.10 CONCLUSIONS SUR L’UTILISABILITÉ PRATIQUE
D ’ UN CODAGE DE SIGNES INTENSIONNEL
Nous avons présenté les algorithmes précédents afin de démontrer que
l’existence d’un codage de signes rend effectivement possible la vérification
de diverses relations extensionnelles (égalité, dépendance, généralisation, spécialisation) entre deux textèmes ou entre un textème et les signes codés. En
même temps, nous avons trouvé que le coût de ces algorithmes est relativement élevé : il est proportionnel au nombre de propriétés multiplié par le
nombre de signes dans le codage. Certes, le produit de ces deux constants est
un très grand nombre, mais dans des situations réelles — lorsque les textèmes
et les signes sont caractérisés par relativement peu de propriétés, et on ne s’intéresse qu’à un sous-ensemble réduit de signes (tel que les signes de l’écriture
latine) — ils se réduisent drastiquement. De plus, puisqu’il s’agit de nombres
constants, avec l’augmentation de la puissance des ordinateurs le coût de ces
algorithmes devient de moins en moins critique.
213
214
CHAPITRE 4
CONCLUSIONS ET
PERSPECTIVES
4.1 RÉSUMÉ DES RÉSULTATS
Nous avons entamé cette thèse avec l’objectif d’analyser en détail les modèles de texte informatiques actuels afin de repérer leurs défauts et leurs limitations éventuelles. Ainsi, nous avons consacré un intérêt particulier au codage de caractères Unicode, aux fontes intelligentes et au modèle de texte
caractère-glyphe qui établit une connexion entre les représentations (et les
usages) d’échange et finale. Nous avons trouvé que la plupart des problèmes
liés à ce modèle remontent à sa nature fondamentalement extensionnelle, au
fait qu’il considère les éléments textuels comme de simples entrées d’une table
de codage. Cette approche s’est avérée trop rudimentaire pour être à la base
d’un modèle de texte qui vise l’universalité, aussi bien au niveau des écritures
qu’au niveau des usages couverts.
D’autre part, en réponse à ce défaut, nous avons observé chez Unicode
les premiers signes d’une transition vers un mode de représentation intensionnelle, dans la forme d’une base de données de propriétés associées aux caractères. Le même phénomène s’est produit pour le modèle de texte formaté,
lorsque les fontes sont devenues « intelligentes ». Certaines autres technologies, comme le modèle de texte typographique du format de fonte Graphite
et surtout le modèle M-text, ont poursuivi ce changement d’orientation par
l’ouverture de la possibilité de créer des propriétés définies par l’utilisateur et
de les attacher au texte.
Par l’introduction d’un nouveau cadre formel de modélisation de texte,
nous avons souhaité examiner la possibilité théorique et pratique d’une représentation textuelle informatique intensionnelle et complètement ouverte.
Dans ce but, nous avons emprunté une méthodologie développé initialement
dans un contexte de représentation des connaissances, à l’aide duquel nous
avons réussi à formaliser des notions telles que propriété, caractère, glyphe ou
contexte d’usage. Du même cadre a découlé l’idée de généraliser l’unité textuelle en la considérant comme un ensemble de propriétés librement choisies,
ensemble que nous avons nommé textème.
Le textème s’est montré utile, entre autres, pour représenter des signes
d’écriture et en général des propriétés textuelles absentes du codage Unicode,
car il fournit une méthode d’enrichissement du texte alternative au balisage, ce
dernier étant normalement prévu pour la structuration d’unités textuelles plus
conséquentes. Aussi, l’interprétation libre de ce que représente un textème ou
une propriété de textème nous a permis d’élargir notre conception du texte
informatique, et d’y introduire des entités textuelles novatrices comme par
exemple les signes d’écriture probabilistes ou les textèmes-balises.
215
Le modèle
caractère-glyphe
Approches liées à la RC
parmi les modèles
existants
La possibilité
de la modélisation
de texte sur des bases
intensionnelles
L’intérêt du textème
Mais avant tout, le textème a permis de créer les fondements théoriques
d’un modèle de texte extensible et indépendant d’usage, à l’opposé du modèle
caractère-glyphe où la chaîne Unicode et la chaîne de glyphes correspondent
à des usages prédéterminés. Dans le cas d’un texte en textèmes, le contexte
d’usage détermine la catégorie fonctionnelle à laquelle appartiennent les propriétés présentes dans les textèmes. Il détermine également le choix d’unité
pertinente, c’est-à-dire la segmentation de l’écriture en unités élémentaires
auxquelles correspondront les textèmes. Dans le modèle caractère-glyphe,
l’acte de changement d’usage se traduit par un passage depuis la chaîne de
caractères vers la chaîne de glyphes pour l’opération de formatage, et dans
La problématique l’autre sens pour l’extraction de contenu à partir du document formaté. Dans
de changement d’unité le modèle en textèmes, un changement d’usage se réalise par l’ajout de noupertinente velles propriétés aux textèmes (et par la suppression éventuelle d’autres), mais
aussi par un changement d’unité pertinente si nécessaire. Le modèle caractèreglyphe résoud ce dernier problème par la maintenance parallèle de la chaîne
de caractères et de la chaîne de glyphes, avec une table de correspondance
qui permet le passage depuis l’un vers l’autre. Dans le modèle en textèmes,
la même chaîne peut subvenir à plusieurs usages à la fois tant que les unités
pertinentes d’écriture restent les mêmes ; sinon, le modèle doit être étendu
d’une manière ou d’une autre : par la représentation soit de plusieurs signes
par le même textème, soit d’un seul signe par plusieurs textèmes. L’« impureté »
conceptuelle des deux solutions reflète que le modèle en textèmes, du moins
dans sa formulation la plus simple, ne prévoit pas la représentation simultanée
d’usages qui segmentent différemment la même écriture.
Le textème s’adapte
aux différents usages
L’inévitabilité
La relation qu’entretiennent les textèmes adjacents représentant le même
du contexte signe (comme par exemple une ligature) n’est qu’un parmi de nombreux
exemples où l’information doit être considérée inter-textémique plutôt qu’intratextémique. Il s’agit tout simplement du fait que toute information textuelle ne
se traduit pas forcément en propriété de textème, soit parce que l’information
s’attache clairement à une unité structurelle de plus haut niveau, soit parce
qu’une propriété de textème peut être généralisée pour un morceau de texte
entier lorsque chacun de ses textèmes la partage, soit parce qu’il s’agit d’une
relation entre plusieurs textèmes d’un texte donné. Nous avons appelé ce type
d’informations contextuelles car conceptuellement elles ne font pas partie du
textème : elles se distinguent par le fait que l’arité des éléments de l’extension
de la première est supérieure à l’unité. Le contexte et les propriétés contextuelles sont donc des ingrédients incontournables dans la modélisation de
texte, puisque c’est à travers elles que les éventuelles relations et interactions
entre unités textuelles peuvent être décrites.
La dépendance :
Le phénomène de dépendance est une forme de contextualité non pas
une forme entre signes mais entre propriétés de textème, où la valeur d’une ou de plude contextualité sieurs propriété(s) donnée(s) détermine celle d’une autre. L’existence d’une
dépendance entre deux propriétés peut parfois découler d’une nécessité logique (comme le rapport entre le radius et la surface d’un sphère) mais, au
plus général, il s’agit d’une conséquence des « réalités factuelles » du monde
que l’on observe et que l’on modélise : si la valeur d’une propriété A détermine celle d’une propriété B, c’est parce qu’il se trouve qu’il n’existe pas
216
d’objets dans le monde modélisé qui aient la propriété A mais non B1 . Il n’est
donc pas surprenant que la dépendance n’est pas un phénomène unique au
modèle de texte en textèmes ; au contraire, il est récurrent dans tout modèle
qui entreprend une certaine forme de représentation des connaissances. Dans
cette thèse, nous avons appelé cette définition de la dépendance dépendance
extensionnelle, car elle lie le phénomène aux relations ensemblistes entre les
extensions des propriétés (c’est-à-dire entre les ensembles de signes qu’elles
caractérisent).
Cependant, si nous ne nous contentons pas de la description théorique
du phénomène mais nous cherchons à automatiser, d’une façon ou d’une
autre, la gestion des dépendances au sein du texte afin d’éviter une combinaison de propriétés jugée invalide, alors la définition précédente nous sera
peu utile, étant donné que nous n’avons pas — et ne pourrons jamais avoir
— une connaissance exhaustive de la totalité des signes d’écriture du monde
et de toutes leurs propriétés. Pour cette raison, nous avons créé une définition
alternative et restreinte de la notion de dépendance, que nous avons appelé
algorithmique, en liant l’existence de celle-ci à l’obtention de la valeur de propriété par l’intermédiaire d’un algorithme informatique. Ceci nous a permis de
concevoir des solutions informatisables de suivi de dépendances.
La relation d’égalité entre propriétés et entre textèmes est un autre problème auquel nous avons consacré une attention particulière. En effet, la vérification d’égalité entre deux textes est à la base de nombreuses opérations
textuelles courantes (la recherche, l’indexation, la comparaison, etc). L’identité
superficielle de deux textes, textème par textème et propriété par propriété, est
évidemment un critère d’égalité suffisant mais pas forcément le plus utile, tout
comme la comparaison de deux chaînes Unicode ne se fait pas forcément à
travers les codes de caractère seuls. Par contre, à l’opposé d’Unicode où le
code numérique est incontournable car il est le seul à fournir l’identité du
caractère, l’identité du signe (ou des signes) représenté(s) par le textème est
entièrement définie par l’ensemble de ses propriétés, et dans une première
approximation, par l’extension commune de celles-ci. Ainsi, deux propriétés
sont extensionnellement égales si elles caractérisent exactement les mêmes
signes, et l’égalité extensionnelle de deux textèmes est définie comme l’égalité ensembliste de leurs extensions communes respectives.
L’égalité extensionnelle n’est en même temps qu’une parmi les définitions
possibles de la relation d’égalité. Parfois, ce critère seul est insuffisant et les intensions des propriétés doivent également être prises en compte (par exemple,
leur appartenance à la même catégorie fonctionnelle). Le plus grand problème
de l’égalité extensionnelle reste cependant le fait qu’en pratique nous n’avons
pas une connaissance totale de l’ensemble de base de signes, et par conséquent nous ne connaissons pas non plus les extensions des propriétés. Dans
sa généralité, l’égalité extensionnelle entre deux propriétés est impossible de
vérifier en pratique pour exactement la même raison qu’il est impossible de
vérifier leur dépendance extensionnelle.
En partie en réponse à ces problèmes, nous avons proposé dans le chapitre 3 une solution pratique à la description intensionnelle de propriétés à
1
Bien entendu, nous sommes en train de simplifier ici : il se peut également que de tels
objets existent mais nous les jugeons non importants pour notre modèle, etc.
217
Gestion automatique
des dépendances
Formes d’égalité
entre propriétés
et entre textèmes
La non-vérifiabilité
de l’égalité
extensionnelle
Description sémantique
des propriétés
Description sémantique
des signes
Codage de signes
intensionnel
La conversion
d’Unicode en codage
de signes
l’aide des langages RDF et OWL. Il s’agit de mettre en place une description
sémantique qui peut comprendre une référence vers un espace de nommage,
des catégories fonctionnelles auxquelles appartient la propriété et aussi des
formulations explicites d’égalité avec d’autres propriétés. Puisque le modèle
de texte en textèmes promeut l’invention et l’usage libres de propriétés « custom » dans les textes, la sémantisation des propriétés devient incontournable
si l’on souhaite que de tels textes soient interprétables par des logiciels tiers,
au moins partiellement.
Cette méthode permet la description de l’intension des propriétés, c’est-àdire des différents rapports qu’elles entretiennent entre elles ainsi qu’avec des
relations de rangs supérieurs. Intuitivement, on peut également envisager de
poursuivre la même méthode descriptive vers la strate T0 inférieure, afin de
définir les extensions des propriétés : les rapports entre les propriétés et les
signes qu’elles caractérisent. Rappelons que la raison pour laquelle ni la définition extensionnelle de la dépendance ni celle de l’égalité entre propriétés
ne sont utiles en pratique est précisément que ces extensions sont en général inconnues2 . Si, par contre, on restreint l’ensemble de base de signes (le
contenu de la strate T0 de notre cadre formel de modélisation) à une taille
maîtrisable (par exemple, de l’ordre de grandeur du codage Unicode), alors il
devient possible de déterminer exactement l’extension de chaque propriété,
ce qui permet ensuite de vérifier les relations ensemblistes de compréhension
et d’égalité entre propriétés.
L’idée, développée en fin du chapitre 3, est donc de créer un codage de
signes intensionnel qui intègre les avantages des codages traditionnels avec
une approche intensionnelle grâce aux textèmes. Nous cherchons ainsi à obtenir un catalogue de signes restreint mais extensible, chacun d’eux étant caractérisé par une gamme étendue de propriétés mais aussi par des relations
qui le connectent à d’autres signes du codage (par exemple, une relation ( ,
, , ) peut établir l’égalité d’une syllabe hangûl à la séquence de ses trois
composants jamo).
Une différence majeure entre le codage Unicode et notre codage de signes
est que dans ce dernier l’identifiant numérique — le code de signe — n’est plus
la seule information permettant la vérification de l’identité d’un élément textuel ni de l’égalité entre deux éléments textuels. Ainsi, pour comparer deux
textèmes composés de couples clé-valeur, il suffit de trouver leurs extensions
communes respectives3 et puis de vérifier l’égalité des deux ensembles obtenus, une opération exécutable en un temps proportionnel au carré du nombre
de propriétés par signe. Entre autres, le codage Unicode peut être converti
en codage de signes sans perte de compatibilité vers les systèmes existants.
D’abord, il s’agit d’étendre la gamme de propriétés associées aux caractères,
en commençant par leur identité (e.g., la description « LATIN CAPITAL LETTER
A » peut être formalisé par quatre propriétés). Ensuite, la génération de la table
de correspondance propriété 7→ caractères est triviale.
2
Car, on ne peut répondre à des questions telles que « quels sont, en général, tous les signes
rouges ? » ou « est-ce qu’il existe du texte français écrit dans un système d’écriture autre que le
latin ? ».
3
C’est-à-dire l’intersection des ensembles de signes correspondant à chaque couple clévaleur.
218
4.2 CONCLUSIONS
Dans cette thèse, nous avons proposé une approche intensionnelle à la
modélisation de texte, sur laquelle nous avons ensuite fondé un ensemble de
modèles autour du concept de textème. Nous avons examiné ces modèles de
nombreux points de vue et nous les avons comparés aux modèles existants,
notamment à celui basé sur le codage Unicode et les fontes intelligentes. À
ce point, il est sans doute utile de dresser un bilan objectif des résultats obtenus, entre autres d’un point de vue pragmatique : qu’est-ce que les modèles
proposés peuvent offrir aux systèmes informatiques d’aujourd’hui ? Quels seraient les effets de court et de long terme de l’adoption de ces modèles sur les
usages textuels informatiques ?
Un des résultats les plus intéressants de la thèse est probablement la reconnaissance de l’importance grandissante des approches liées à la représentation des connaissances dans la modélisation de texte. Le fait qu’Unicode et
les formats de fonte intelligents ont tous les deux adoptés, du moins partiellement, des formes de description intensionnelles — des bases de données de
propriétés, des règles de combinaison de glyphes, etc. — prouve qu’il existe
aujourd’hui une réelle besoin de création de modèles de texte « intelligents ».
Ce que nous considérons comme l’objectif primaire de cette thèse est la tentative de généraliser ces diverses manifestations d’intelligence dans le cadre
d’une approche formelle basée sur la représentation des connaissances.
La définition formelle de l’élément textuel généralisé, le textème, a tourné
notre attention vers des réflexions sur l’atomicité des éléments textuels.
Comme les atomes de la matière physique, ces unités ne sont plus considérées indivisibles puisqu’elles représentent des conglomérats de propriétés.
Néanmoins, les textèmes restent les briques de base du texte numérique, car
ce sont à partir d’eux que la chaîne unidimensionnelle est construite.
Si une telle vision de l’unité textuelle semble, au premier regard, contreintuitive et compliquée à une personne habituée à des alphabets de petite
taille, elle l’est sans doute moins pour, par exemple, un Chinois ou un Japonais qui a un regard plus « constructiviste » sur les éléments de son écriture.
Notons qu’à la même personne occidentale un modèle de texte qui distingue
entre l’abstrait qui est le caractère et le concret qui est le glyphe n’est pas forcément intuitif non plus. Heureusement, l’intuitivité du modèle ne concerne
pas directement l’utilisateur final car il n’accède jamais au texte autrement
qu’à travers une interface homme-machine : un usager d’un logiciel de traitement de texte n’a pas besoin de comprendre la structure interne du textème,
tout comme il n’a pas besoin de comprendre la différence entre caractère et
glyphe.
En même temps, la compréhension théorique que nous avons pu tirer du
formalisme établi nous a servi, d’une part, à mieux définir ce que l’on entend, justement, par caractère ou glyphe. La notion clé qui a permis de réunir
ces deux concepts sous une théorie unique est celle de l’usage : c’est par sa
capacité de s’adapter aux différents usages — et les propriétés qui leur appartiennent — que le modèle de texte en textèmes devient flexible et polyvalent.
Ceci étant dit, nous avons dû reconnaître qu’à différents usages peuvent correspondre différents unités pertinentes d’écriture, ce qui relativise la polyvalence
219
Besoin de modèles
de texte « intelligents »
et d’approches RC
L’atomicité de l’élément
textuel
Définition des notions
de caractère, de glyphe
et d’usage
de la chaîne de textèmes en tant que texte « multi-usages ».
Interactions entre
Ces réflexions nous ont inévitablement menées à identifier les limites
atomes textuels : d’une approche qui considère le texte comme une suite d’atomes indépendépendances dants. En effet, les phénomènes de contextualité et de dépendance observés
et contextualité sur des exemples concrets de textes en textèmes ne sont pas propres à ce mo-
dèle : on les retrouve, entre autres, au sein du texte Unicode et aussi entre
la chaîne de caractères et la chaîne de glyphes. Il s’agit, en réalité, de phénomènes qui n’échappent à aucun modèle qui vise à décrire un fragment
suffisamment complexe du monde ; ce n’est donc pas un hasard que l’introduction d’un contexte formalisé et de méthodes de gestion de dépendances est
lieu commun parmi les différentes approches à la représentation des connaissances. Il n’y a donc aucune doute sur la nécessité de l’extension du modèle
en textèmes par une forme de gestion de contexte.
Ayant reconnu l’insuffisance du concept de textème et de propriété de
textème vis-à-vis de ces problèmes, nous avons tenté une formalisation des
propriétés contextuelles et des dépendances ; en vue des points précédents, le
fait que nos solutions proposées soient si similaires à celles développées dans
d’autres domaines n’est guère surprenant. Cependant, à l’opposé de méthodes
développées dans un cadre scientifique tel que l’intelligence artificielle, la
création et la manipulation de texte sont des pratiques quotidiennes qui ne
sont pas, et ne devraient pas devenir, des actes nécessitant une compréhension
profonde des modèles de texte sous-jacents. Par conséquent, des méthodes sophistiqués de gestion de dépendances et de contexte ne conviennent pas pour
des usages où l’utilisateur exige que le texte soit manipulable d’une manière
transparente. C’est pour la même raison que nous avons proposé des solutions ad hoc d’ingénierie, adaptées à des usages précis, au lieu d’un système
d’inférences générique, puissant mais très probablement non réalisable.
L’intérêt du modèle
Dans la même optique, nous avons envisagé plusieurs scénarios quant à
en textèmes l’utilisation pratique des différents modèles fondés sur le concept de textème.
dans l’application Ω Nos expériences de l’implémentation d’une variante de modèle sur la plate-
forme Ω ont prouvé que nos idées théoriques peuvent montrer leur utilité
au sein d’une application de composition de documents, en la rendant plus
puissant (par la gestion simultanée du caractère et du glyphe), plus extensible
(par l’ajout de propriétés définies par l’utilisateur à travers des modules externes) et plus simple (par la suppression de certains types de nœuds). D’autre
part, le succès de l’implémentation a montré que le modèle peut être intégré sans grandes difficultés dans le code source d’un logiciel écrit dans les
années 1980.
La normalisation
Nous avons également considéré l’utilité du modèle en tant que médium
des propriétés d’échange, aussi bien dans le cadre de documents en textèmes qu’en tant
que modèle générique implémenté au niveau du système d’exploitation. Bien
évidemment, l’échange d’information textuelle entre applications sous-entend
la connaissance d’un format commun. Or, si les modèles de texte extensionnels (comme le texte en caractères ASCII) reposent sur un ensemble normalisé
d’éléments textuels, à savoir le codage de caractères, les modèles intensionnels, eux, requièrent la normalisation des propriétés. En connaissance des difficultés ahurissantes de la création de normes internationales, et notamment
220
les enjeux politiques qu’ont dû surmonter les créateurs de la norme Unicode4 ,
nous sommes conscients du fait que la probabilité du succès d’une norme
similaire pour les propriétés de textème tend vers zéro. En effet, l’adoption
mondiale de la norme Unicode doit déjà être considérée comme un succès
durement gagné.
En vue de ces difficultés insurmontables, la solution que nous avons proposée au problème de normalisation tente de contourner ces problèmes par
la proposition d’une norme extensible et décentralisée, dont la mise en œuvre
est rendue possible par des technologies telles que XML (qui fournit le concept
d’espace de nommage, et donc l’identification unique des propriétés) ou
RDF (qui, en tant qu’outil informatique développé pour la représentation des
connaissances, permet la description formelle des propriétés). Le Web, à son
tour, permet la répartition des définitions, pour que l’invention d’une nouvelle
propriété liée à un nouvel usage ne soit pas contrainte par une procédure quelconque de normalisation centralisée.
Nous considérons que le cadre de description formelle de propriétés proposée dans cette thèse est une idée à part entière qui est intéressant même
indépendamment de l’adoption éventuelle d’un modèle de texte en textèmes.
Si la base de données d’Unicode formalise les correspondances entre caractères et propriétés, ces dernières ne possèdent que des définitions textuelles
informelles. Tant que la gamme de propriétés Unicode reste limitée, une telle
approche suffit, mais si les nouveaux usages poussent la Consortium Unicode
à l’élargissement de cet ensemble, alors la situation pourra très vite ressembler
à celle de l’explosion du nombre de caractères codés : comme la description
intensionnelle des caractères, celle des propriétés deviendra également inévitable.
Des considérations de compatibilité avec les modèles existants, ainsi que
d’optimisation de stockage et de traitement, nous ont menés à l’idée de réunir
dans un seul modèle les avantages des approches intensionnelle et extensionnelle. D’une part, le codage Unicode est incontournable aujourd’hui, et il le
restera sans doute pendant encore bien longtemps. Pragmatiquement parlant,
il serait donc illusoire de proposer — du moins pour un usage général et à
court terme — un modèle alternatif qui, de plus, va à l’encontre de la plupart des principes de la modélisation textuelle en usage depuis le XIXe siècle.
D’autre part, l’intérêt pratique du code de caractère en tant que représentation
compacte d’un signe d’écriture est, bien sûr, loin d’être négligeable.
Heureusement, nous avons trouvé que le concept de textème pouvait très
bien être reconcilié avec le principe de codage. D’une part, le textème peut
référer à un élément textuel codé à travers une propriété numérique, la description de celui-ci pouvant être étendue par des propriétés supplémentaires
au sein du même textème. La chaîne de caractères peut donc être considérée
comme un cas spécial de la chaîne de textèmes. D’autre part, par la formalisation et l’extension du codage de caractères Unicode on obtient ce que nous
avons appelé un codage de signes intensionnel qui, tout en restant compatible
avec le codage de caractères, intègre, de plus, la notion d’usage et par cela
ouvre le modèle de texte vers de nouveaux usages potentiels. C’est donc dans
4
Si nous possédons un aperçu de ce genre de problèmes, c’est avant tout grâce au témoignage personnel de M. Éric Muller, membre illustre du comité technique d’Unicode.
221
Une norme
décentralisée
Codage de signes :
la synthèse
des approches
intensionnel
et extensionnel
Un intérêt immédiat
des résultats :
l’extension d’Unicode
l’extension du codage Unicode par des connaissances intensionnelles formalisées que nous voyons l’intérêt immédiat des résultats avancés dans cette thèse,
à part bien sûr l’implémentation éventuelle du modèle de texte en textèmes
dans des applications autonomes, telles que le logiciel Ω.
4.3
PERSPECTIVES D’USAGE ET D’ÉVOLUTION
POUR LES MODÈLES DE TEXTE INTENSIONNELS
Dans cette section terminale nous souhaitons aborder certains aspects de
notre travail auxquels nous avons déjà référé mais qui n’ont cependant pas pu
être développés dans le cadre de cette thèse. Le sujet peut-être le plus important est l’influence du textème sur l’interface homme-machine de manipulation de texte. Un autre sujet intéressant est lié au problème de la représentation
de multiples usages, chacun ayant des unités pertinentes d’écriture différentes,
au sein d’une chaîne de textèmes. Nous allons esquisser un modèle de texte
alternatif qui contourne ce problème en se débarrassant du concept de textème.
4.3.1 L ES
ASPECTS INTERFACE HOMME - MACHINE
DES MODÈLES DE TEXTE EN TEXTÈMES
L’impossibilité
d’adresser
la problématique
de l’IHM dans le cadre
de cette thèse
Quelques problèmes
de caractère intuitif
En chapitre 2 nous avons introduit et analysé le concept de textème d’un
point de vue théorique, pour ensuite passer aux questions d’implémentation
en chapitre 3. La pièce manquante du puzzle, d’une importance égale aux
deux aspects précédents, est l’examen du rapport qui existe entre le modèle et
l’utilisateur : comment le remplacement du modèle Unicode par un modèle
en textèmes peut changer les pratiques liées à la manipulation du texte dans le
contexte d’une application donnée, telle qu’un logiciel de traitement de texte,
un éditeur simple, le texte immuable d’une boîte de dialogue, etc.
La problématique de la conception d’interfaces de manipulation de texte
et de l’influence mutuelle entre celle-ci et le modèle sous-jacent est, évidemment, un domaine de recherche auquel nous ne pourrions pas faire justice
dans le cadre de cette thèse, pour plusieurs raisons. Tout d’abord, la conception IHM est une science à part entière dont l’auteur n’est malheureusement
pas en possession de connaissances théoriques adéquates qui seraient pourtant essentielles afin d’éviter une approche fondamentalement naïve. De plus,
une étude rigoureuse du domaine aurait largement dépassé le cadre de cette
thèse. Nous avons donc décidé qu’il était préférable de ne point adresser la
problématique de l’IHM plutôt que de tenter à mettre en place une étude forcément restreinte qui, de plus, manquerait probablement de rigueur.
Néanmoins, même sans connaissances théoriques dans la conception d’interfaces homme-machine de manipulation de texte, de nombreuses questions
spécifiques surgissent intuitivement, inspirées de nos expériences des pratiques textuelles courantes, que nous souhaitons aborder dans le cadre des
perspectives, ne serait-ce que par simple mention.
– Dans quels usages/applications la structure théorique du textème — le
fait qu’il est composé d’un ensemble de propriétés — transparaît-elle à
travers l’interface utilisateur ?
222
– Un éditeur de texte simple (c’est-à-dire plutôt du genre « bloc-notes » que
« Word ») mais adapté au texte en textèmes n’est pas forcément censé (ni
capable de) faire transparaître la totalité de propriétés que possèdent les
signes à travers leur apparence visuelle sur l’écran. Comment résoudre,
alors, le problème de l’incongruence qui peut potentiellement exister
entre la visualisation des signes et les propriétés de textème les décrivant, afin d’éviter une situation de « dissonance cognitive » de la part de
l’utilisateur ?
– Est-ce qu’on peut imaginer des cas d’utilisation où l’utilisateur peut modifier les propriétés de textème arbitrairement ?
– Si la réponse à la question précédente est affirmative, alors comment
gérer les éventuels problèmes de dépendance introduits par les modifications de l’utilisateur ?
– Comment l’utilisateur peut-il appréhender les concepts tels que dépendance, contexte et propriété contextuelle ? Comment est-ce qu’ils
peuvent être « traduits » à travers l’interface ?
– Lors d’un copier-coller, est-ce que l’utilisateur exerce un contrôle sur
l’ensemble de propriétés transmises, y compris les éventuelles propriétés contextuelles ?
Le lecteur a certainement noté qu’il n’existe probablement pas de réponses
uniques et définitives à ces questions, car elles dépendent avant tout de l’environnement (des applications, des usages) dans lequel s’intègre l’interface.
Des solutions concrètes ne peuvent donc être proposées que dans le cadre
d’usages préalablement spécifiés. Cependant, il ne serait sans doute pas suffisant comme méthodologie de considérer uniquement les usages et les applications existants et bien connus, car ces usages et applications sont intimement
liés à leur modèle de texte sous-jacent.
Ainsi, les éditeurs de texte brut développés pour du texte ASCII sont des
logiciels simples aussi bien au niveau implémentationnel qu’au niveau d’utilisation. Lorsque le modèle de texte basé sur le codage ASCII est remplacé par
celui basé sur Unicode, le même genre d’éditeur de texte se complexifie considérablement au niveau implémentationnel et aussi à un certain degré au niveau de l’interface (gestion de coupures de ligne, de caractères combinants, de
directionnalité, etc.). Néanmoins, l’éditeur de texte Unicode maintient, malgré tout, son aspect « bas niveau » qui permet l’accès et la modification des
caractères individuels. Tout change lorsque l’on imagine un éditeur de texte
en textèmes, au point que les critères de simplicité d’utilisation et d’accès bas
niveau deviennent presque contradictoires. Ainsi, un éditeur simple et intuitif
n’autorisera probablement pas l’affichage complet ni le contrôle libre des propriétés de textèmes, alors qu’un éditeur de bas niveau — dont la raison d’être
est justement de permettre un accès non restreint au texte — ne sera probablement pas d’une utilisation facile, notamment à cause de la dissonance
cognitive ci-haut mentionnée entre propriétés effectives et image perçue. Il
n’est donc plus possible de parler d’« éditeur de texte brut » dans le contexte
d’un modèle de texte en textèmes, du moins pas dans le sens classique du
terme.
223
Il n’existe pas
de recettes générales
car l’IHM est également
fonction de l’usage
En revanche, l’usage
est également fonction
du modèle
Étude de cas :
éditeurs de texte brut
4.3.2 M ODÈLES DE
TEXTE INTENSIONNELS
SANS TEXTÈMES
Recherche d’une
Un direction potentielle pour la recherche de modèles de texte intensionsolution généralisée nels est celle qui mène vers des modèles sans éléments atomiques, sans texau problème tèmes. La motivation pour étudier des modèles autres que ceux déjà examinés
du changement d’unité dans cette thèse, outre un intérêt théorique, peut être la volonté de trouver
textuelle pertinente
Avantages
et inconvénients
d’un modèle de texte
sans atomes
une solution plus efficace et plus naturelle aux problèmes de « granularité »
qui peuvent exister entre propriétés. Nous avons observé — notamment dans
la section 2.5 — que certaines propriétés s’attachent non pas à un seul textème
mais à une suite de textèmes ; nous avons appelé ce type de propriété contextuelle. Dans d’autres cas, ce genre de correspondance multiple-à-un opère
dans la direction inverse : plusieurs unités textuelles devraient se retrouver au
sein du même textème, chacun ayant ses propres propriétés (cf. fig. 2.6 sur
la page 118). Le problème semble être la rigidité du textème même, de cette
« boîte à propriétés » qui n’est donc pas capable de s’adapter facilement à des
usages textuels simultanés qui segmentent le texte de manières différentes.
Il est bien possible de créer des modèles qui ne considèrent pas le texte
comme une « succession de boîtes ». L’avantage d’un tel modèle serait d’une
part, de résoudre le problème de différence de granularité entre unités textuelles pertinentes de différents usages, et d’autre part, de ne plus distinguer
entre propriétés « dans et en dehors de la boîte » (propriétés de textème et propriétés contextuelles). Le revers de la médaille est que l’abandon de l’approche
intuitive qui regarde le texte comme une succession de signes mène vers des
modèles extrêmement abstraits dont l’utilité pratique peut être questionnable.
Pour des raisons de cohérence et aussi pour ne pas allonger davantage
la taille du présent texte, l’auteur préfère présenter ses recherches quant aux
modèles de texte alternatifs dans un travail séparé.
224
BIBLIOGRAPHIE
[1] « Acharya, website dedicated to multilingual computing in Indian languages ».
http://acharya.iitm.ac.in/.
[2] ADOBE L ABS. « Le projet Mars », 2007.
http://labs.adobe.com/wiki/index.php/Mars.
[3] ADOBE SYSTEMS. PostScript Language Reference, 3rd Ed. Addison Wesley, 1999. ISBN 0 201 37922 8.
[4] ADOBE SYSTEMS. « Adobe Glyph List (Liste de glyphes d’Adobe) », 2002.
http://partners.adobe.com/public/developer/en/opentype/
glyphlist.txt.
[5] ADOBE SYSTEMS. « Adobe Glyph Naming Convention (Convention de
nommage de glyphes d’Adobe) », 2003.
http://partners.adobe.com/public/developer/opentype/
index_glyph.html.
[6] ADOBE SYSTEMS. « PDF Reference, Sixth Edition, version 1.7 », 2007.
http://www.adobe.com/devnet/acrobat/pdfs/pdf_reference.pdf.
[7] Patrick ANDRIES. « Unicode et les polices : deux mondes ». Dans Actes
de l’atelier « La typographie entre les domaines de l’art et de l’informatique », Publications de l’Institut Royal de la Culture Amazighe, Rabat,
2007.
http://hapax.qc.ca/pdf/deux-mondes.pdf.
[8] Jacques ANDRÉ. Création de fontes en typographie numérique. Habilitation à diriger des recherches, 1993.
http://hal.inria.fr/view_by_stamp.php?label=INRIA
&action_todo=view&langue=fr&id=tel-00011218&version=1#.
[9] Jacques ANDRÉ. « ISO Latin-1, norme de codage des caractères européens ? trois caractères français en sont absents ! ». Dans Cahiers GUTenberg, volume 25, 1996.
http://www.gutenberg.eu.org/pub/GUTenberg/publicationsPDF/
25-andre.pdf.
[10] Jacques ANDRÉ et Henri HUDRISIER , éditeurs. Document numérique,
volume 6 (Unicode, écriture du monde). 3-4/2002.
[11] APPLE COMPUTER. « How GX Does Justification ».
http://developer.apple.com/textfonts/WhitePapers/
GXJustification.html.
[12] APPLE COMPUTER. « TrueType Reference Manual, AAT Tables ».
http://developer.apple.com/textfonts/TTRefMan/.
[13] Gábor BELLA. « An Automatic Diacritic Positioning System for Arabic and
Hebrew Scripts ». Master’s thesis, ENST Bretagne, 2003.
225
[14] Gábor BELLA et Yannis HARALAMBOUS. « Fontes intelligentes, textèmes
et typographie dynamique ». Document numérique, vol. 9 (Fontes numériques), 2007.
[15] Massimo BENERECETTI, Paolo BOUQUET, et Chiara GHIDINI. « Contextual
reasoning distilled ». JETAI, 12(3):279–305, 2000.
http://citeseer.ist.psu.edu/benerecetti00contextual.html.
[16] Tom BISHOP et Richard COOK. « A Specification for CDL Character Description Language », 2003. Rapport technique, Wenlin.
http://www.wenlin.com/cdl/cdl_spec_2003_10_31.pdf.
[17] Gérard BLANCHARD. « Pour une Sémiologie de la Typographie ». PhD
thesis, École des Hautes Études en Sciences Sociales, 1980.
[18] R.J. BRACHMAN. « What IS-A Is and Isn’t: An Analysis of Taxonomic Links
in Semantic Networks ». Computer, 16(10):30–36, 1983. ISSN 00189162.
http://ieeexplore.ieee.org/iel5/2/34675/01654194.pdf
?tp=&isnumber=&arnumber=1654194.
[19] Peter T. DANIELS et William BRIGHT, éditeurs. The World’s Writing Systems. Oxford University Press, 1996. ISBN 0-19-507993-0.
[20] John DEFRANCIS. Visible Speech: The Diverse Oneness of Writing Systems. University of Hawai‘i Press, 1989.
[21] Patrick DEHORNOY. Mathématiques de l’informatique. Dunod, 2000.
ISBN 2 10 004446 X.
[22] Jon FERRAIOLO, Jun FUJISAWA, et Dean Jackson (EDS.). « Scalable Vector
Graphics (SVG) 1.1 Specification », 2007. Recommandation W3C.
http://www.w3.org/TR/SVG11/.
[23] FOURNIER,
1764.
LE JEUNE.
Manuel typographique, tome I. Paris, Fournier,
[24] Gottlob FREGE. Écrits logiques et philosophiques. Seuil, 1971. ISBN
2-02-002742-9.
[25] Fausto GIUNCHIGLIA et Paolo BOUQUET. « Introduction to contextual
reasoning. An Artificial Intelligence perspective ». Dans Perspectives on
Cognitive Science, volume 3, pages 138–159, 1996.
http://www.nbu.bg/cogs/personal/kokinov/COG507/
INTRODUCTION%20TO%20CONTEXTUAL%20REASONING
%20AN%20ARTIFICIAL%20INTELLIG.pdf.
[26] William C. HANNAS. Asia’s Orthographic Dilemma. University of Hawai‘i Press, 1997. ISBN 0 8248 1892 X.
[27] Tereza HARALAMBOUS et Yannis HARALAMBOUS . « Characters, Glyphs
and Beyond ». Dans Actes du Glyph and Typesetting Workshop, Kyoto,
Japon, 2003.
http://omega.enstb.org/yannis/pdf/kyoto2003-1.pdf.
[28] Yannis HARALAMBOUS. Fontes et codages. O’Reilly France, 2004. ISBN
2-84177-273-X.
226
[29] Yannis HARALAMBOUS. « Voyage au centre de TEX: composition, paragraphage, césure ». Cahiers GUTenberg, 44-45, 2004.
http://omega.enstb.org/yannis/pdf/voyage.pdf.
[30] Yannis HARALAMBOUS . « Infrastructure for Typesetting High-Quality Arabic ». Dans TUGboat, 27(2), 2006.
Actes de la conférence TUG 2006, Marrakech, Maroc.
[31] Yannis HARALAMBOUS . « Unicode et typographie : un amour impossible ». Dans Document Numérique, volume 6 (« Unicode, écriture du
monde »), 3-4/2002.
[32] Yannis HARALAMBOUS et Gábor BELLA. « Injecting Information into Atomic Units of Text ». Dans ACM Symposium on Document Engineering,
2005.
http://omega.enstb.org/yannis/pdf/p10174-haralambous.pdf.
[33] Yannis HARALAMBOUS et Gábor BELLA. « Omega Becomes a Sign Processor ». Dans Actes de la conférence EuroTEX 2005, Pont-à-Mousson,
France, 2005. (Version mise à jour : Omega Becomes a Texteme Processor.).
http://omega.enstb.org/yannis/pdf/eurotex05.pdf.
[34] Yannis HARALAMBOUS et Gábor BELLA. « Open-Belly Surgery upon Ω2 ».
Dans TUGboat 26(1), 2006. Actes de la conférence EuroTEX 2006, Debrecen, Hongrie.
[35] M. HOSKEN, B. HALLISSY, W. CLEVELAND, S. CORRELL, et A. WARD.
« Graphite Description Language, version 2.001 », 2000.
http://scripts.sil.org.
[36] « ISO/IEC
10036,
Information
technology—Font
information
interchange—Procedures for registration of font-related identifiers »,
1993.
http://10036ra.org.
[37] « ISO/IEC Technical Report 15285, Information technology: An operational model for characters and glyphs », 1998.
http://standards.iso.org/ittf/PubliclyAvailableStandards/
index.html.
[38] Mohamed JAMAL, Eddine BENATIA, Mohamed ELYAAKOUBI, et Azzedine
L AZREK. « Arabic Text Justification ». Dans TUGboat 27(2), 2006. Actes
de la conférence TUG 2006, Marrakech, Maroc.
[39] Ioannis KANELLOS. « Contributions à la représentation des concepts : fondements logiques et modélisation des processus de catégorisation cognitive. ». PhD thesis, École des Hautes Études en Sciences Sociales, 1990.
[40] KEN-ICHI HANDA, Nishikimi MIKIKO, Takahashi NAOTO, et Tomura SATORU. « The m17n Library—A General Purpose Multilingual Library for
Unix/Linux Applications ». Dans Asian Symposium on Natural Language
Processing to Overcome Language Barriers, 2004.
http://www.m17n.org/common/import/hainanm17n.pdf.
[41] Donald E. KNUTH. The TEXbook. Addison-Wesley, 1984. ISBN 0-20113448-9.
227
[42] Donald E. KNUTH. Digital Typography. Center for the Study of Language
and Information—Lecture Notes, 1999.
[43] Donald E. KNUTH et Michael F. PLASS. « Breaking Paragraphs into Lines ».
Dans Software—Practice and Experience, volume 11, 1981.
[44] Azzedine L AZREK. « CurExt, Typesetting Variable-sized Curved Symbols ». Dans TUGboat 24(3), 2003. Actes de la conférence EuroTEX 2003,
Brest, France.
http://www.ucam.ac.ma/fssm/rydarab/doc/communic/curext.pdf.
[45] Raph LEVIEN. « SVG Fonts. Is the SVG working group about to choose
shame and get war? », 1999.
http://www.levien.com/svg/shame.html.
[46] John MCCARTHY. « Notes on Formalizing Context ». Dans Actes du
13th International Joint Conference on Artificial Intelligence, Chambéry,
France, pages 555–560, 1993.
http://www.nbu.bg/cogs/personal/kokinov/COG507/
Formalizing%20context.pdf.
[47] Marshall MCLUHAN. The Gutenberg Galaxy. University of Toronto Press,
1962. ISBN 0-8020-6041-2.
[48] MICROSOFT CORP. « Word 2007 Rich Text Format (RTF) Specification,
version 1.9 », 2007.
http://www.microsoft.com/downloads/details.aspx?FamilyId=
DD422B8D-FF06-4207-B476-6B5396A18A2B&displaylang=en.
[49] Frank MITTELBACH et Chris ROWLEY. « Application-independent representation of text for document processing—will Unicode suffice? ». 1996.
http://omega.enstb.org/yannis/pdf/docnum.pdf.
[50] G.L. MURPHY et D.L. MEDIN. « The Role of Theories in Conceptual Coherence ». Psychological Review, 92(3):289–316, 1985.
[51]
Le Dictionnaire de l’Académie française, 1re édition. Paris, Coignard, 1694. Source : version numérisée par le projet ARTFL.
http://portail.atilf.fr/dictionnaires/ACADEMIE/PREMIERE/
premiere.fr.html.
[52]
Le Dictionnaire de l’Académie française, 8e édition. Paris, Hachette, 1932-1935. Source : version numérisée par ATILF-CNRS.
http://atilf.atilf.fr/academie.htm.
N.D..
N.D..
[53] OWL. « OWL Web Ontology Language Reference, W3C Recommendation », 10 février 2004.
http://www.w3.org/TR/owl-ref/.
[54] John PLAICE, Yannis HARALAMBOUS, et Chris ROWLEY. « An extensible approach to high-quality multilingual typesetting ». Dans IEEE Research Issues in Data Engineering: Multi-lingual Information Management, RIDE-MLIM 2003, Hyderabad (Inde), 2003.
http://omega.enstb.org/yannis/01249847.pdf.
[55] John PLAICE et Chris ROWLEY. « Characters are not simply names, nor documents trees ». Dans Actes du Glyph and Typesetting Workshop, Kyoto,
Japon, 2003.
228
http://coe21.zinbun.kyoto-u.ac.jp/papers/
ws-type-2003/009-plaice.pdf.
[56] RDF. « RDF Primer, W3C Recommendation », 10 février 2004.
http://www.w3.org/TR/REC-rdf-syntax/.
[57] Chris ROWLEY et John PLAICE. « New directions in document formatting:
What is text? ». Dans Actes du Glyph and Typesetting Workshop, Kyoto,
Japon, 2003.
http://coe21.zinbun.kyoto-u.ac.jp/papers/
ws-type-2003/001-rowley.ps.
[58] Richard SPROAT. A Computational Theory of Writing Systems. Cambridge University Press, 2000.
[59] Johny SROUJI et Daniel M. BERRY.
« Arabic Formatting with DITROFF/FFORTID ». Electronic Publishing, 5(4):163–208, 1992.
http://citeseer.ist.psu.edu/article/srouji92arabic.html.
[60] Toshiya SUZUKI, Masatake YAMATO, et Yoshiki MIKAMI. « Encodings in
Legacy Khmer TrueType Fonts ». Document numérique, vol. 9 (Fontes
numériques), 2007.
[61] Edward H. TRAGER. « The Penguin and Unicode: The State of Unicode
and Internationalization in Linux », 2005. Présentation à la 27e Conférence Unicode.
[62] « Le standard Unicode, Introduction ». Traduction française par P. Andries.
http://hapax.qc.ca.
[63] « The Unicode Standard, version 5.0 ».
http://www.unicode.org.
[64] « Unicode Technical Report #17 : Character Encoding Model ».
http://unicode.org/reports/tr17/.
[65] Ludmilla G. VÉDÉNINA. Pertinence linguistique de la présentation typographique. Peeters-Selaf, Paris, 1989. ISBN 2-87723-020-1.
[66] Kaiyu WAN, Vasu ALAGAR, et Joey PAQUET. « A Context Theory for Intensional Programming ». Dans Proceedings of the CRR’05 Workshop on
Context Representation and Reasoning, Paris, France, 2005.
http://sra.itc.it/events/crr05/wan.pdf.
[67] Adolf WILD. « La typographie de la Bible de Gutenberg ». Dans Cahiers
GUTenberg, volume 22 (« numéro spécial : ligatures & caractères contextuels »), 1995.
[68] Christian WITTERN. « Embedding Glyph Identifiers in XML Documents ».
Dans Journal of the Japan Association for East Asian Text Processing,
volume 4, 1995.
http://www.jaet.gr.jp/jj/egix.pdf.
[69] Candy YIU et Wai WONG. « Chinese Character Synthesis using METAPOST ». TUGboat, 24(2), 2003.
[70] Y.T.YEOW et T.G.TANG. « Radical-Pattern-Based Chinese Character Synthesis ». Proceedings of the IEEE, 70, no 10, 1982.
229
[71] Victor-Hugo ZALDIVAR-CARRILLO. « Contributions à la formalisation de
la notion de contexte : le concept de « théorie » dans la représentation
des connaissances ». PhD thesis, Université de Montpellier II, 1995.
230
ANNEXE A
LISTE
DE PUBLICATIONS
Gábor BELLA et Yannis HARALAMBOUS . « Fontes intelligentes, textèmes et typographie dynamique ». Dans Document numérique, vol. 9 (Fontes numériques),
2007.
Yannis HARALAMBOUS , Gábor BELLA et Atif GULZAR. « Open-Belly Surgery
upon Ω2 ». TUGboat 26(1), 2006. Actes de la conférence EuroTEX 2006, Debrecen, Hongrie.
Yannis HARALAMBOUS et Gábor BELLA. « Injecting Information into Atomic
Units of Text ». ACM Symposium on Document Engineering, 2005.
http://omega.enstb.org/yannis/pdf/p10174-haralambous.pdf
Yannis HARALAMBOUS et Gábor BELLA. « Omega Becomes a Sign Processor ».
Actes de la conférence EuroTEX 2005, Pont-à-Mousson, France.
(Version mise à jour : Omega Becomes a Texteme Processor.)
http://omega.enstb.org/yannis/pdf/eurotex05.pdf
John PLAICE, Yannis HARALAMBOUS, Paul SWOBODA et Gábor BELLA.
« Moving Omega to an Object-Oriented Platform ». Actes de la conférence
EuroTEX 2004, Xanthi, Grèce. Springer Lecture Notes in Computer Science.
Yannis HARALAMBOUS, Gábor BELLA et Anish MEHTA. « Adapting Omega to
OpenType Fonts ». Actes de la conférence EuroTEX 2003, Brest, France.
http://omega.enstb.org/yannis/pdf/
231