FR2929778A1 - Procedes et dispositifs de codage et de decodage binaire iteratif pour documents de type xml. - Google Patents

Abstract

L'invention vise le codage/décodage binaire itératif pour un document comprenant des valeurs à coder ou à décoder. Pour le codage, après avoir créé (400) un dictionnaire à partir des valeurs à coder, des différences entre des éléments consécutifs du dictionnaire créé sont calculées (440). Ces étapes de création et de calcul sont répétées (460) en substituant les valeurs à coder par des différences entre les valeurs du dictionnaire créé précédemment. Les valeurs du document sont ensuite codées (480) à partir desdits dictionnaires créés. Pour le décodage, après avoir obtenu (610, 640) un ensemble de valeurs représentatives de différences entre des éléments d'un dictionnaire à partir de valeurs codées, des éléments du dictionnaire sont calculés (650) à partir desdites valeurs obtenues. Ces étapes sont répétées en substituant les valeurs représentatives de différences par les valeurs du dictionnaire calculées précédemment (630). Les valeurs sont alors décodées (670) à partir desdits dictionnaires calculés.

Description

La présente invention concerne l'optimisation des fichiers de type XML et plus particulièrement des procédés et des dispositifs de codage et de décodage binaire itératif pour documents de type XML, notamment de documents de type SVG. Le langage de balisage extensible XML (acronyme de Extensible Markup Language en terminologie anglo-saxonne) est une syntaxe pour définir des langages informatiques. Le langage XML permet ainsi de créer des langages adaptés à des utilisations différentes mais pouvant être traités par les mêmes outils. Un document XML est composé d'éléments, chaque élément commençant par une balise ouvrante comportant le nom de l'élément, par exemple <balise>, et se terminant par une balise fermante comportant elle aussi le nom de l'élément, par exemple </balise>. Chaque élément peut contenir d'autres éléments ou des données textuelles. Un élément peut être précisé par des attributs, chaque attribut étant défini par un nom et ayant une valeur. Les attributs sont placés dans la balise ouvrante de l'élément qu'ils précisent, par exemple <balise attribut="valeur">. La syntaxe XML permet aussi de définir des commentaires, par exemple <!-- Commentaire-->, et des instructions de traitement qui peuvent préciser à une application informatique quels traitements appliquer au document XML, par exemple <?montraitement?>. Les éléments, attributs, données textuelles, commentaires et instructions de traitement sont regroupés sous le nom générique de noeud. Plusieurs langages XML différents peuvent contenir des éléments de même nom. Pour utiliser plusieurs langages XML différents, un ajout a été effectué à la syntaxe XML permettant de définir des espaces de nommage, appelés namespace en terminologie anglo-saxonne. Deux éléments sont identiques seulement s'ils ont le même nom et se trouvent dans le même espace de nommage. Un espace de nommage est défini par une URI (sigle de Uniform Resource Identifier en terminologie anglo-saxonne), par exemple http://canon.crf.fr/xml/monlangage. L'utilisation d'un espace de nommage dans un document XML passe par la définition d'un préfixe qui est un raccourci vers l'URI de cet espace de nommage. Ce préfixe est défini à l'aide d'un attribut spécifique. A titre d'illustration, l'expression xmlns:ml="http://canon.crf.fr/xml/monlangage" associe le préfixe ml à l'URI http://canon.crf.fr/xml/monlangage. L'espace de nommage d'un élément ou d'un attribut est précisé en faisant précéder son nom par le préfixe associé à l'espace de nommage suivi de , par exemple <ml:balise ml :attribut="valeur">. XML présente de nombreux avantages et est devenu un standard pour stocker des données dans un fichier ou pour échanger des données. XML permet en particulier de disposer de nombreux outils pour traiter les fichiers générés. De plus, un document XML peut être édité manuellement avec un simple éditeur de texte. En outre, un document XML, contenant sa structure intégrée aux données, est très lisible même sans en connaître la spécification. Cependant, le principal inconvénient de la syntaxe XML est d'être très prolixe. Ainsi, la taille d'un document XML peut être plusieurs fois supérieure à la taille intrinsèque des données. Cette taille importante des documents XML induit aussi un temps de traitement important lors de la génération et surtout de la lecture de documents XML. Pour palier ces inconvénients, des mécanismes pour coder les documents XML ont été cherchés. Le but de ces mécanismes est de coder le contenu du document XML sous une forme plus efficace mais permettant de reconstruire facilement le document XML. Cependant, la plupart de ces mécanismes ne conservent pas l'ensemble des avantages du format XML. De nombreux nouveaux formats, permettant de stocker les données contenues dans un document XML, ont ainsi été proposés. Ces différents formats sont regroupés sous l'appellation XML Binaire . Parmi ces mécanismes, le plus simple consiste à coder les données de structure dans un format binaire au lieu d'utiliser un format textuel. En outre, la redondance des informations structurelles dans le format XML peut être supprimée ou au moins diminuée. Ainsi, par exemple, il n'est pas nécessairement utile de préciser le nom de l'élément dans la balise ouvrante et la balise fermante. Ce type de mécanisme est utilisé par tous les formats XML Binaire. Un autre mécanisme consiste à créer une ou plusieurs tables d'index qui sont utilisés, en particulier, pour remplacer les noms d'éléments et d'attributs généralement répétés dans un document XML. Ainsi, lors de la première occurrence d'un nom d'élément, celui-ci est codé normalement dans le fichier et un index lui est associé. Puis, pour les occurrences suivantes de ce nom d'élément, l'index sera utilisé à la place de la chaîne complète, réduisant la taille du document généré, mais facilitant aussi la lecture. En effet, il n'y a pas besoin de lire la chaîne complète dans le fichier et, en outre, la détermination de l'élément lu peut être réalisée par une simple comparaison d'entiers et non par une comparaison de chaînes de caractères. Ce type de mécanisme est mis en oeuvre dans plusieurs formats, notamment dans les formats conformes aux recommandations Fast Infoset et Efficient XML Interchange (EXI). Ce mécanisme peut être étendu aux valeurs textuelles et aux valeurs des attributs. De la même manière, lors de la première occurrence d'une valeur textuelle ou d'une valeur d'attribut, celle-ci est codée normalement dans le fichier et un index lui est associé. Les occurrences suivantes de cette valeur sont codées à l'aide de l'index. Ce type de mécanisme est mis en oeuvre dans plusieurs formats, notamment dans les formats conformes aux recommandations Fast Infoset et EXI.

Un autre mécanisme encore consiste à utiliser des tables d'index pour décrire la structure de certaines catégories de noeuds du document. Ainsi, par exemple, il est possible d'utiliser une table d'index pour chaque noeud élément ayant un nom donné. Lors de la première occurrence d'un noeud fils dans le contenu de ce noeud, une nouvelle entrée décrivant le type de ce noeud fils est ajoutée dans la table d'index. Lors des occurrences suivantes d'un noeud fils similaire, ce nouveau noeud fils est décrit en utilisant l'index associé.

