Unification des représentations XML et graphique

Dans notre poste de lecture active, décrit à la section 2.3, les aspects texte et image sont fortement couplés car ils sont intégrés dans une structure arborescente interne unique qui facilite l’implémentation d’interactions complexes entre ces deux types de ressources. Pour ce faire, l’architecture de notre système repose sur une nouvelle boîte à outils graphique, appelée Ubit (pour Ubiquitous Brick Interaction Toolkit) [Lecolinet99b, Lecolinet99c].

Le Toolkit Ubit

Le toolkit Ubit propose deux APIs C++ équivalentes et interchangeables. La première est une API objet classique qui ressemble un peu à celle du toolkit graphique Java AWT. La seconde API, également en C++, permet des descriptions déclaratives qui rappellent celles des langages de balisage tels que HTML et autres DTDs définies avec SGML ou XML.

Figure 2.18 : Combinaison de briques graphiques avec le toolkit Ubit.

L’architecture du toolkit Ubit est fondée sur la notion de briques logicielles génériques et modulaires, appelées briques de base, qu’il est possible de combiner librement afin d’obtenir une grande variété de composants graphiques spécialisés

(Figure 2.18). Une brique de base est un petit objet qui implémente et qui contrôle une fonctionnalité bien précise. Les briques Ubit ne se limitent pas aux composants graphiques visibles (les traditionnels widgets ou controls), mais permettent aussi de représenter n’importe quelle propriété matérielle (une décoration, du texte, une image, un symbole, etc.) ou immatérielle (une couleur, un type de police, un comportement, une condition, etc.).

Ce schéma de conception offre plusieurs avantages. L’utilisation des briques de base permet de créer des objets graphiques qui correspondent aux besoins du domaine d’application. En effet, la généricité et la simplicité de ces briques les rendent facile à dériver en une grande variété d’objets pouvant accomplir des tâches très spécifiques. Une brique peut, par exemple, implémenter un objet particulier tel qu’un élément ou un attribut XML. La simplicité de ces briques de base permet également de disposer simultanément d’un grand nombre d’objets graphiques en utilisant une quantité de mémoire raisonnable, ce qui rend possible le développement d’applications pleinement orientées objets sans pour autant sacrifier les performances. Par opposition, la plupart des toolkits graphiques fournissent des composants qui implémentent de nombreuses caractéristiques standard (même lorsqu’ils sont utilisés pour des tâches spécifiques) et, en conséquence ont tendance à utiliser de grandes quantités de mémoire. Ce schéma de conception impose de sérieuses limitations sur le nombre d’objets graphiques qui peut raisonnablement être utilisé. En conséquence, les logiciels efficaces tentent généralement de mixer différents styles de programmation et d‘introduire des astuces de codage qui accroissent leur complexité tout en limitant leurs capacités.

Outre ces divers aspects, le choix du toolkit Ubit s’explique surtout par le fait que le modèle structurel induit par la combinaison des briques de bases se rapproche fortement de celui des langages de balisages. Cette propriété offre la possibilité de représenter l’arbre qui décrit un document structuré au moyen d’un arbre de composants graphiques. Le toolkit Ubit semble donc fournir un cadre bien adapté au développement de logiciels de visualisation et d’édition de documents structurés. De plus, il dispose en standard de fonctionnalités comme le zoom et la transparence, et de composants comme les lentilles magiques, qui facilitent l’implémentation de techniques d’interactions avancées.

Mise en correspondance des éléments XML et des briques Ubit

Au niveau de notre application, nous tirons parti des spécificités du toolkit Ubit de la façon suivante. Au lieu de manipuler des représentations internes séparées de l’arbre XML et de l’arbre d’instanciation des objets graphiques (Figure 2.19), on les rassemble dans un graphe unique.

Figure 2.19 : Correspondance entre l’arbre XML et l’arbre Ubit.

Chaque nœ ud de l’arbre XML décrivant le document est représenté par une brique Ubit qui implémente les caractéristiques XML appropriées ainsi que leurs fonctions de rendu graphique. Cette représentation facilite la construction d’éditeurs interactifs puisque chaque objet (les balises) apparaissant effectivement à l’écran correspond à un objet réel et unique de la représentation interne. Ainsi, la représentation textuelle affichée à la Figure 2.20 (partie B) peut être vue comme une projection de l’arbre XML/Ubit qui est automatiquement gérée (et mise à jour à l’écran) par le toolkit. Ce schéma de conception possède également l’avantage de fournir directement la

correspondance inverse de la représentation visuelle vers les données internes. La

correspondance entre la position du curseur sur le texte et les nœ uds XML est connue en permanence de telle sorte qu’un déplacement de la souris sur l’écran est conceptuellement équivalent à un déplacement de pointeur dans l’arbre XML/Ubit. Cette caractéristique offre des possibilités étendues d’édition et diverses autres fonctionnalités intéressantes, puisque l’utilisateur peut directement interagir avec une représentation visuelle qui est virtuellement équivalente aux données internes.

Enfin, une autre caractéristique de notre implémentation consiste à ajouter aux briques XML/Ubit les données spatiales qui permettent de lier le contenu des images avec leurs parties textuelles (annotations et transcriptions), c’est-à-dire les informations de couplage texte/image. Les nœ uds XML/Ubit intègrent ainsi trois types de données dans une représentation unique :

? les caractéristiques des éléments XML, leurs attributs et leur contenu textuel,

? les caractéristiques graphiques du rendu approprié au texte structuré dans la transcription et la vue XML,

Figure 2.20 : Projection graphique de l’arbre XML/Ubit.

Fenêtre B : rendu visuel du code XML/TEI associé au fac-similé numérique affiché dans la fenêtre A.

Cette correspondance entre les nœ uds XML et leurs représentations graphiques (à la fois dans les images et dans les vues textuelles) pourrait surprendre à première vue puisque le codage XML tend à séparer la structure et la sémantique du texte du rendu graphique. Tout d’abord, il s’avère toutefois important de rappeler, qu’au niveau de notre application, cette correspondance existe uniquement dans la représentation interne des données, afin d’améliorer la gestion de ces données et de faciliter l’interaction utilisateur, mais n’a aucun impacte sur les représentations externes (fichiers XML/TEI). Ensuite, il est intéressant de noter que les caractéristiques graphiques standards pour le rendu du texte ne sont pas stockées dans les nœ uds XML/Ubit, mais dans des objets de style séparés. Ces styles, une autre caractéristique

B A

standard du toolkit, fournissent un moyen simple et efficace de paramétrer les briques Ubit. Ce sont des collections de spécifications graphiques qui s’appliquent par défaut en l’absence de spécifications explicites. L’utilisation de styles permet de partager l’essentiel des ressources graphiques (fontes, couleurs… ) entre les objets. Cette caractéristique facilite la translation entre les « mondes » XML/Ubit (document structuré / interface graphique) qui repose alors sur un double niveau de correspondance :

? la correspondance entre les balises (et attributs) XML et les briques Ubit pour le codage,

? la correspondance entre les feuilles de style XML et les objets de style Ubit pour le rendu.

Comme alternative à la méthode proposée, une autre solution consiste à avoir deux arbres en correspondance bi-univoque. Le premier décrit la structure du document XML et peut être construit au moyen d’une API standard (par exemple l’API XERCES du projet Apache [Apache01]). Le second est un arbre Ubit qui reproduit la structure XML au moyen des briques graphiques. Cette approche permet aux développeurs de mettre à profit toutes les opérations implémentées en standard dans l’API XML utilisée. Elle semble également faciliter la gestion de documents de grandes tailles.