Ce type de mécanisme est mis en oeuvre dans les formats conformes aux recommandations EXI. Le format de données SVG (sigle de Scalable Vector Graphics en terminologie anglo-saxonne) est un langage XML permettant de décrire des graphiques vectoriels. SVG utilise la syntaxe XML et définit un ensemble d'éléments et d'attributs permettant notamment de décrire des formes géométriques, des transformations, des couleurs et des animations. Un outil très utilisé dans SVG est le chemin graphique, appelé path en terminologie anglo-saxonne. Un chemin graphique est un ensemble de commandes et de coordonnées associées, permettant de décrire une forme graphique complexe à partir de segments, de courbes de Bézier et d'arcs de cercle. Les formats XML Binaire peuvent être utilisés pour coder des documents SVG. Cependant, la plupart de ces formats présentent des limitations par rapport au codage de documents SVG. En effet, dans de nombreux documents SVG, la part de la structure est peu importante par rapport à la part du contenu. Or, les formats XML Binaire visent principalement à compresser la structure des documents XML. Au niveau du contenu, les formats XML Binaire peuvent indexer les valeurs, afin de ne pas coder plusieurs fois une même valeur répétée de contenu. Ils peuvent aussi coder de manière spécifique certains contenus dont le type est connu et simple, par exemple un nombre entier ou un nombre réel. Mais les contenus SVG ne répondent à aucun de ces critères : les contenus SVG importants par leur taille sont rarement répétés et ne correspondent généralement pas à des types simples.

Ces contenus de taille importante sont par exemple les chemins graphiques, qui mélangent des commandes graphiques simples avec des coordonnées ou des listes de valeurs entières ou réelles. Pour cette raison, il est nécessaire de créer de nouveaux formats XML Binaire spécifiques aux documents SVG ou d'adapter des formats XML 30 Binaire existant pour coder efficacement les documents SVG. Le brevet US 6,624,769 décrit un format XML Binaire adapté à coder des documents SVG. Ce brevet décrit en particulier une manière spécifique pour coder les chemins SVG consistant à coder les commandes utilisées dans le chemin en n'attribuant un code qu'aux commandes présentes dans le chemin. En outre, ces codes sont des codes de type Huffman, dont l'attribution est prédéfinie pour l'ensemble des commandes existantes.

Les arguments des commandes sont codés de façon binaire, en utilisant un nombre de bits minimum permettant de coder tout argument présent dans le chemin. Plus précisément, le brevet se limite au codage d'arguments entiers, correspondant aux profils SVG pour les téléphones mobiles, et sépare les arguments en deux catégories : les arguments correspondant à des commandes absolues et ceux correspondant à des commandes relatives. Dans le cas d'une commande absolue, l'argument représente directement une position dans le repère SVG tandis que dans le cas d'une commande relative, l'argument représente le déplacement depuis la position précédente. Pour chaque type d'argument, le nombre minimum de bits permettant de coder tout argument de ce type présent dans le chemin est calculé. Ensuite, chaque argument est codé sur un nombre de bits dépendant de son type. Le format décrit dans ce brevet permet d'obtenir des documents SVG compacts, mais ne s'applique qu'à une catégorie restreinte de documents et a une efficacité qui reste limitée dans le cas de chemins importants.

Par ailleurs, un type de codage pouvant être utilisé pour coder une suite de nombres est le codage par dictionnaire selon lequel l'ensemble des valeurs prises par les différents nombres est d'abord codé. Cet ensemble de valeurs constitue un dictionnaire qui est utilisé pour coder les nombres. Ainsi, pour chaque nombre, l'index de ce nombre dans le dictionnaire est codé.

Un tel type de codage est généralement efficace pour les valeurs SVG. Un autre type de codage pouvant être utilisé pour coder une suite de nombres est le codage par delta selon lequel chaque nombre est codé non pas directement, mais relativement au précédent. Ainsi, pour chaque nombre, la différence de ce nombre et du précédent est codée. Ce système est efficace dans le cas de suite de nombres dont la variation est faible par rapport à la valeur du nombre.

Dans le cas de SVG, ce type de codage est partiellement intégré au langage de par l'existence des commandes relatives. Par ailleurs, les variations entre deux nombres successifs sont souvent du même ordre de grandeur que les nombres eux-mêmes. Enfin, dans le cas des chemins, deux nombres successifs représentent des valeurs correspondant à deux coordonnées différentes, donc relativement indépendantes. L'invention permet notamment d'augmenter l'efficacité de compression de suites de données, en particulier des suites de nombres, notamment de données de type SVG.

L'invention a ainsi pour objet un procédé de codage binaire itératif pour un document structuré comprenant au moins une pluralité de valeurs à coder, ce procédé comprenant les étapes suivantes, - création d'un dictionnaire à partir desdites valeurs à coder ; - calcul des différences entre au moins deux éléments consécutifs 15 dudit dictionnaire créé ; - répétition des étapes précédentes dans lesquelles les valeurs à coder sont des différences entre les valeurs du dictionnaire créé précédemment ; et, - codage de ladite pluralité de valeurs dudit document à partir 20 desdits dictionnaires créés. Le procédé selon l'invention permet ainsi d'améliorer le codage des documents structurés, par exemple de type XML, en particulier des documents de type XML comprenant une suite de nombres, pour optimiser la taille du document codé. 25 Selon un mode de réalisation particulier, le procédé comprend en outre une étape de tri des éléments d'au moins un dictionnaire créé, préalablement à ladite étape de calcul des différences, afin d'améliorer le codage. Toujours selon un mode de réalisation particulier, le procédé 30 comprend en outre une étape d'indexation des éléments d'au moins un dictionnaire créé, préalablement à l'étape de codage de ladite pluralité de valeurs, le codage d'au moins une valeur à coder comprenant une étape de substitution de ladite au moins une valeur à coder par un index. L'utilisation d'index se substituant à des valeurs permet d'optimiser le codage. De façon avantageuse, ladite étape de répétition est répétée un nombre prédéterminé de fois.

Selon un mode de réalisation particulier, le procédé comprend en outre une étape de normalisation d'au moins une valeur de ladite pluralité de valeurs. En particulier, si au moins certaines des valeurs de ladite pluralité de valeurs sont représentatives de coordonnées, ladite étape de normalisation peut comprendre une étape de conversion de coordonnées absolues en coordonnées relatives ou de conversion de coordonnées relatives en coordonnées absolues. Ainsi, selon la nature des valeurs à coder, il est possible de réduire la taille des valeurs à coder et, ainsi, d'améliorer le codage. De même, si au moins certaines des valeurs de ladite pluralité de valeurs sont représentatives de coordonnées, chaque composante de ladite pluralité de valeurs formant une pluralité de valeurs est, de préférence, codée de façon indépendante afin de prendre en compte la relation pouvant exister entre les valeurs à coder pour optimiser le codage. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de comparaison d'au moins deux desdites différences calculées entre au moins trois éléments d'un dictionnaire créé à au moins un seuil prédéterminé, lesdites au moins deux desdites différences étant considérées comme distinctes si leur différence est supérieure audit seuil prédéterminé. Ainsi, si une différence entre deux éléments d'un dictionnaire est considérée comme étant négligeable, les deux éléments peuvent être regroupés en un seul élément pour améliorer le codage. Ledit document peut notamment être un document de type XML ou de type SVG. Si ladite pluralité de valeurs à coder appartient à un chemin de type SVG, ledit procédé comprend en outre, avantageusement, une étape de séparation entre ladite pluralité de valeurs et au moins une commande pour optimiser le codage en prenant en compte le lien pouvant exister entre les valeurs à coder.

L'invention a également pour objet un procédé de décodage binaire itératif d'un document structuré comprenant une pluralité de valeurs codées, ce procédé comprenant les étapes suivantes, - obtention d'un ensemble de valeurs représentatives de différences entre une pluralité d'éléments d'un dictionnaire à partir de ladite pluralité de valeurs codées ; - calcul des éléments dudit dictionnaire à partir desdites valeurs obtenues ; - répétition des étapes précédentes dans lesquelles les valeurs représentatives de différences sont les valeurs du dictionnaire calculées précédemment ; et, - décodage d'au moins une valeur de ladite pluralité de valeurs codées à partir desdits dictionnaires calculés. Le procédé selon l'invention permet ainsi de décoder des documents 15 codés selon un codage optimisé. De façon avantageuse, ladite étape de répétition est répétée un nombre prédéterminé de fois. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de décodage d'index, ladite étape de décodage d'au moins une 20 valeur de ladite pluralité de valeurs codées comprenant une étape de substitution d'un index décodé par une valeur de l'un desdits dictionnaires afin de prendre en compte les étapes d'optimisation du codage. L'invention a aussi pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des 25 étapes du procédé décrit précédemment, ainsi que des moyens de stockage d'informations, amovibles ou non, partiellement ou totalement lisibles par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé décrit précédemment. 30 L'invention a également pour objet un dispositif de codage binaire itératif pour un document structuré comprenant au moins une pluralité de valeurs à coder, ce dispositif comprenant les moyens suivants, - moyens pour créer un dictionnaire à partir desdites valeurs à coder ; - moyens pour calculer des différences entre au moins deux éléments consécutifs dudit dictionnaire créé ; - moyens pour réutiliser lesdits moyens pour créer et lesdits moyens pour calculer en substituant lesdites valeurs à coder par des différences entre les valeurs du dictionnaire créé précédemment ; et, - moyens pour coder ladite pluralité de valeurs dudit document à partir desdits dictionnaires créés.

Le dispositif selon l'invention permet ainsi d'améliorer le codage des documents structurés, par exemple de type XML, en particulier des documents de type XML comprenant une suite de nombres, pour optimiser la taille du document codé. Selon un mode de réalisation particulier, le dispositif comprend en outre des moyens pour trier des éléments d'au moins un dictionnaire créé, préalablement audit calcul des différences, afin d'améliorer le codage. Toujours selon un mode de réalisation particulier, le dispositif comprend en outre des moyens pour indexer des éléments d'au moins un dictionnaire créé, préalablement audit codage de ladite pluralité de valeurs, lesdits moyens pour coder ladite pluralité de valeurs comprenant des moyens pour substituer au moins une desdites valeurs à coder par un index. L'utilisation d'index se substituant à des valeurs permet d'optimiser le codage. Toujours selon un mode de réalisation particulier, le dispositif comprend en outre des moyens pour normaliser au moins une valeur de ladite pluralité de valeurs. En particulier, si au moins certaines des valeurs de ladite pluralité de valeurs sont représentatives de coordonnées, lesdits moyens de normalisation peuvent comprendre des moyens pour convertir des coordonnées absolues en coordonnées relatives ou pour convertir des coordonnées relatives en coordonnées absolues. Ainsi, selon la nature des valeurs à coder, il est possible de réduire la taille des valeurs à coder et, ainsi, d'améliorer le codage. Toujours selon un mode de réalisation particulier, le dispositif comprend en outre des moyens pour comparer au moins deux desdites différences calculées entre au moins trois éléments d'un dictionnaire créé à au moins un seuil prédéterminé, lesdites au moins deux desdites différences étant considérées comme distinctes si leur différence est supérieure audit seuil prédéterminé. Ainsi, si une différence entre deux éléments d'un dictionnaire est considérée comme étant négligeable, les deux éléments peuvent être regroupés en un seul élément pour améliorer le codage. Si ladite pluralité de valeurs à coder appartient à un chemin de type SVG, ledit dispositif comprend en outre, de préférence, des moyens pour séparer ladite pluralité de valeurs d'au moins une commande pour optimiser le codage en prenant en compte le lien pouvant exister entre les valeurs à coder. L'invention a également pour objet un dispositif de décodage binaire itératif d'un document structuré comprenant une pluralité de valeurs codées, ce dispositif comprenant les moyens suivants, - moyens pour obtenir un ensemble de valeurs représentatives de 15 différences entre une pluralité d'éléments d'un dictionnaire à partir de ladite pluralité de valeurs codées ; - moyens pour calculer des éléments dudit dictionnaire à partir desdites valeurs obtenues ; - moyens pour réutiliser lesdits moyens pour obtenir un ensemble 20 de valeurs et pour calculer des éléments en substituant les valeurs représentatives de différences par les valeurs du dictionnaire calculées précédemment ; et, - moyens pour décoder au moins une valeur de ladite pluralité de valeurs codées à partir desdits dictionnaires calculés. 25 Le dispositif selon l'invention permet ainsi de décoder des documents codés selon un codage optimisé. Selon un mode de réalisation particulier, le dispositif comprend en outre des moyens pour décoder des index, lesdits moyens pour décoder au moins une valeur de ladite pluralité de valeurs codées comprenant des moyens 30 pour substituer un index décodé par une valeur de l'un desdits dictionnaires afin de prendre en compte les étapes d'optimisation du codage.

D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 montre un exemple de dispositif permettant d'implémenter au moins partiellement l'invention ; - la figure 2 illustre un objet géométrique défini par un fichier XML de type SVG ; - la figure 3 représente un exemple d'algorithme de codage d'un chemin SVG selon l'invention ; - la figure 4 représente un exemple d'algorithme de codage d'une liste de valeurs numériques à l'aide d'un dictionnaire différentiel ; - la figure 5 illustre un exemple d'algorithme de décodage permettant de décoder un chemin SVG codé à l'aide de l'algorithme décrit en référence à la figure 3 ; et, - la figure 6 représente un exemple d'algorithme de décodage d'une liste de valeur par dictionnaire différentiel. L'invention consiste notamment en une méthode de codage pour les chemins SVG, permettant une représentation compacte des valeurs utilisées dans ces documents. Cette méthode de codage consiste, en particulier, à coder les arguments des commandes d'un chemin SVG à l'aide d'un dictionnaire lui- même codé. Les valeurs du dictionnaire sont triées puis les différences entre les valeurs consécutives sont calculées. Les valeurs obtenues sont alors codées elles-mêmes à l'aide d'un second dictionnaire. Le codage des valeurs de ce second dictionnaire s'effectue également en triant ses valeurs, puis en calculant les différences entre les valeurs consécutives. Ces différences sont alors codées directement. La méthode de codage utilisée par l'invention est récursive : le codage par dictionnaire est appliqué plusieurs fois aux jeux de valeurs à coder, le premier jeu étant les paramètres du chemin SVG et le second étant les valeurs du dictionnaire. Cette application récursive du codage par dictionnaire permet d'obtenir un taux de compression important pour les chemins SVG.

Un dispositif adapté à mettre en oeuvre l'invention ou une partie de l'invention est illustré sur la figure 1. Le dispositif 100 est par exemple une station de travail, un micro-ordinateur, un assistant personnel ou un téléphone mobile.

Le dispositif 100 comporte ici un bus de communication 105 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 110 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 115 (ROM, acronyme de Read Only Memory 10 en terminologie anglo-saxonne) pouvant comporter les programmes "Prog", "Prog1" et "Prog2" ; - une mémoire vive ou mémoire cache 120 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au 15 cours de l'exécution des programmes précités ; et, - une interface de communication 150 adaptée à transmettre et à recevoir des données. Optionnellement, le dispositif 100 peut également disposer : - d'un écran 125 permettant de visualiser des données et/ou de 20 servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier et d'une souris 130 ou d'un autre dispositif de pointage, un écran tactile ou une télécommande ; - d'un disque dur 135 pouvant comporter les programmes "Prog", "Prog1" et "Prog2" précités et des données traitées ou à traiter selon 25 l'invention ; et, - d'un lecteur de cartes mémoires 140 adapté à recevoir une carte mémoire 145 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et 30 l'interopérabilité entre les différents éléments inclus dans le dispositif 100 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 100 directement ou par l'intermédiaire d'un autre élément du dispositif 100. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 135 ou en mémoire morte 115. Selon une variante, la carte mémoire 145 peut contenir des données ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 100, est stocké dans le disque dur 135. Selon une autre variante, le code exécutable des programmes 10 pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface 150, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 100 avant d'être exécutés. 15 L'unité centrale 110 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 135 ou dans la mémoire morte 115 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une 20 mémoire non volatile, par exemple le disque dur 135 ou la mémoire morte 115, sont transférés dans la mémoire vive 120 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. 25 Il convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC). L'exemple présenté en annexe illustre un exemple de contenu de 30 document SVG pouvant être traité par le procédé selon l'invention. Ce document SVG contient, outre l'en-tête SVG, un seul chemin décrit dans la balise path . II représente un flocon de Koch, à la première itération. Un aperçu graphique de ce document SVG est illustré sur la figure 2. Dans ce document, les lettres majuscules M, L et Z représentent des commandes de chemin SVG. M correspond à la commande moveto , c'est- à-dire aller au point dont les coordonnées suivent. L correspond à la commande lineto , c'est-à-dire relier le point précédent au point dont les coordonnées suivent. Z correspond à la commande closepath , c'est-à-dire relier le point précédent au premier point du chemin. Les commandes M et L prennent chacune deux arguments, correspondant aux coordonnées du point. Cependant, quand une commande est répétée, il n'est pas nécessaire de la repréciser. C'est pour cela que la lettre L n'apparaît qu'une seule fois dans le chemin, alors que ce chemin est constitué par plusieurs commandes lineto . Les commandes M, L et Z correspondent à des commandes dont les coordonnées sont données de manière absolue par rapport au référentiel utilisé. Il existe une autre version de ces commandes, représentées par les lettres minuscules m, I et z, qui prennent en paramètre des coordonnées relatives, exprimées par rapport aux coordonnées du point précédent. La figure 3 représente un exemple d'algorithme de codage d'un chemin SVG selon l'invention. Une première étape (étape 300) permet d'obtenir le chemin à coder. A titre d'illustration, il est ici considéré que le chemin à coder est celui indiqué précédemment, c'est-à-dire le chemin suivant, M100.00 180.00 L 76.91 140.00 30.72 140.00 53.81 100.00 30.72 60.00 76.91 60.00 100.00 20.00 123.09 60.00 169.28 60.00 146.19 100.00 169.28 140.00 123.09 140.00Z Dans une étape suivante (étape 310), le chemin est réécrit. Cette réécriture a pour objet de n'utiliser que des commandes relatives au sein du chemin. Néanmoins, comme il n'existe aucune référence pour les arguments de la première commande, celle-ci demeure une commande absolue. Cependant, elle peut être réécrite en commande relative car les recommandations SVG spécifient que si un chemin commence par une commande relative, celle-ci doit être traitée comme une commande absolue. L'intérêt de cette transformation est de rendre homogène l'ensemble des arguments utilisés dans le chemin. En outre, le choix de coordonnées relatives permet, dans de nombreuses situations, de réduire les valeurs (les coordonnées absolues peuvent avoir des valeurs importantes si le chemin est loin de l'origine tandis que les coordonnées relatives ont des valeurs faibles si les points formant le chemin restent proches). Enfin, le nombre de commandes pouvant être utilisées est diminué de moitié, ce qui permet d'utiliser un codage plus compact pour les commandes. En reprenant l'exemple précédent, le chemin réécrit peut s'écrire sous la forme suivante, m100. 180. 1-23.09 -40. -46.19 0. 23.09 -40. -23.09 -40. 46.19 0. 23.09 -40. 23.09 40. 46.19 0. -23.09 40. 23.09 40. -46.19 0.z Selon un premier mode de réalisation, cette réécriture peut être omise pour réduire la complexité du codage en supprimant une étape de calcul. D'autre part, dans certaines situations, il est possible de contrôler la source des documents SVG pour générer des chemins utilisant uniquement des commandes relatives. Dans ce cas, il est inutile de réécrire les chemins.

Selon un second mode de réalisation, la réécriture peut transformer toutes les commandes relatives en commandes absolues. En effet, dans certaines situations, il est plus efficace de n'utiliser que des commandes absolues. Le choix de la réécriture à réaliser peut soit être prédéterminé, soit être déterminé pour chaque chemin en fonction des caractéristiques du chemin ou de la taille obtenue pour le codage du chemin en fonction des choix effectués. Une étape suivante (étape 320) permet de séparer les commandes de leurs arguments pour les coder séparément, les commandes étant codées 30 avant les arguments. En reprenant l'exemple précédent, les commandes extraites sont les suivantes, m, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,z Cette liste de commandes peut également s'écrire sous la forme suivante où les commandes identiques consécutives sont référencées une seule fois avec le nombre d'occurrences, m,1*11,z Selon l'exemple donné, la liste des arguments est la suivante, 100., 180., -23.09, -40., -46.19, 0., 23.09, -40., -23.09, -40., 46.19, 0., 23.09, -40., 23.09, 40., 46.19, 0., -23.09, 40., 23.09, 40., -46.19, 0. Les commandes sont ensuite codées (étape 330).

Le codage utilisé consiste ici à attribuer à chaque commande un code sur 4 bits. Les valeurs de codage restantes (ici 6 valeurs puisque les recommandations SVG définissent 10 commandes relatives) sont utilisées pour coder des répétitions. Ainsi la liste des commandes de l'exemple précédent peut être codée par la séquence suivante d'octets, 05 02 FD 10 où le premier octet 05 correspond au nombre de codes utilisé et les trois octets suivants 02 FD 10 correspondent aux commandes contenues dans le chemin. Le code 0 (codé sur 4 bits ou un demi octet) correspond à la commande m , le code 2 à la commande I , le code F à 6 répétitions de la commande précédente (c'est-à-dire ici la commande I ), le code D à 4 répétitions de la commande précédente (c'est-à-dire toujours la commande I ) et le code 1 à la commande z . Le dernier code est complété par 4 bits à zéro pour terminer l'octet. D'autres types de codage peuvent être utilisés. En particulier, le code utilisé pour chaque commande peut être de longueur variable. II est ainsi possible d'utiliser un codage de type Huffman pour coder les différentes commandes. Cependant, cela implique de transmettre la description du codage utilisé. Une autre solution consiste à déterminer à l'avance un codage de type Huffman, pour les commandes, qui sera utilisé pour tous les chemins SVG (il convient de remarquer que les commandes I et c sont celles qui sont le plus souvent utilisées dans les chemins).

Une étape suivante (étape 340) a pour objet de coder les arguments des commandes du chemin. Cette étape est réalisée en utilisant un algorithme de codage par dictionnaire différentiel dont un exemple est décrit en référence à la figure 4.

La forme particulière de la représentation de l'étape 340 indique le caractère itératif de cette étape. La même représentation est utilisée pour les étapes 460, 520 et 630. Il doit être noté que la description de cet algorithme ne prend en compte que les arguments numériques des commandes de chemin SVG.

Cependant, quelques commandes de chemin SVG ont des arguments de type booléen. Ces arguments sont avantageusement séparés des autres arguments à l'étape de séparation des commandes et des arguments (étape 320) et sont codés après la liste des commandes, un bit étant utilisé pour coder chaque argument booléen.

Alternativement, ces arguments booléens peuvent aussi être codés après les autres arguments. Dans une autre alternative, ces arguments booléens peuvent être codés avec les index correspondant aux autres arguments pour conserver l'ordre des arguments.

D'autres types d'arguments, par exemple des chaînes de caractères, peuvent être codés de façon similaire. La figure 4 représente un exemple d'algorithme de codage d'une liste de valeurs numériques à l'aide d'un dictionnaire différentiel. Cet algorithme est appliqué de façon préférentielle aux arguments des chemins XPath mais il peut aussi être appliqué aux listes de valeurs contenues dans d'autres attributs SVG, par exemple les attributs Values ou KeyTimes, ou pour tout autre type de valeur dont le contenu est une liste de nombre. Une première étape (étape 400) a pour objet la création d'un premier dictionnaire, ce premier dictionnaire étant utilisé par la suite pour coder la liste de valeurs. Le premier dictionnaire contient chacune des valeurs contenues dans la liste, sans répétition.

Ainsi, en reprenant l'exemple précédent, le premier dictionnaire est constitué par les éléments suivants, 100., 180., -23.09, -40., -46.19, 0., 23.09, 40, 46.19 Les éléments du premier dictionnaire sont ensuite triés (étape 410), par exemple par ordre croissant. Le premier dictionnaire ainsi trié est mémorisé pour servir de référence pour un codage par index de la liste de valeurs. La détermination des index associés à chacun des éléments triés du premier dictionnaire peut être réalisée ici ou ultérieurement. Les étapes 400 et 410 peuvent être réalisées simultanément.

Dans l'exemple considéré, le premier dictionnaire trié est constitué par les éléments suivants, -46.19, -40., -23.09, 0., 23.09, 40., 46.19, 100., 180. Le codage de la taille du premier dictionnaire est ensuite réalisé (étape 420). Ce codage est effectué en codant directement l'entier représentant le nombre d'éléments présents dans le premier dictionnaire. Dans l'exemple considéré, le premier dictionnaire comporte neuf éléments, la taille codée est donc 09. Le premier élément du premier dictionnaire est ensuite codé (étape 430). Selon un mode de réalisation particulier, les valeurs numériques sont codées selon un format particulier. Un premier octet est utilisé pour coder un en-tête qui contient un premier bit indiquant si le nombre est positif ou non, puis 4 bits indiquant le nombre de décimales utilisées et enfin 3 bits indiquant le nombre d'octets utilisés pour coder le nombre (la partie entière et la partie décimale du nombre). Ensuite, un nombre variable d'octets est utilisé pour coder le nombre (la partie entière et la partie décimale sont codées sous forme d'une seule valeur entière). Selon ce codage, un nombre est codé sur 2 octets au minimum. Selon l'exemple considéré, le premier élément du premier dictionnaire est -46.19. Cet élément peut être codé de la façon suivante, 92 12 OB où le premier octet, utilisé comme en-tête, est 92, soit 10010010 en binaire. Le premier bit, dont la valeur est égale à 1 indique que le nombre est négatif. Les quatre bits suivants (0010), formant la valeur 2, indiquent que le nombre a deux décimales. Les trois derniers bits (010), formant la valeur 2, indiquent que le nombre entier représentant la partie entière et la partie décimale est codé sur deux octets.

Les deuxième et troisième octets (12 OB) forment la valeur 4619 qui correspond au nombre entier utilisé pour coder la partie entière et la partie décimale. II est à noter que tout autre type de codage de valeur numérique peut être utilisé.

Une étape suivante (étape 440) consiste à calculer les différences entre les éléments successifs du premier dictionnaire. Ces différences forment un premier tableau de différences associé au premier dictionnaire. A titre d'illustration, les différences entre les éléments successifs du premier dictionnaire selon l'exemple précédent sont les suivantes, 6.19, 16.91, 23.09, 23.09, 16.91, 6.19, 53.81, 80. Un test est ensuite effectué pour déterminer comment ce tableau de différences doit être codé (étape 450). Ce test consiste par exemple à vérifier si le codage des valeurs de ce tableau doit être réalisé de façon récursive. Ainsi, l'étape 450 peut appeler de nouveau l'algorithme pour coder une liste de valeurs obtenue au cours de l'exécution de cet algorithme. II convient de remarquer ici que l'utilisation de la récursivité dans un algorithme de compression ne permet généralement pas d'améliorer le taux de compression. Dans de nombreuses situations, l'application récursive d'un algorithme de compression conduit même à l'effet inverse tendant à diminuer le taux de compression. Cependant, dans le cas des chemins SVG et de certaines autres valeurs contenues dans les documents SVG, la structure des données est particulière et l'utilisation de la récursivité se révèle efficace. Selon un mode de réalisation préféré de l'invention, l'étape 450 consiste à décrémenter un compteur de récursivité, initialisé à une valeur positive prédéterminée, puis à comparer la valeur obtenue à zéro. Si ce compteur de récursivité atteint la valeur zéro l'algorithme se poursuit à l'étape 470 où le tableau de différences est codé directement. Au contraire, si ce compteur de récursivité est supérieur à zéro, l'algorithme se poursuit à l'étape 460 où le tableau de différences est codé par dictionnaire différentiel à l'aide de ce même algorithme. Toujours selon un mode de réalisation préféré, le compteur de récursivité prend la valeur deux pour valeur initiale. Par conséquent, la liste des arguments du chemin SVG ainsi que le premier tableau de différences sont codés à l'aide de l'algorithme décrit en référence à la figure 4. Si un dictionnaire ne comporte qu'un seul élément, le tableau de différences correspondant est vide et n'a pas besoin d'être codé.

Alternativement, le choix de la méthode de codage du tableau de différences peut se faire en fonction de la taille du tableau de différences. Si la taille de ce tableau est inférieure à une valeur prédéterminée, l'algorithme se poursuit à l'étape 470 sinon, l'algorithme se poursuit à l'étape 460. Dans une autre variante de réalisation, les deux codages sont testés pour le tableau et celui donnant le résultat le plus compact est retenu. Toujours selon une autre variante de réalisation, plusieurs des variantes de réalisation précédentes sont combinées. Il est à noter que si le mode de réalisation de l'étape 450 n'est pas déterministe, le résultat du test 450 doit être codé afin que, lors du décodage, la bonne méthode de décodage soit utilisée. Selon l'exemple illustré et en considérant le mode de réalisation préféré de l'invention, le compteur de récursivité est décrémenté et prend la valeur 1. L'algorithme se poursuit donc à l'étape 460. A l'étape 460, dans le cas d'un résultat positif au test 450, le tableau de différences est codé en utilisant de manière récursive ce même algorithme. Ainsi, dans cet exemple, pour le premier tableau de différences, un second dictionnaire, appelé dictionnaire différentiel, est créé et trié, contenant alors les éléments suivants, 6.19, 16.91, 23.09, 53.81, 80.

Puis la taille de ce second dictionnaire, égale à 5, est codée (05). Le premier élément de ce second dictionnaire est ensuite codé selon le schéma décrit précédemment, • 2929778 21 120268 où 12 (soit 00010010 en binaire) indique que le nombre est positif (premier bit à 1), qu'il comprend deux décimales (quatre bits suivants à 0010) et que deux octets sont utilisés pour coder le nombre (trois bits suivants à 010). 5 Les deuxième et troisième octets (02 6B) forment la valeur 619 qui correspond au nombre entier utilisé pour coder la partie entière et la partie décimale du nombre. Le tableau de différences de ce second dictionnaire, appelé second tableau de différence, est ensuite calculé pour obtenir les valeurs suivantes, 10 10.72, 6.18, 30.72, 26.19 Pour le codage du second tableau de différences, le compteur de récursivité est décrémenté et prend la valeur 0. Le résultat du test 450 est donc négatif et l'algorithme se poursuit à l'étape 470. A l'étape 470, dans le cas d'un résultat négatif au test 450, le second 15 tableau de différences est codé sans appel récursif à cet algorithme. Selon le mode de réalisation préféré de l'invention, une table de codage est créée contenant chacune des valeurs présentes une seule fois dans le second tableau des différences. Cette table de codage est ensuite triée et l'ensemble des valeurs contenues dans celle-ci est codé directement. Les 20 valeurs contenues dans le second tableau de différences sont alors remplacées par les index déterminés par rapport à cette table de codage. Ainsi, dans l'exemple décrit, le second tableau de différences précédent est codé selon ce mode de réalisation préféré. La table de codage triée contient les éléments suivants, 25 6.18, 10.72, 26.19, 30.72 Ces valeurs sont codées directement, selon le même format que précédemment (selon lequel le premier octet correspond au format de codage des valeurs), précédées par leur nombre, de la façon suivante, 04 12 02 6A 12 04 30 12 0A 3B 12 OC 00 30 où 04 correspond au nombre d'élément du tableau, la première indication 12 précise le format de codage de la première valeur, 026A correspond à la valeur du premier élément, la seconde indication 12 précise le format de codage de la seconde valeur, 0430 correspond à la valeur du second élément et ainsi de suite pour tous les éléments de la table de codage. Un index est associé à chaque élément de la table de codage, selon l'ordre croissant. Ainsi, l'index 0 est associé à la valeur 6.18, l'index 1 à 10.72, l'index 2 à 26.19 et l'index 3 à 30.72. Ensuite les valeurs du second tableau de différences sont codées. Pour cela, chaque valeur est remplacée par l'index déterminé à l'aide de la table de codage. La liste des index des éléments du second tableau de différences est donc, pour le second dictionnaire, la suivante : 1,0,3,2 Comme le nombre de valeurs d'index à coder est de quatre, chaque index est de préférence codé sur 2 bits. La liste des index est donc codée par la valeur 4E. Dans une variante, lors de l'étape 470, le tableau de différences est 15 codé directement. Pour cela, chaque élément du tableau est codé comme un nombre. Dans tous les cas, après l'étape 460 ou après l'étape 470, l'algorithme se poursuit à l'étape 480 qui consiste à coder les éléments du premier tableau de différences à l'aide des index correspondant à chacune des 20 valeurs, triées, du second dictionnaire. Chaque index est codé sur un nombre de bits minimal pour coder le nombre d'éléments contenus dans le dictionnaire trié. Ainsi, l'index 0 est associé à la valeur 6.19, l'index 1 à 16.91, l'index 2 à 23.09, l'index 3 à 53.81 et l'index 4 à 80. 25 Selon l'exemple décrit, la liste des index à coder pour le premier tableau de différences, selon les index déterminés à partir des éléments triés du second dictionnaire est la suivante, 0, 1, 2, 2, 1, 0, 3, 4 Cinq valeurs étant possibles, ces index sont codés sur 3 bits chacun. 30 La concaténation des représentations binaires des valeurs 0, 1, 2, 2, 1, 0, 3 et 4 est égale à 000001010010001000011100 soit la valeur suivante, 05 22 1C L'appel récursif de l'algorithme de la figure 4 est alors terminé. Le traitement se poursuit donc à l'étape 480 pour le codage des index correspondant à la liste des arguments. Des index sont associés aux éléments triés du premier dictionnaire.

Comme indiqué précédemment, cette association peut être réalisée lors du codage des index ou lors de la détermination des éléments du premier dictionnaire. Selon l'exemple décrit, l'index 0 correspond à la valeur -46.19, l'index 1 à -40, l'index 2 à -23.09, l'index 3 à 0, l'index 4 à 23.09, l'index 5 à 40, l'index 6 à 46.19, l'index 7 à 100 et l'index 8 à 180.

Chaque argument des commandes du chemin est ensuite remplacé par l'index correspondant déterminé à partir des index associés aux éléments triés du premier dictionnaire. La liste des arguments des commandes du chemin est alors la suivante, 7,8,2, 1,0,3,4, 1,2, 1,6,3,4, 1,4,5,6,3,2,5,4,5,0,3 Neuf valeurs d'index étant possible, ces index sont codés sur quatre bits chacun. La liste précédente d'index peut alors s'écrire sous la forme suivante, 78 21 03 41 21 63 41 45 63 25 45 03 Il est à noter que l'ordre de codage utilisé par l'algorithme a pour conséquence que les différentes listes d'index se suivent. Ceci permet d'utiliser les bits non utilisés à la fin du code d'une liste d'index pour commencer le codage de la liste d'index suivante. L'algorithme se termine après l'étape 480. Le codage du chemin SVG est alors obtenu par la concaténation du codage des commandes et du codage des arguments, le codage des arguments correspondant lui-même à la concaténation du codage du nombre d'éléments du premier dictionnaire, du codage du premier élément du premier dictionnaire, du codage de la taille du second dictionnaire, du codage du premier élément du second dictionnaire, du codage des valeurs du second dictionnaire, du codage de la liste des index associés au second dictionnaire, du codage de la liste des index associés au premier dictionnaire et du codage de la liste des index des arguments des commandes du chemin.

Comme indiqué précédemment, il est possible d'utiliser plus que deux dictionnaires. Néanmoins, le schéma de codage d'un chemin SVG reste similaire, selon un mécanisme d'encapsulation lié au caractère itératif de l'algorithme.

Dans l'exemple décrit, le chemin contenu dans le document SVG est constitué par 162 caractères. Une représentation standard de ce chemin nécessitera donc 162 octets. Ce même chemin est codé par le procédé selon l'invention avec la liste d'octets suivante, 05 02 FD 10 09 92 12 OB 05 12 02 6B 04 12 02 6A 12 04 30 12 OA 3B 12 OC 00 4E 05 22 1C 78 21 03 41 21 63 41 45 63 25 45 03 constituée de 41 octets. Par comparaison, une simplification de l'écriture du chemin initial, en enlevant les décimales nulles, permet de réduire la taille du chemin à 119 octets. L'application sur ce chemin simplifié de techniques de compression classiques permet de réduire sa taille à environ 100 octets. Toujours par comparaison, une adaptation de l'algorithme proposé dans le brevet US 6,624,769 nécessite au minimum 45 octets auxquels il faut ajouter la taille du codage des commandes, et la taille du codage des en-têtes.

Dans une variante, les index ne sont pas codés directement mais à l'aide d'un code de type Huffman. Pour cela, à chaque valeur d'index est attribué un code dont la taille dépend de sa fréquence d'utilisation (les codes les plus courts étant attribués aux valeurs les plus fréquentes). Puis, lors du codage des index, chaque index est remplacé par son code associé.

Cependant, il est nécessaire de transmettre une information permettant au décodeur de reconstituer les codes associés à chaque index. Pour cela, la liste des index par ordre de fréquence est codée, de préférence avant le codage de la liste des valeurs. Dans une autre variante, afin de diminuer la taille des informations supplémentaires devant être transmise, des valeurs d'index parmi les plus fréquentes sont sélectionnées, le nombre de ces valeurs étant prédéterminé. Ces valeurs d'index sélectionnées se voient attribuer des codes courts, tandis que les valeurs d'index non sélectionnées se voient attribuer des codes longs de taille identique. Ainsi, l'information supplémentaire à transmettre se réduit aux valeurs d'index sélectionnées. De préférence, le nombre prédéterminé est fonction du nombre de valeurs d'index. De préférence, les codes courts ont des longueurs différentes, les codes les plus courts étant associés aux valeurs les plus fréquentes. La figure 5 illustre un exemple d'algorithme de décodage permettant de décoder un chemin SVG codé à l'aide de l'algorithme décrit en référence à la figure 3.

Après avoir obtenu le chemin SVG, sous sa forme codée, au cours d'une première étape (étape 500), la liste des commandes composant le chemin SVG est décodée (étape 510). Chacune des commandes est ici décodée après avoir décodé le nombre de commandes. Les arguments correspondant à cette liste de commandes sont ensuite décodés (étape 520) en utilisant le décodage différentiel décrit en référence à la figure 6. Le nombre d'arguments à décoder est calculé à partir de la liste des commandes décodées. Le chemin SVG est ensuite reconstitué (étape 530). Pour cela, l'algorithme écrit successivement chacune des commandes décodées avec ses arguments respectifs. Il convient de noter que si une étape de réécriture du chemin SVG a été réalisée lors du codage, l'étape inverse n'est pas réalisée lors du décodage. Par conséquent, le document SVG décodé n'est pas identique, au niveau syntaxique, au document SVG codé. Cependant, la réécriture ne modifiant pas la sémantique du document, c'est-à-dire le graphique décrit par le document SVG, le document SVG décodé permet de générer le même graphique que le document SVG initial. A nouveau, comme en ce qui concerne la figure 3, le décodage des arguments booléens n'est pas décrit ici mais se déduit immédiatement de la description du codage utilisé.

La figure 6 représente un exemple d'algorithme de décodage d'une liste de valeurs par dictionnaire différentiel. Cet algorithme utilise, en paramètre, le nombre de valeurs à décoder. Une première étape (étape 600) a pour objet le décodage du nombre d'éléments contenus dans le premier dictionnaire, c'est-à-dire la taille du premier dictionnaire. Le premier élément du premier dictionnaire est ensuite décodé (étape 610). Un test est ensuite réalisé pour déterminer si l'algorithme de décodage doit se poursuivre de façon récursive ou non (étape 620). Ce test correspond au test effectué à l'étape 450 de la figure 4. II est réalisé de façon similaire. Si le résultat du test est positif, l'algorithme se poursuit à l'étape 630 sinon il se poursuit à l'étape 640. A l'étape 630, les différences entre les éléments successifs du dictionnaire sont décodées en réalisant un appel récursif à cet algorithme de décodage par dictionnaire différentiel. Le nombre de valeurs à décoder est celui décodé à l'étape 600. A l'étape 640, les différences entre les éléments successifs du dictionnaire sont décodées directement, en fonction du codage réalisé lors de l'étape 470 de la figure 4. Dans tous les cas, l'algorithme se poursuit à l'étape 650. Lors de cette étape, les éléments du dictionnaire sont calculés. Les différents éléments sont calculés de proche en proche, à partir du premier élément décodé à l'étape 610, en utilisant les différences décodées lors de l'une des étapes 630 et 640.

Les index des valeurs sont ensuite décodés (étape 660). Le nombre d'index à décoder est celui utilisé comme paramètre de l'algorithme. Le nombre de bits utilisé pour chaque index dépend, de préférence, du nombre d'éléments dans le dictionnaire. Ce nombre de bits est le nombre de bits minimal pour coder le nombre d'éléments contenus dans le dictionnaire. D'autres types de codage peuvent être utilisés, en relation avec la phase de codage.

La liste des valeurs est ensuite reconstruite (étape 670) : chaque index décodé à l'étape précédente est remplacé par sa valeur associée contenue dans le dictionnaire. Bien que le procédé selon l'invention ait été décrit pour le codage de chemin SVG, il peut être utilisé pour coder toute liste de valeurs numériques faisant partie d'un contenu textuel d'un document XML. Il peut s'agir d'un noeud texte ou de la valeur d'un attribut. En particulier, l'invention peut être appliquée à d'autres attributs SVG comme l'attribut values qui définit une liste de valeurs ou l'attribut keyTimes qui définit une liste d'instants temporels.

Selon ce mode de réalisation, l'algorithme de codage décrit en référence à la figure 3 est simplifié. L'étape 300 est remplacée par une étape d'obtention de la liste des valeurs à coder. Les étapes 310, 320 et 330 sont remplacées par une seule étape de codage du nombre de valeurs contenues dans la liste.

De même, l'algorithme de décodage décrit en référence à la figure 5 est simplifié. L'étape 510 est remplacée par une étape de décodage du nombre de valeurs contenues dans la liste. L'étape 530 est supprimée car aucun traitement supplémentaire n'est nécessaire pour reconstituer la liste des valeurs retournée par l'étape 520.

Le procédé selon l'invention peut également être appliqué à d'autres langages de description de graphiques en deux dimensions en XML, tels que Microsoft Silverlight (Silverlight est une marque) ou Adobe Mars, ou utilisant d'autres syntaxes, tels que Adobe Postscript (Postscript est une marque), Adobe PDF (PDF est une marque), ou Autodesk DXF (DXF est une marque). II peut aussi être appliqué à des langages de description d'interfaces graphiques, comme XAML (sigle d'eXtensible Application Markup Language en terminologie anglo-saxonne), XUL (sigle d'XML-based User interface Language en terminologie anglo-saxonne), UIML (sigle de User Interface Markup Language en terminologie anglo-saxonne), Adobe Flex (Flex est une marque) et OpenLaszlo. Il peut en outre être appliqué à des langages permettant des descriptions multimédias, en particulier pour coder des listes de valeurs temporelles. Ces langages comprennent SMIL (sigle de Synchronized Multimedia lntegration Language en terminologie anglo-saxonne). Enfin, il peut être appliqué à des langages de description de graphiques en trois dimensions, en particulier pour coder des listes de points en trois dimensions. Ces langages comprennent par exemple X3D (sigle d'Extensible 3D en terminologie anglo- saxonne). Une autre variante de mise en oeuvre consiste à coder de façon séparée les différentes valeurs numériques en fonction de leur catégorie. Ainsi, dans le cas des chemins, les arguments correspondant à des abscisses seront codés séparément des arguments correspondant à des ordonnées. Pour cela, lors de l'étape 320, les arguments sont séparés en différentes catégories. Puis, lors de l'étape 340, l'algorithme de codage par dictionnaire différentiel est utilisé pour la liste des arguments dans chaque catégorie. Lors du décodage, les différentes listes d'arguments sont décodées séparément, puis l'ensemble des arguments est reconstruit à partir de ces listes.

II est également possible de réaliser un codage avec pertes. En effet, dans certaines situations, des approximations peuvent conduire à obtenir dans le tableau de différences des valeurs très proches. Il est alors préférable de fusionner ces valeurs en une seule pour diminuer le coût de codage. Dans ce but, l'algorithme de codage décrit en référence à la figure 4 peut prendre en paramètre une valeur liée au niveau maximal d'erreur. Lors de l'étape 410, durant le tri du dictionnaire, si deux éléments du dictionnaire ont une différence inférieure à ce niveau maximal d'erreur alors ces deux éléments sont fusionnés. Ensuite, lors de l'étape 460 ou de l'étape 470 (dans le cas d'un codage à l'aide d'un dictionnaire), ce niveau maximal d'erreur est transmis. Mais comme les étapes 460 et 470 concernent le tableau de différences, une approximation sur une de ces différences peut être cumulée lors de la reconstitution des éléments du dictionnaire. Aussi, le niveau maximal d'erreur transmis n'est pas le niveau maximal d'erreur initial, mais ce niveau maximal d'erreur divisé par le nombre d'éléments contenus dans le dictionnaire.

Enfin, lors de l'étape 470, si un codage à l'aide d'un dictionnaire est utilisé, le niveau maximal d'erreur est pris en compte pour réduire le nombre d'éléments contenus dans le dictionnaire en fusionnant les éléments proches. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente. • 2929778 30 ANNEXE 5 <?xml version ="1.0" encoding= "UTF-8 "?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www. w3. org/Graphics/SVG/1.1/DTD/svg 11-basic. dtd"> <svg xmIns=httpi/www.w3.org/2000/svg viewBox="O 0 200 200" width="200" height="200"> <path stroke="black" fill="white" stroke-width="1 " d="M100.00 180.00 L76.91 140.00 30.72 140.00 53.81 100.00 30.72 60.00 76.91 60.00 100.00 20.00 123.09 60.00 169.28 60.00 146.19 100.00 169.28 140.00 123.09 15 140.00Z"/> </svg>

Claims (24)

1. REVENDICATIONS1. Procédé de codage binaire itératif pour un document structuré comprenant au moins une pluralité de valeurs à coder, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - création (400) d'un dictionnaire à partir desdites valeurs à coder ; - calcul (440) des différences entre au moins deux éléments consécutifs dudit dictionnaire créé ; - répétition (460) des étapes précédentes dans lesquelles les valeurs à coder sont des différences entre les valeurs du dictionnaire créé précédemment ; et, - codage (480) de ladite pluralité de valeurs dudit document à partir desdits dictionnaires créés.
2. 2. Procédé selon la revendication 1 comprenant en outre une étape de tri (410) des éléments d'au moins un dictionnaire créé, préalablement à ladite étape de calcul des différences.
3. 3. Procédé selon la revendication 1 ou la revendication 2 comprenant en outre une étape d'indexation des éléments d'au moins un dictionnaire créé, préalablement à l'étape de codage de ladite pluralité de valeurs, le codage d'au moins une valeur à coder comprenant une étape de substitution de ladite au moins une valeur à coder par un index.
4. 4. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite étape de répétition est répétée un nombre prédéterminé de fois.
5. 5. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de normalisation (310) d'au moins une valeur de ladite pluralité de valeurs.
6. 6. Procédé selon la revendication précédente selon lequel au moins certaines des valeurs de ladite pluralité de valeurs sont représentatives de coordonnées, ladite étape de normalisation comprenant une étape deconversion de coordonnées absolues en coordonnées relatives ou de conversion de coordonnées relatives en coordonnées absolues.
7. 7. Procédé selon l'une quelconque des revendications précédentes selon lequel au moins certaines des valeurs de ladite pluralité de valeurs sont représentatives de coordonnées, chaque composante de ladite pluralité de valeurs formant une pluralité de valeurs étant codée de façon indépendante.
8. 8. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de comparaison d'au moins deux desdites différences calculées entre au moins trois éléments d'un dictionnaire créé à au moins un seuil prédéterminé, lesdites au moins deux desdites différences étant considérées comme distinctes si leur différence est supérieure audit seuil prédéterminé.
9. 9. Procédé selon l'une quelconque des revendications précédentes selon lequel ledit document est un document de type XML ou de type SVG.
10. 10. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite pluralité de valeurs à coder appartient à un chemin de type SVG, ledit procédé comprenant en outre une étape de séparation entre ladite pluralité de valeurs et au moins une commande.
11. 11. Procédé de décodage binaire itératif d'un document structuré comprenant une pluralité de valeurs codées, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - obtention (610, 640) d'un ensemble de valeurs représentatives de différences entre une pluralité d'éléments d'un dictionnaire à partir de ladite pluralité de valeurs codées ; - calcul (650) des éléments dudit dictionnaire à partir desdites valeurs obtenues ; - répétition des étapes précédentes dans lesquelles les valeurs représentatives de différences sont les valeurs du dictionnaire calculées précédemment (630) ; et, - décodage (670) d'au moins une valeur de ladite pluralité de valeurs codées à partir desdits dictionnaires calculés.
12. 12. Procédé selon la revendication précédente selon lequel ladite étape de répétition est répétée un nombre prédéterminé de fois.
13. 13. Procédé selon la revendication 11 ou la revendication 12 comprenant en outre une étape de décodage d'index (660), ladite étape de décodage d'au moins une valeur de ladite pluralité de valeurs codées comprenant une étape de substitution d'un index décodé par une valeur de l'un desdits dictionnaires.
14. 14. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme d'ordinateur est exécuté sur un ordinateur.
15. 15. Moyens de stockage d'informations, amovibles ou non, partiellement ou totalement lisibles par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 13.
16. 16. Dispositif de codage binaire itératif pour un document structuré comprenant au moins une pluralité de valeurs à coder, ce dispositif étant caractérisé en ce qu'il comprend les moyens suivants, - moyens pour créer (400) un dictionnaire à partir desdites valeurs à coder ; - moyens pour calculer (440) des différences entre au moins deux éléments consécutifs dudit dictionnaire créé ; - moyens (460) pour réutiliser lesdits moyens pour créer et lesdits moyens pour calculer en substituant lesdites valeurs à coder par des différences entre les valeurs du dictionnaire créé précédemment ; et, - moyens (480) pour coder ladite pluralité de valeurs dudit document à partir desdits dictionnaires créés.
17. 17. Dispositif selon la revendication 16 comprenant en outre des moyens pour trier (410) des éléments d'au moins un dictionnaire créé, préalablement audit calcul des différences.
18. 18. Dispositif selon la revendication 16 ou la revendication 17 comprenant en outre des moyens pour indexer des éléments d'au moins un dictionnaire créé, préalablement audit codage de ladite pluralité de valeurs, lesdits moyens pour coder ladite pluralité de valeurs comprenant des moyens pour substituer au moins une desdites valeurs à coder par un index.
19. 19. Dispositif selon l'une quelconque des revendications 16 à 18 comprenant en outre des moyens pour normaliser (310) au moins une valeur de ladite pluralité de valeurs.
20. 20. Dispositif selon la revendication précédente selon lequel au moins certaines des valeurs de ladite pluralité de valeurs sont représentatives de coordonnées, lesdits moyens de normalisation comprenant des moyens pour convertir des coordonnées absolues en coordonnées relatives ou pour convertir des coordonnées relatives en coordonnées absolues.
21. 21. Dispositif selon l'une quelconque des revendications 16 à 20 comprenant en outre des moyens pour comparer au moins deux desdites différences calculées entre au moins trois éléments d'un dictionnaire créé à au moins un seuil prédéterminé, lesdites au moins deux desdites différences étant considérées comme distinctes si leur différence est supérieure audit seuil prédéterminé.
22. 22. Dispositif selon l'une quelconque des revendications 16 à 21 selon lequel ladite pluralité de valeurs à coder appartient à un chemin de type SVG, ledit dispositif comprenant en outre des moyens pour séparer ladite pluralité de valeurs d'au moins une commande.
23. 23. Dispositif de décodage binaire itératif d'un document structuré comprenant une pluralité de valeurs codées, ce dispositif étant caractérisé en ce qu'il comprend les moyens suivants, - moyens pour obtenir (610, 640) un ensemble de valeurs représentatives de différences entre une pluralité d'éléments d'un dictionnaire à partir de ladite pluralité de valeurs codées ; - moyens pour calculer (650) des éléments dudit dictionnaire à partir desdites valeurs obtenues ; moyens pour réutiliser lesdits moyens pour obtenir un ensemble de valeurs et pour calculer des éléments en substituant les valeurs représentatives de différences par les valeurs du dictionnaire calculées précédemment (630) ; et, - moyens pour décoder (670) au moins une valeur de ladite pluralité de valeurs codées à partir desdits dictionnaires calculés.
24. 24. Dispositif selon la revendication 23 comprenant en outre des moyens pour décoder des index (660), lesdits moyens pour décoder au moins une valeur de ladite pluralité de valeurs codées comprenant des moyens pour substituer un index décodé par une valeur de l'un desdits dictionnaires.