Karim Barkati
DEA ATIAM
Juin 2001

Rapport du stage de DEA :

Paramétrage automatique du rendu typographique en SVG des partitions MusicXML, par feuilles de style XSLT.

Directeur de stage : M. Emmanuel Saint-James
Laboratoire d'Informatique de Paris VI (LIP6)
Université Paris VI / Jussieu

Résumé

La visualisation de partitions musicales par les navigateurs standards du Web est contrecarrée par une triple absence:

un format d'entrée, connu de tout fonds documentaire;
un format de sortie, vectoriel donc peu volumineux;
un jeu de feuilles de styles paramétrant la mise en page de toute partition.

Le but de ce travail est de founir ces trois outils, en utilisant des normes reconnues internationalement.

Le premier doit reposer sur le méta-langage universel XML et décrire les aspects linguistiques non algébriques du langage musical écrit (en particulier les coulés entre portées). Depuis la rédaction du sujet de stage, est apparu sur le Web un tel format: MusicXML. Nous le décrivons en détail et mentionnons les difficultés rencontrées, notamment dans les carences des DTD face aux XML Schemas.

Pour le deuxième outil, le format de sortie, nous avons opté pour SVG, le langage de dessin vectoriel compatible avec XML. Il est recommandé par le W3C, et déjà doublement opérationnel: d'une part la bibliothèque Batik d'Apache en fait un langage utilisable dans un contexte de gratuité des logiciels, d'autre part Adobe propose déjà des plug-in pour Netscape & Explorer sous Windows & MacOS.

Le troisième outil, le jeu de feuilles de style, constitue l'essentiel de notre travail de développement logiciel. Il s'est agit pour nous d'une part de rédiger des feuilles de style au format XSL, et d'autre part de programmer en Java leur application sur des partitions au format MusicXML. Nous avons utilisé pour cela les bibliothèques Xalan et Xerces d'Apache.

Nous conclurons sur le travail à achever pour que toute institution possédant des partitions puissent les visualiser sur le Web avec une interface optimale et une faible bande passante.

Un glossaire des sigles et termes techniques figure à la fin du rapport.

Table des matières

Introduction

Chapitre 1: Description sémantique des partitions musicales
1. Les formats musicaux
2. Les tentatives de standardisation
3. Le format MusicXML

Chapitre 2: Dessin vectoriel de partitions sur le Web
1. Les polices musicales
2. La résolution graphique maximum
3. Le rendu en SVG

Chapitre 3: Feuilles de style musicales
1. Les feuilles de style
2. La séparation entre les données musicales et leur représentation graphique
3. L'automatisation du rendu typographique avec XSLT

Conclusion

Introduction

L'objectif originel de ce stage consistait à définir un format XML de description des partitions musicales adapté à leur circulation sur le réseau et à leur visualisation par un navigateur. Il est apparu pendant le stage, conformément à une situation de plus en plus fréquente sur le Web, que cet objectif a été en partie réalisé par d'autres que nous, aussi le stage a été réorienté interactivement plus en aval du but poursuivi. Les objectifs finaux conservent tout de même un format d'échange en XML, plus un moteur de conversion de XML vers SVG.

Il s'agit donc de développer ou d'utiliser une norme de description des partitions musicales, idéalement dans le but de la soumettre au Web Consortium. Une fois acceptée et integrée dans les navigateurs, elle permettrait d'insérer dans un document HTML une partition comme on insère une image. Cela pose des problèmes techniques et conceptuels, surtout si l'on souhaite diversifier les applications d'une telle structure de données, comme une impression à l'écran et sur papier de qualité maximum, l'extraction de connaissances, et un encombrement minimum pour diffusion sur le réseau et archivage local.

Il faut programmer un ensemble de DTD en XML pour décrire la structure logique d'une partition, et une application en Java pour analyser syntaxiquement ces partitions XML et générer de manière automatique un code en SVG (une norme graphique vectorielle pour le Web en passe d'être adoptée) pour les visualiser. Une partie de ce travail a déjà été effectuée, puisqu'il existe déjà des DTD pour les partitions (en particulier MusiXML de Gerd Castan), ainsi qu'un convertisseur de fichiers MusiXML vers SVG (musiquexml de François Chastanet), qui sont donc succeptibles d'être réutilisés.

Il s'agit ensuite de coder un ensemble de règles typographiques dans des feuilles de style (XSLT) permettant des "exceptions locales". Les exceptions, ou interventions locales du graveur, peuvent techniquement être codées dans les feuilles de style, puisqu'elles fonctionnent de manière contextuelle; par exemple, il est possible de rajouter une règle sur la 181ème mesure. Même si la raison de cette exception n'est pas modèlisée, il est nécessaire de pouvoir intervenir localement, avec une feuille de style de rang inférieur. On peut espérer à l'usage une convergence vers des feuilles plus universelles. De cette manière, le format original ne contient aucune information graphique.

En effet, cette recherche part du postulat suivant: les informations graphiques ne font pas partie de la musique elle-même. Il devrait donc être possible de développer un système de mise en page automatique et paramétrable, en reprenant le principe du convertisseur abc2ps. Ainsi, le graphique devient optionnel pour les applications qui n'en ont pas besoin, comme l'extraction de connaissances, et surtout le format commun permet l'échange entre les applications, car la sémantique est le dénominateur commun entre les applications, une intersection obligatoire entre les différents formats.

Les règles contenues dans les feuilles de style sont perfectibles en quantité et en qualité, pour typographier le fond de façon toujours plus esthétique. Il ne s'agit plus uniquement d'un format de sauvegarde, mais d'un format qui distingue l'intention du compositeur, les règles de gravure, et éventuellement les ajustements personnels, ce qui lui permet d'être exploitable dans plusieurs contextes.

Les formats commerciaux ne possèdent pas cette séparation logique, sans doute par obligation d'être présent sur le marché le plus tôt possible, mais cette absence de séparation du fond et de la forme est à l'origine de la multiplicité des formats. Essayer de structurer les données intelligemment nous rapproche d'un langage commun. SVG étant lui-même du XML, ce projet de stage entre donc dans une philosophie du "tout XML" et Java, comparse avec lequel XML partage ses ambitions multiplateformes.

Finalement, ce travail doit proposer un modèle stable reposant sur quatre éléments:

un premier fichier sémantique XML, décrivant les informations musicales uniquement, en vue de réduire les temps de téléchargement et l'encombrement en mémoire pour les applications d'extraction de connaissances;
un deuxième fichier syntaxique XSLT, décrivant les règles de mise en page à appliquer sur le premier, une de feuille de style susceptible de contenir des exceptions localisées pour les cas particuliers si fréquents en gravure; il pourrait contenir les polices ou leur nom;
un programme Java, produisant un fichier graphique SVG à partir des deux fichiers précédents, et éventuellement de la taille courante d'une "page" (A4, US, largeur de la fenêtre du navigateur, ...);
un fichier graphique de sortie SVG contenant le dessin de la partition sous forme vectorielle, issu du calcul de la mise en page par le programme précédent sur les deux fichiers d'entrée.

Chapitre 1

Description sémantique des partitions musicales

1. Les formats musicaux

Une centaine de formats musicaux numériques existe à ce jour, et sont malheureusement incompatibles. Chaque logiciel d'édition musicale stocke le travail typographique dans son format propriétaire, où les données musicales ne sont pas séparées des informations de mise en page ni de formatage. Les tentatives de standardisation n'ont pas pris en compte ce besoin de séparation, ce qui explique en partie leur échec.

En effet, la différence effective entre deux logiciels d'édition musicale se situe nécessairement dans la représentation des données musicales, non pas dans ces données elles-mêmes, qui doivent être strictement communes. La norme MIDI, standard musical par excellence, ne peut servir de support commun pour plusieurs raisons techniques, dont l'absence de distinction entre deux notes enharmoniques comme do dièze et ré bémol.

XML est un standard ouvert et indépendant de toute plateforme, un méta-langage conçu pour supporter la définition de langages spécifiques à des communautés différentes. Puissant, facile à implanter, international (Unicode), disposant de nombreux outils gratuits, XML est un bon candidat pour la représentation musicale car il est:

basé sur une grammaire,
déclaratif,
structuré hiérarchiquement,
modulaire,
extensible,
lisible directement par un humain,
séparateur de la structure et de la présentation.

Par ailleurs, il est possible d'appliquer des transformations à des groupes d'objets. Parmi les utilisations d'un format musical XML, l'affichage requière sans doute l'encodage représentationnel le plus complet, tandis que l'analyse en requière moins, et la performance automatique encore moins.

2. Les tentatives de standardisation

Face à cette tour de Babel des langages musicaux, en particulier ceux qui sont chargés de décrire les partitions musicales, plusieurs entreprises et institutions ont élaboré des formats, dont l'adoption n'a jamais vraiment été unanime. Un standard garantirait pourtant à la fois la pérenité des partitions et l'accès rapide aux fonds déjà numérisés. Beaucoup de représentations musicales suivent une approche trop étroite (l'affichage, la performance), et d'autre trop large (SMDL).

Voici quelques formats importants:

NIFF (Notation Interchange File Format)
CMN (Common Music Notation)
SMDL (Standard Music Description Language)
Enigma (le format du logiciel Finale)
MusiTeX (le format musical pour LaTeX)
abc (un format de notation musical en ascii)
HumDrum (un format ascii pour des outils de recherche d'informations)
MuseData (le format d'un projet de base de données musicales)

Plusieurs tentatives de définition d'un standard XML pour la représentation musicale ont été menées par différentes instances, à partir de motivations parfois divergentes, mais aucune n'a pu rencontrer le succès escompté jusqu'à maintenant.

SMDL (Standard Music Description Language):
http://www.oasis-open.org/cover/gen-apps.html#smdl
Ce standard international conforme à SGML devait définir une architecture pour la représentation des informations musicales, aussi bien seules qu'en conjonction avec du texte, du graphisme, ou d'autres informations reclamées par des besoins éditoriaux ou commerciaux. SMDL est une application "HyTime" (Hypermedia / Time-based Structuring Language), ce qui lui permettrait de supporter les séquencements temporels multimédia. Sans doute trop large, cette tentative de 1995 n'a pas abouti, les applications spécifiques étant encombrées par trop de fonctionnalités.

MNML (Musical Notation Markup Language):
http://www.irdu.nus.edu.sg/music/inet96ppt/sld001.htm
MNML est une initiative de l'IRDU (Internet Research and Development Unit) de l'Université de Singapour. Ce format minimaliste décrit presque exclusivement les notes et les silences. A titre d'exemple, citons l'absence des points staccato et des liaisons.

MHTML (Music HyperText Markup Langage):
http://www.shigeta.net/mhtml/index.htm
MHTML est une extension complète pour la notation musicale en HTML. L'une de ses qualités tient à la représentation des liaisons entrecroisées par des attributs dans les balises finales. C'est aussi une conception qui rend les exemples tout-à-fait lisibles. Malheureusement, étant un format bâtard entre HTML et XML, il n'est pas analysable par les parsers standards.

MML (Music Markup Language):
http://www.mmlxml.org/
MML est un langage basé sur SGML. Il permet l'inclusion d'éléments musicaux et d'évenements sonores dans les documents du Web, en spécifiant le balisage des structures musicales et sonores. Le site Internet de la spécification de MML est particulièrement instructif, mais aucune implémentation n'est mentionnée.

XScore (eXtensible Score Language):
http://fn2.freenet.edmonton.ab.ca/~rgrigait/xscore/
XScore est un langage XML pour la description des partitions musicales qui spécifie à la fois leur structure et leur contenu. Son objectif est proche du notre: fournir une façon standard et générique de stocker et d'échanger ces partitions. Le site Internet est intéressant, en revanche, le format en lui-même est un peu trop succint.

MusiXML:
http://www.s-line.de/homepages/gerd_castan/compmus/notationformats_e.html#MusiXML
MusiXML est un format développé par Gerd Castan, d'abord avec une DTD (MusiXML.DTD), puis avec un XML Schema (MusiXML.xsd), ce qui fait de lui le seul format musical décrit en XML Schema à l'heure actuelle. Cette caractéristique ne suffit pas à l'imposer comme format de base pour notre recherche, car les outils de développement en XML Schema sont encore trop immatures, cette norme venant seulement d'être adoptée après maintes modifications. L'objectif principal de ce format est de ne stocker chaque donnée qu'une seule fois, au lieu de les redécrire systématiquement, tout en séparant le contenu du style. Le problème est évident avec l'exemple pour une même musique d'une partition orchestre et de la partition d'un instrument de l'orchestre, qui est forcément redondante. Les deux partitions partagent des informations musicales communes. L'idée consiste donc à stocker ces informations (<content>) dans un endroit séparé, le domain logique, et d'y faire simplement référence de la manière suivante:
work -> page -> system -> staff -> measure -> reference to part of <content>
au lieu de la description redondante habituelle:
work -> page -> system -> staff -> measure -> <content>

MusicXML:
http://www.musicxml.org/xml.html
MusicXML a été conçu par la société Recordare pour représenter les partitions musicales, et plus spécifiquement la notation musicale occidentale depuis le 17ème siècle. C'est un format d'échange pour les applications de notation, d'analyse, de fouille, et de performance. MusicXML est basé sur les formats MuseData et Humdrum. Humdrum représente explicitement la nature bi-dimensionnelle des partitions par une notation de la présentation en deux dimensions. Comme XML est un format hiérarchique, il n'est pas possible d'encoder cette propriété directement, alors deux formats de haut niveau ont été déveleppés:

partwise.dtd, qui contient les mesures à l'intérieur de chaque voix (part)
timewise.dtd, qui contient les voix à l'intérieur de chaque mesure

Deux feuilles de style XSLT (parttime.xsl et timepart.xsl) sont fournies pour passer d'un format à l'autre.
Les DTD de partitions en timewise ou en partwise ne représentent qu'un mouvement d'une pièce. Plusieurs mouvements, ou toute autre collection musicale, peuvent être représentés à l'aide de la DTD opus.dtd. Le document opus contient des liens XLink vers des partitions individuelles, et évoluera vers l'inclusion de références plus détaillées et d'informations musicologiques. Il existe aussi une DTD midixml.dtd pour la représentation des fichiers MIDI en XML. MusicXML est donc un format très complet, ce qui constitue l'une des raisons de notre choix.

MusiqueXML:
http://francois.chastanet.free.fr/musiquexml/MusiqueXML.htm
MusiqueXML est un projet modeste de transformation de la notation musicale depuis un format XML vers SVG. Le format XML utilisé est en fait un sous-ensemble du XML Schema MusiXML.

NIFFML:
http://www.s-line.de/homepages/gerd_castan/compmus/notationformats_e.html#NIFF
NIFFML est une traduction simple de NIFF en XML par Gerd Castan.

ChordML:
http://www.cifranet.org/xml/ChordML.html
ChordML est une application simple qui ne représente que les paroles et les symboles d'accords, mais pas les notes.

SMIL (Synchronized Multimedia Integration Language):
http://www.w3.org/AudioVideo/
SMIL synchronise le graphisme et le son. Il n'est pas conçu pour éditer de la notation musicale, mais il sait distribuer du graphisme (des partitions) et du son, indépendemment des plateformes. Ainsi, il pourrait être utilisé à des fins pédagogiques sur le Web.

Par rapport à nos problématiques de standardisation, de compacité, et de paramétrage, plusieurs formats musicaux sont susceptibles de convenir:

MusiXML, au format XML Schema plus universel;
MusicXML, qui structure deux DTD pour les mesures et les voix;
NIFF, car beaucoup d'applications l'utilisent;
abc, car il est minimal, possède déjà un fonds important, ainsi qu'un aspect visuel intrinsèque.

A ce stade des investigations, il reste à choisir le format le plus approprié pour l'aspect sémantique, et à déterminer si l'ensemble des règles typographiques peut être complètement représenté avec les feuilles de style, simples comme les CSS (Cascading Style Sheets), ou complexes en XSL (eXtensible Stylesheet Langage).

3. Le format MusicXML

En ce qui concerne la définition structurée des partitions musicales, nous avons vu qu'il existe une certaine quantité de tentavives: laquelle faut-il choisir, et doit-on la garder entièrement ou partiellement? Nous avons établi la liste des utilisations souhaitées, en les ordonnant par ordre de priorité, afin de déterminer une structure de données adaptée, et de déceler d'éventuelles incompatibilités entre les objectifs:

standardisation
impression à l'écran et sur papier de qualité maximum
encombrement minimum
extraction de connaissances

L'information musicale dans les différents formats est structurée différemment pour optimiser chaque application. Mais développer un unique langage musical XML pourrait grandement simplifier la tâche des applications de recherche dans les bases de données et d'extraction de connaissances musicales. MusicXML est un langage d'échange de notations musicales occidentales basé sur XML. Le format MusicXML répond à un maximum de critères, et nos premiers développements n'ont pas montré d'incompatibilités. Il est très complet, au point de pouvoir décrire les liaisons entrecroisées, grâce à un système d'attributs qui indentifient le numéro de la liaison à ouvrir ou à fermer en fonction du nombre de liaisons ouvertes. L'auteur de MusicXML continue de développer son format en tenant compte des besoins des utilisateurs; nous correspondons régulièrement. Il développe aussi des convertisseurs bidirectionnels pour Finale, ce qui fait de MusicXML un standard potentiel. Même si les XML Schema sont prometteurs, les outils pour les DTD étant plus nombreux et plus matures, le fait que MusicXML soit sous-tendu par des DTD reste un avantage; son auteur est prêt à développer le XML Schema correspondant lorsque la situation s'inversera. Enfin, la définition du format est répartie sur plusieurs DTD qui sont autant d'éléments conceptuellement appréhendables, quand d'autres formats mélangent tout dans un même fichier:

attributes.dtd	clefs, armures, transpositions	attributes
barline.dtd	barres de mesure	barline
common.dtd	éléments partagés	dynamics fermata footnote level segno staff track wavy-line
direction.dtd	éléments musicaux n'étant pas attachés à une note	direction harmony print sound
identity.dtd	métadonnées, identification	ENCODING-DATE identification
link.dtd	entité pour XLink	-
note.dtd	notes, petites notes, éléments sans hauteur; accord, silences	backup figured-bass forward note
opus.dtd	collection de partitions MusicXML	opus
partwise.dtd	appelle toutes les entités extérieures sauf timewise	-
score.dtd	oeuvre, mouvements, ensemble de mesures ou de parts	score-partwise score-timewise
timewise.dtd	appelle toutes les entités extérieures sauf partwise	-

Cette description contient les coordonnées graphiques, mais elles ne sont pas obligatoires, de même que les informations sonores. Ce format décrit très précisément l'aspect sémantique, mais contient aussi des champs superflus pour l'utilisation escomptée. Nous utilisons ce format en ignorant simplement les champs qui nous sont superflus, plutôt que de le tronquer, par souci de compatibilité. Nous appliquons des feuilles de style sur des fichiers validés par ces DTD pour générer les fichiers de sortie graphiques.

Chapitre 2

Dessin vectoriel de partitions sur le Web

1. Les polices musicales

Les éditeurs de partitions perfectionnés utilisent tous des polices de caractères standards et des polices musicales. Ces dernières permettent de stocker les caractères musicaux nécessaires, de les appeler avec un seul code, et offrent des mécanismes précieux pour la mise en page et la mise à l'échelle. Typiquement, les polices vectorielles encodent les dessins musicaux sous la forme d'un tracé vectoriel, défini par des points d'ancrage, des lignes, et des courbes de Bézier. Ce mécanisme permet de zoomer à l'infini sans aucune dégradation de l'image, sous réserve que les algorithmes de mise à l'échelle prennent quelques précautions d'usage.

Unicode a inclu récemment des symboles musicaux dans son immense entreprise de codage des caractères (cf. Annexes). Les descriptions sont assez précises pour les signes spécifiés, mais beaucoup de signes sont encore absents. Néanmoins, l'équipe d'Unicode étant active, et SVG supportant Unicode, il est raisonnable de penser que les futures applications de notation musicale en feront usage.

L'inclusion de polices de caractères reste un problème délicat sur le Web. Beaucoup d'applications ont besoin de polices multiples, mais les navigateurs actuels n'embarquent que six polices. Pour les applications de notation musicale, ces polices ne sont pas utilisables, et il faut trouver des moyens plus lourds, comme l'interprète PostScript embarqué dans une Applet Java d'édition, développé par Nabil Bouzaïene.

De toutes façons, les polices musicales posent des problèmes de disponibilité. En utilisant Java, on peut exécuter des programmes sur presque toutes les plateformes, mais on ne peut pas s'assurer qu'il y ait une police musicale d'installée sur la plateforme d'exécution, ni même qu'elle soit installable. Au contraire, en utilisant SVG, un programme de notation musicale peut transporter avec lui tous les symboles de notation musicale dont il a besoin.

Les polices utilisées par SVG doivent nécessairement être soit au format True Type 1, soit au format SVG Font, ce qui n'est actuellement pas le cas des polices utilisées par l'éditeur mentionné. Cependant, moyennant quelques manipulations, il devrait être possible de rendre les deux polices Didone et Hector en True Type 1.

Incidemment, la librairie Batik d'Apache gère le format SVG et les polices SVG. L'annonce suivante est tirée de la discussion sur Batik, et propose déjà un convertisseur de polices True Type vers SVG. "The SVG Font Converter illustrates how Batik can help you embed SVG Font definitions in an SVG file by providing an application that converts ranges of characters from a True Type Font format to the SVG Font format."

2. La résolution graphique maximum

Sur le Web, les partitions musicales sont affichées et stockées sous forme d'images bitmaps, souvent au format GIF ou PDF. Soit l'affichage est lourd et lent si l'image est codée en haute résolution, soit la visualisation est médiocre si l'image est codée en basse résolution. De plus, toute manipulation structurelle est interdite puisque la structure logique de la partition a disparu.

Actuellement, il n'existe pas de moyen de visualiser des données vectorielles directement dans un navigateur. Il existe en revanche des moyens détournés, comme le téléchargement du plug-in Flash de Macromedia qui visualise des fichiers vectoriels dans un format propriétaire. Mais surtout les développements à venir sont prometteurs. L'image vectorielle est une nécessité pour le Web pour des raisons évidentes de bande passante: une image vectorielle est généralement beaucoup volumineuse qu'une image bitmap, surtout pour les images de grande taille, ou celles dont le contenu peut s'exprimer de façon simple géométriquement.

XML est un bon langage pour les marquages sémantique et typographique. Appliquer des feuilles de style sur un fichier XML dont la structure est décrite par un XML Schema multiplie les fichiers à manipuler. La non-minimalité du format XML ne semble pas être un obstacle car il se compresse très bien, d'environ un facteur 30. Une enquête rapide montre que le fonds musical disponible se compose essentiellement de fichiers MIDI, quelques fichiers ABC, et une dizaine de NIFFML. SVG semble être un bon candidat pour l'aspect graphique, car il est lui-même défini en SVG, et il intègre les polices à plusieurs niveaux, permet d'importer ses propres glyphes et d'utiliser les nouveaux caractères musicaux d'Unicode.

En fait, non seulement SVG permettra d'atteindre une résolution graphique maximum, entre autres pour la visualisation des partitions sur le Web, mais aussi à un coût minimum en terme de mémoire, tout en gardant certaines possibilités de manipulation après un téléchargement.

3. Le rendu en SVG

SVG est un format pour le graphisme basé sur XML. Deux applications intéressantes de ce format sont envisageables:

le remplacement des polices musicales, qui ne sont pas multiplateformes, alors qu'un programme utilisant SVG peut embarquer tous les symboles nécessaires;
l'intégration de la notation musicale sur le Web, avec à la fois des fichiers de petite taille, un affichage de haute qualité, et l'impression de haute qualité pour ces mêmes données.

En pratique, bien que les principaux navigateurs n'intègrent pas encore d'interprète SVG, il est envisageable de programmer des applications qui génèrent des fichiers SVG, car Adobe a développé un plug-in idoine pour Netscape et Explorer sous les plateformes Macintosh et Windows; le navigateur Amaya intègre une bonne partie de SVG, et batik permet sous Linux de visualiser les fichiers SVG. Par contre, comme notre plateforme de développement est Linux, tant que Netscape Linux n'intègre pas SVG, il serait prématuré de développer un plug-in qui génère du code SVG comme il était initialement prévu.

Au niveau du développement, deux formats de sortie pour l'affichage étaient intéressants: produire un fichier SVG, ou produire un fichier dans le format de l'éditeur partagé de Nabil Bouzaïene. Le premier a l'avantage de l'universalité et doit donc rester l'objectif de ce stage, même si la seconde a celui de la continuation des travaux antérieurs.

Les nouvelles recommendations du W3C sur XML et SVG sous-tendent notre outil de démonstration. Celui-ci permet de transformer une partition de musique écrite dans le formalisme XML en une partition de musique affichable dans le formalisme SVG. Cette dernière peut être visualisée par deux outils: l'application Java Batik-svgbrowser, d'Apache, et le plug-in SVGViewer, d'Adobe. Notre choix de DTD pour écrire la partition s'est porté sur le format MusicXML, parce qu'il est le plus complet et qu'il repose sur des DTD.

L'image de la page de garde montre la visualisation du fichier out.svg dans la fenêtre de batik-svgbrowser. Bien que représentant peu de symboles, cette visualisation démontre la validité du principe de paramétrage automatique du rendu typographique en SVG des partitions MusicXML par feuilles de style XSLT. En effet, tous les types d'éléments graphiques requis par la visualisation des partitions sont présents:

du texte (le titre et le compositeur dans des polices de tailles différentes),
des éléments purement graphiques (les portées sont cinq objets <svg:line>)
des glyphes référencés à l'extérieur (la clé de sol est un tracé complexe stocké dans un fichier externe)

Chapitre 3

Feuilles de style musicales

1. Les feuilles de style

Grâce aux feuilles de style, de nombreuses propriétés graphiques ou typographiques du document final sont absentes du document source. De fait, une feuille de style est un document qui contient toutes ces propriétés. Il existe plusieurs langages de spécification de feuilles de style. Ils permettent tous d'indiquer les modalités de réalisation physique de chacun des éléments qui composent un document, en prenant en compte l'existence et la valeur des attributs qui leur sont éventuellement associés. Par réalisation physique, nous entendons aussi l'impression sur papier l'affichage sur des écrans de tailles et de technologies diverses, la lecture d'un document par un logiciel de synthèse vocale, ou sa réalisation sur un terminal Braille mono ou multiligne.

Le mécanisme de feuilles de style le plus puissant à ce jour est XSLT, qui permet de spécifier des règles de transformation du document d'origine, bien au-delà de la simple mise en pages.

Element Description

xsl:apply-imports Applies a template from an imported stylesheet

xsl:apply-templates Applies a template to the current element

xsl:attribute Adds an attribute to the nearest containing element

xsl:attribute-set Defines a named set of attributes

xsl:call-template Provides a way to call a named template

xsl:choose Provides a way to choose between a number of alternatives based on conditions

xsl:comment Creates an XML comment

xsl:copy Copies the current node without childnodes and attributes to the output

xsl:copy-of Copies the current node with childnodes and attributes to the output

xsl:decimal-format Defines the character/string to be used when converting numbers into strings, with the format-number function

xsl:element Adds a new element node to the output

xsl:fallback Provides a way to define an alternative for not implemented instructions

xsl:for-each Provides a way to create a loop in the output stream.

xsl:if Provides a way to write a conditional statement

xsl:import Imports a stylesheet

xsl:include Includes a stylesheet

xsl:key Provides a way to define a key

xsl:message Writes a message to the output

xsl:namespace-alias Provides a way to map a namespace to another namespace

xsl:number Writes a formatted number to the output

xsl:otherwise Indicates what should happen when none of the <xsl:when> elements inside an <xsl:choose> element is satisfied

xsl:output Provides a way to control the transformed output

xsl:param Provides a way to define parameters

xsl:preserve-space Provides a way to define the handling of white-space

xsl:processing-instruction Writes a processing instruction to the output

xsl:sort Provides a way to define sorting

xsl:strip-space Provides a way to define the handling of white-space

xsl:stylesheet Defines the root element of the style sheet

xsl:template Defines a template for output

xsl:text Writes text to the output

xsl:transform Defines the root element of the style sheet

xsl:value-of Creates a text node and inserts a value into the result tree

xsl:variable Provides a way to declare a variable

xsl:when Defines a condition to be tested and performs an action if the condition is true. This element is always a child element of <xsl:choose>

xsl:with-param Provides a way to pass parameters to templates

Element	Description
xsl:apply-imports	Applies a template from an imported stylesheet
xsl:apply-templates	Applies a template to the current element
xsl:attribute	Adds an attribute to the nearest containing element
xsl:attribute-set	Defines a named set of attributes
xsl:call-template	Provides a way to call a named template
xsl:choose	Provides a way to choose between a number of alternatives based on conditions
xsl:comment	Creates an XML comment
xsl:copy	Copies the current node without childnodes and attributes to the output
xsl:copy-of	Copies the current node with childnodes and attributes to the output
xsl:decimal-format	Defines the character/string to be used when converting numbers into strings, with the format-number function
xsl:element	Adds a new element node to the output
xsl:fallback	Provides a way to define an alternative for not implemented instructions
xsl:for-each	Provides a way to create a loop in the output stream.
xsl:if	Provides a way to write a conditional statement
xsl:import	Imports a stylesheet
xsl:include	Includes a stylesheet
xsl:key	Provides a way to define a key
xsl:message	Writes a message to the output
xsl:namespace-alias	Provides a way to map a namespace to another namespace
xsl:number	Writes a formatted number to the output
xsl:otherwise	Indicates what should happen when none of the <xsl:when> elements inside an <xsl:choose> element is satisfied
xsl:output	Provides a way to control the transformed output
xsl:param	Provides a way to define parameters
xsl:preserve-space	Provides a way to define the handling of white-space
xsl:processing-instruction	Writes a processing instruction to the output
xsl:sort	Provides a way to define sorting
xsl:strip-space	Provides a way to define the handling of white-space
xsl:stylesheet	Defines the root element of the style sheet
xsl:template	Defines a template for output
xsl:text	Writes text to the output
xsl:transform	Defines the root element of the style sheet
xsl:value-of	Creates a text node and inserts a value into the result tree
xsl:variable	Provides a way to declare a variable
xsl:when	Defines a condition to be tested and performs an action if the condition is true. This element is always a child element of <xsl:choose>
xsl:with-param	Provides a way to pass parameters to templates

2. La séparation entre les données musicales et leur représentation graphique

L'information diffère des données. Le format XML doit séparer la syntaxe de la sémantique, entre autres pour permettre l'extraction de données musicales sans téléchargements inutiles. Parmi les formats XML disponibles actuellement, nos recherches ont désigné comme meilleur candidat MusicXML.

XML fut pressenti dès son arrivée comme une technologie qui allait révolutionner l'échange de données. Les feuilles de style lui permettent de se dégager des informations de présentation, ce que n'a pas pu faire HTML. Cette séparation de la description structurelle des documents et de la description de leur réalisation physique offre d'énormes avantages en termes de facilité d'échange et de production coopérative de documents, d'indépendance par rapport à des logiciels particuliers, et de pérennité des documents sur le très long terme. Surtout, elle ouvre des possibilités importantes en termes de traitement automatisé de documents. Grâce notamment à cette séparation entre contenu et "mise en pages", XML pourra être utilisé comme un formalisme puissant et commode pour l'échange de données entre les applications informatiques les plus diverses.

Les DTD, le langage de schéma actuel pour spécifier le contenu et la structure de documents XML, souffrent de quelques déficiences. Tout d'abord, les DTD ne sont pas écrites en XML, ce qui signifie que les technologies existantes pour manipuler des documents XML telles que DOM ou SAX ne peuvent être utilisées pour analyser (« parser ») des schémas de documents. Ensuite, les DTD ne supportent pas les espaces de nom, c'est-à-dire que des conflits entre deux éléments homonymes provenant de DTD différentes peuvent apparaître, ce qui rend impossible l'import de définitions externes afin de réutiliser du code existant. Enfin, et surtout, les DTD n'offrent qu'un typage très limité des données. Conscient de ces fâcheuses limitations, le W3C a récemment proposé un nouveau langage de définition de schéma, XML Schema. Conçu pour palier les déficiences précitées des DTD, XML Schema propose, en plus des fonctionnalités fournies par les DTD, des nouveautés :

un grand nombre de types de données intégrées comme les booléens, les entiers, les intervalles de temps, etc. De plus, il est possible de créé de nouveaux types par ajout de contraintes sur un type existant;
des types de données utilisateurs qui vous permettent de créer votre propre type de données nommé;
la notion d'héritage. Les éléments peuvent hériter du contenu et des attributs d'un autre élément. C'est sans aucun doute l'innovation la plus intéressante de XML Schema;
le support des espaces de nom;
les indicateurs d'occurrences des éléments peuvent être tout nombre non négatif;
une grande facilité de conception modulaire de schémas;

XML Schema va donc permettre à XML d'atteindre son potentiel maximal. Evidemment, il est possible d'appliquer des feuilles de style sur un fichier XML dont la structure est décrite par un XML Schema, comme sur tout fichier XML.

3. L'automatisation du rendu typographique avec XSLT

Une partie de nos recherche s'est concentrée sur la définition du paramétrage typographique, à travers les feuilles de styles musicales. Il a fallu définir au préalable quels outils de programmation utiliser. Le choix n'a pas été évident, car beaucoup d'outils sont diffusés au sein de la communauté informatique sur Internet: des API (Application Programming Interface) comme SAX ou SAX2 qui permettent de traiter du XML, et des parsers comme JAXP,JAXB, ou JAXM, qui permettent d'analyser des fichiers XML.

Il existe beaucoup de librairies Java pour manipuler du XML, en voici quelques unes:

Apache's XML Project
Sun's Java Project X Package
IBM's XML4J v2 Package
Oracle's v2 XML PackageDataChannel's XJParser Package
Microstar's AElfred Parser
James Clark's XP Parser

La version du kit de développement Java installée est la 1.3.0_02, mais quelques problèmes de configuration pour la compilation de fichiers qui font appel à certains paquages externes ont d'abord dû être résolus. Il a aussi fallu apprendre les API Java spécifiques à XML et leur utilisation, comme les DOM (Document Object Model), et SAX (Simple API for XML).

Par souci de cohérence avec Batik et Xalan, nous avons choisi d'utiliser la bibliothèque Xerces d'Apache pour traiter les documents XML, bien que XML4J d'IBM semble aussi être une excellente librairie. La bibliothèque Xalan d'Apache nous permet d'utiliser des feuilles de style de transformation XSLT, et assure une compatibilité avec les API de Xerces, qui la sous-tend.

La version 1.3.1 de Xerces propose des parsers DOM (Document Object Model), SAX (Simple API for XML), et SAX2. Une première analyse comparative a été faite, ainsi qu'un test positif de chargement et d'analyse de fichier MusicXML, qui confirme la validité de ce choix. Xerces continue d'évoluer, notammant vers le support du récent XML Schema: "Xerces-J 1.4.0 is now ready for prime-time. The most important new feature in Xerces-J 1.4.0 is full schema support (except for some small limitations as detailed in the documentation)."

La version 1.2.2 de Xalan propose entre autres un processeur XSLT qui nous permet d'appliquer nos feuilles de style sur nos documents MusicXML. Ce processeur parcours un document XML, et lorsqu'il trouve un motif correspondant à l'un des motifs de la feuille de style, il applique le patron de règles décrites dans celle-ci. Ainsi, le processeur Xalan construit un arbre-résultat à partir d'un arbre-source. Ce couple processeur / feuille de style permet de manipuler la structure logique des documents XML, ce dont nous avons besoin pour développer notre moteur de conversion MusicXML vers SVG. En effet, il s'agit de constuire un arbre-résultat SVG contenant les éléments graphiques à partir des éléments syntaxiques contenus dans un arbre-source MusicXML.

Ce processeur XSLT nous est aussi utile pour changer de représentation MusicXML: partwise ou timewise. De fait, en amont, MusicXML utilise déjà deux feuilles de style parttime.xsl et timepart.xsl, respectivement pour passer d'une représentation par voix (verticalement sur la partition d'orchestre) à une représentation par mesures (horizontalement), et réciproquement.

Notre programme MusicXML2SVG.java, un premier traducteur MusicXML vers SVG, a permi de tester les concepts et les représentations. Ce premier développement a nécessité l'apprentissage de nombreuses technologies: des langages dont Java, XML, et XSL, des concepts tels les DOM, des normes particulières dont MusicXML et SVG, et des librairies en cours de développement dont Xerces et Xalan. Le fonctionnement reste pourtant simple en apparence: un programme Java charge un processeur Xalan, puis lui demande d'appliquer sur un fichier XML une feuille de style XSLT, et de retourner le résultat dans un fichier quelconque, ici ce sera un fichier SVG.

Ce code fonctionne, mais la feuille de style (par exemple musicxml2svg05.xsl) se limite pour l'instant à détecter une partition MusicXML (partwise), puis le titre et le compositeur, et une mesure pour générer une portée en SVG. C'est suffisant pour démontrer les potentialités de ce mécanisme et la validité de nos choix technologiques et conceptuels. Néanmoins, il faudrait développer l'ensemble du code, notamment pour modéliser un ensemble complet de règles de paramétrage typographique.

Cela risque de poser certains problèmes techniques au niveau de la gestion des polices musicales, de localisation des calculs. Les mécanismes XSLT sont si puissants qu'ils accaparent une partie des calculs, en les modélisant dans les règles de transformation. Or certains calculs doivent rester dans le programme Java.

Conclusion

Ce stage s'est déroulé en deux temps: la période d'investigation, puis la phase développement. Les connaissances rassemblées concernent:

la notation musicale,
la typographie numérique,
la justification automatique,
les formats numériques de représentation musicale,
le langage XML avec les DTD et les XML Schemas,
les feuilles de styles XSL, XSLT et CSS,
la norme SVG,
le format MusicXML, et
le langage Java.

L'intérêt du sujet initial sur la conception d'une norme XML pour les partitions musicales s'est effacé en partie devant l'apparition récente des formats comme MusicXML ou MusiXML. Néanmoins, la séparation des aspects sémantique et syntaxique est restée d'actualité, puisqu'aucun format ne dispose de cette structure pourtant familière à XML. La problématique est alors devenue la suivante: comment afficher correctement des partitions qui ne contiennent pas directement leur mise en page? Techniquement, cela se traduit par l'application de feuilles de style XSLT sur les fichiers MusicXML sémantiques, grâce à un processeur Xalan écrit en Java.

Nos choix technologiques sont les suivants:

MusicXML pour les fichiers sémantiques d'entrée, car l'analyse ce format a démontré ses fortes aptitudes à la description sémantique;
SVG pour les fichiers graphiques de sortie, pour ses orientations vectorielles et réseau;
XSLT pour les feuilles de style, qui modélisent ainsi les règles typographiques;
Java comme langage de programmation, notamment pour ses fortes accointances avec XML, et pour la cohérence avec les développements précédents du laboratoire.

Certaines perspectives de développement sont envisageables à court terme, en particulier par rapport aux travaux antérieurs du laboratoire concernant l'éditeur de partition en ligne coopératif développé par Nabil Bouzaïene. Il s'agit d'un appelet Java que l'on pourrait étendre de manière à ce qu'il génére des fichiers dans les formats précités. Il est possible de programmer un plug-in pour Netscape qui convertirait les fichiers XML vers SVG, puis un second qui dessinerait effectivement à l'écran ces fichiers SVG, et enfin interfacer l'applet avec ces plug-ins pour obtenir un éditeur de partition en ligne coopératif, multipolices, et conforme à des normes vectorielles et musicales précises.

Gerd Castan, qui maintient un site très complet sur les formats musicaux, développe aussi actuellement un système XSLT pour générer un fichier SVG à partir d'une partition décrite dans son format MusiXML; nous restons en contact. Par ailleurs, Michael Good est intéressé par le rendu SVG de fichiers MusicXML.

Glossaire

Cette recherche utilisant de nombeuses technologies informatiques récentes, une connaissance approfondie d'une certaine quantité de sigles, de logiciels, de divers outils, et de concepts est nécessaire, et a demandé un travail préalable conséquent de documentation en bibliothèque et sur Internet.

abc:
http://www.gre.ac.uk/~c.walshaw/abc/
Le langage abc a été mis au point par Chris Walshaw pour permettre de noter la musique en format ASCII. Il s'inspire de la manière dont on nomme les notes de la gamme dans le système anglo-saxon ( a=la; b=si; c=do; d=ré; e=mi; f=fa; g=sol) Le langage développé par Chris Walshaw était conçu au départ pour la musique traditionnelle d'Europe occidentale (irlandaise, anglaise, écossaise etc...) écrite sur une seule portée en notation classique. En fait le système est extensible à beaucoup d'autres genres de musique. Depuis fin 1991, le système s'est rapidement répandu et il existe à présent plusieurs logiciels sur PC, UNIX et Macintosh qui peuvent non seulement lire le langage abc mais aussi le jouer sur les haut-parleurs d'un ordinateur et afficher les portées musicales. Une des caractéristiques principales de la notation abc, et sans doute ce qui la différencie nettement des autres langages d'informatique musicale, est qu'on peut lire les fichiers sans l'aide d'un ordinateur. En effet, avec un peu d'entraînement, il est possible de déchiffrer un air directement depuis sa transcription abc sans avoir à le traduire en portées et l'imprimer. La simplicité du système en fait donc aussi un outil facile pour la notation musicale. De plus les fichiers abc sont peu encombrants et aisés à transmettre par courrier électronique.

Amaya:
http://www.w3.org/Amaya/
Amaya est un navigateur/éditeur de documents pour le Web, utilisé pour tester et montrer les nouveaux développements en matière de protocoles Web et de formats de données. Etant donné la nature très versatile des technologies Web, Amaya doit jouer un rôle central. Il est adaptable et extensensible, et disponible à la fois sur les plateformes Unix et Windows '95/NT.
Amaya est un environnement complet de navigation et de création avec une interface de type WYSIWYG (What You See Is What You Get), comme la plupart des navigateurs du commerce. Grâce à cette interface, les utilisateurs peuvent facilement générer des pages HTML et XHTML, ainsi que des feuilles de style CSS, des expressions MathML, et des dessins SVG (cependant le support complet de SVG n'est pas encore disponible).
Amaya est un projet "open source" hébergé par le W3C, chacun est donc invité à apporter une contribution quelqu'en soit la forme (documentation, traduction, écriture de code, résolution de bugs, portage sur d'autres plateformes...).

API:
Application Programming Interface / Interface pour la programmation d'application.
Une API est un ensemble de fonctions et d'objets réutilisables mis à la disposition de la communauté des développeurs.

Batik:
http://xml.apache.org/batik/
Batik est un ensemble d'outils Java manipulant des images au format SVG. L'ambition du projet Batik est de fournir aux développeurs un ensemble de modules utilisables individuellement ou collectivement pour supporter des solutions SVG spécifiques comme la visualisation, la génération, ou la manipulation. Il fournit déjà des phraseurs SVG, des générateurs SVG et des implémentations de DOM SVG. Ce projet se veut extensible: par exemple, Batik permet au développeur d'employer ses propres balises SVG. L'un des programmes fourni avec cet ensemble est un visualiseur SVG arrivé à maturité, qui valide les différents modules et leur inter-opérabilité.

CSS:
Cascading Style Sheets / Feuilles de style en cascade.
http://www.w3.org/Style/CSS/
CSS est un mécanisme puissant et relativement complexe pour gérer des styles (par exemple les polices, les couleurs, l'espacement) des documents Web. Les feuilles de style CSS sont donc utilisées pour la mise en page sur le Web comme méthodes efficaces de définitions et d'organisation des styles pour l'affichage du texte et des graphismes. Les CSS ont été initialement conçues pour le langage HTML. La première version CSS1 a été publiée en 1996 par le W3C, et la seconde version CSS2 en 1998. Celle-ci introduit notamment la notion de type de média qui donne la possibilité de spécifier la mise en pages d'un document en vue de son affichage sur écran, de son impression sur papier, ou d'indiquer les conditions de sa réalisation par sythèse vocale. SVG utilise CSS2 pour inclure des feuilles de style en ligne, externes, ou integrées. Tout ce qui concerne les attributs textuels de mise en page (comme les espacements) et les attributs graphiques (comme les propriétés fill et stroke) peut être défini en tant que style. Techniquement, les CSS sont définies en deux parties: le sélecteur et le style. Dans l'exemple suivant "rectangle" est le sélecteur et "fill:red" est le style:
.rectangle {fill:red;}
Les styles permettent à l'auteur de "cascader" des changements à travers un document ou un site en éditant la définition.

DOM:
Document Object Model / Modèle objet de document.
http://www.w3.org/DOM/
Le DOM est une norme du W3C qui spécifie une interface permettant aux développeurs d'écrire des fonctions de création, de modification, et de consultation des éléments constitutifs d'un document XML ou HTML. Il est défini indépendamment d'une plateforme ou d'un langage. Le modèle de représentation de document utilisé par le DOM est le bosquet, c'est-à-dire un graphe composé d'arbres et d'arcs reliant certains noeuds d'un arbre à un autre. La structure du DOM est décrite en annexe.

DTD:
Document Type Definition / Définition de type de document.
Les documents valides obéissent à une structure type prédéfinie. La DTD est le mécanisme par lequel de telles structures sont spécifiées. Produire des documents valides présente un double intérêt: les DTD sont réutilisables, souvent libres de droits, et les DTD rendent la validation automatique. Par ailleurs, une feuille de style se définit toujours par référence à la structure des documents à formater: si les documents sont valides, la même feuille de style s'appliquera à tous les documents conformes à une même DTD. Les DTD peuvent être internes ou externes, les définitions internes étant prioritaires.

HTML:
HyperText Markup Language / Langage de balisage hypertextuel.
http://www.w3.org/MarkUp/
HTML est le langage de publication hypertextuelle sur le Web. C'est un format non propriétaire basé sur SGML, et dont les documents conformes peuvent être créés et utilisés par un grand nombre d'outils, depuis le simple éditeur de texte - on peut saisir le contenu directement -, jusqu'aux outils d'édition WYSIWYG les plus sophistiqués. HTML utilise des balises comme <h1> et </h1> pour stucturer du texte en titres, paragraphes, listes, liens hypertextuels, etc. A la différence de XML, c'est un langage de présentation.

Java:
http://www.javasoft.com/
Java est un langage de programmation objet de Sun Microsystems. Il s'inspire du C++ et permet entre autres de réaliser des pages Web dynamiques avec des animations, des textes défilants... En outre, il est indépendant du système sur lequel il s'exécute. Java permet de construire de petites applications (applets) qui sont appellées dans les pages Web. Il s'est vu adjoindre deux API spécialisées dans le traitement de document XML, qui sont toutes les deux fournies dans un ensemble de package connu sous le nom de JAXP (Java API for XML Parsing).

Navigateur ou browser:
http://www.netscape.com/
http://www.microsoft.com/
Un navigateur est un logiciel qui permet à l'utilisateur de rechercher et de consulter des documents, et d'exploiter les liens hypertextuels qu'ils comportent, dans un environnement de type Internet. Les plus connus sont Netscape Navigator, actuellement dans sa version 6, et Internet Explorer, arrivant dans sa version 6 aussi. Ces nouvelles versions promettent le support de XML. Amaya reste un navigateur marginal destiné à tester les nouvelles technologies d'Internet.

Parser ou phraseur:
Analyseur syntaxique et lexical, ou phraseur - traduction proposée par Emmanuel Saint-James.
Toute application qui doit traiter des entités XML est interfacée avec un phraseur à travers une API. Il existe deux API standard, qui correspondent à deux modèles de traitement différents des documents. Le premier modèle est appelé "traitement dirigé par les évenements", car chaque évenement de l'analyse du flot de données est signalé à l'application par une fonction de renvoi (callback); il s'agit de SAX. Dans le second modèle, le phraseur compile l'ensemble du document et en construit une représentation interne complète; il s'agit de DOM.

SAX:
Simple API for XML / API simple pour XML.
http://www.xml.org
SAX est un standard de fait, pur produit de la coopération spontanée et volontaire des développeurs sur Internet. Ceux-ci constataient en 1997 que les différents phraseurs expérimentaux alors disponibles offraient tous des API différentes, et que cette diversité interdisait de changer facilement de phraseur lorsqu'un nouveau était proposé. Regroupés sur une liste de discussion [XL-dev], ces développeurs décidèrent alors de définir une API commune, décrite en Java, et une implémentation de référence, mise dans le domaine public. Le résultat, SAX, est maintenant reconnu par la quasi-totalité des phraseurs du marché fondés sur le modèle évènementiel.

SGML:
Standard Generalized Markup Language / Langage normalisé de balisage généralisé
Cette norme d'échange de documents structurés s'est révélée trop complexe pour que des navigateurs puissent être implémentés facilement par les industriels. Elle est adaptée aux grandes documentations techniques ou lexicographiques, mais pas à Internet, notamment à cause d'une gestion lourde des liens hypertextes et d'un mécanisme de validation trop strict.

SVG:
Scalable Vector Graphics / Graphismes vectoriels redimensionnables.
http://www.w3.org/Graphics/SVG
SVG est un langage de description des graphismes bi-dimensionnels en XML. SVG permet de manipuler trois types d'objets graphiques:

des formes vectorielles (par exemple, des parcours en lignes droites et en courbes),
des images,
du texte.

Les objets graphiques peuvent être groupés, stylés, transformés et recomposés dans les objets rendus précédemment. Du texte peut être inséré dans n'importe quel espace de noms XML de l'application, ce qui renforce les possibilités de recherche et d'accès des graphismes SVG. L'ensemble de fonctionnalités inclut les transformations emboîtées, les pochoirs, les masques alpha, les effets de filtre, les patrons, et une certaine extensibilité. Les dessins SVG peuvent être dynamiques et interactifs. Le DOM de SVG, qui inclut le DOM XML complet, permet de faire de l'animation graphique vectorielle via des scripts. Un ensemble de fonctions de prise en charge d'évenements tels que onmouseover et onclick peut être assigné à n'importe quel objet graphique SVG. Grâce à sa compatibilité avec d'autres standards du Web, des fonctionnalités comme l'application d'un script peuvent être faites simultanément sur des éléments SVG et d'autres éléments XML provenant d'espaces de noms différents, au sein de la même page Web. Nous utilisons SVG comme format de sortie pour la visualisation des partitions sur le Web.

Xalan:
Processeurs de feuille de style XSLT, disponibles en Java et C++.
http://xml.apache.org/xalan/index.html
Xalan implémente complètement les recommandations XSLT et XPath du W3C. Le processeur de feuille de style est robuste et propose de nombreuses fonctionnalités. Le processeur XPath est utilisable de façon indépendante. Xalan utilise le Bean Scripting Framework (BSF) pour implémenter les extensions de Java ou des autres langages de script.

Xerces:
Parser XML, disponible en Java et C++.
http://xml.apache.org/xerces-j/index.html
Le phraseur Java Xerces 1.3.1 supporte la recommandation XML 1.0 et contient d'autres fonctionnalités avancées, comme XML Schema, DOM niveau 2 version 1.0, et SAX version 2, en plus de supporter les API standardisées DOM niveau 1 et SAX version 1.

XML:
eXtended Markup Langage / Langage de balisage extensible.
http://www.w3.org/XML/
XML est un langage de description et d'échange de documents structurés. C'est un sous-ensemble de SGML qui permet de décrire la structure logique de documents principalement textuels, à l'aide d'un système de balises permettant de marquer les éléments qui composent la structure, et les relations entre ces éléments. Son but est de permettre au SGML générique d'être transmis, reçu et traité sur le Web de la même manière que l'est HTML aujourd'hui. XML a été conçu pour être facile à mettre en oeuvre et interopérable avec SGML et HTML. Il représente une solution aux limites d'HTML devant les hyperdocuments complexes, et aux difficultés de mise en réseau de SGML.

XML Schema:
http://www.w3.org/XML/Schema
Les XML Schemas expriment des vocabulaires partagés et permettent aux machines de dégager les règles élaborées par les gens. Ils fournissent un moyen de définir la structure, le contenu, et la sémantique des documents XML. La proposition XML Schema vient d'être approuvée en tant que Recommandation du W3C récemment, le 02/05/2001. Les XML Schemas remplacent avantageusement les DTD sur beaucoup de plans, sauf celui de la quantité d'outils matures disponibles.

XPath:
http://www.w3.org/TR/xpath
XPath est un langage pour le référencement des parties d'un document XML, conçu par le W3C pour être utilisé à la fois par XSLT et XPointer.

XSL:
eXtensible Stylesheet Language / Langage extensible de feuille de style.
http://www.w3.org/Style/XSL/
XSL est un langage pour écrire des feuilles de style applicables sur des documents XML. Il est divisé en trois parties:

XSLT (XSL Transformations): un langage pour la transformation de documents XML
XPath (XML Path Language): un langage d'expression utilisé par XSLT pour accéder ou référencer des parties d'un document XML. XPath est aussi utilisé par XLink, la spécification de liens XML.
XSLFO (XSL Formatting Objects): un vocabulaire XML qui spécifie des sémantiques de formatage.

Une feuille de style XSL spécifie la présentation d'une classe de documents XML, en décrivant coment une instance de la classe est transformée en un document XML qui utilise le vocabulaire de formatage. A la différence de CSS, XSL utilise une notation XML.

XSLT:
XSL Transformations
http://www.w3.org/TR/xslt
XSLT est un langage utilisé pour transformer des documents XML en d'autres documents XML. XSLT est conçu pour être utilisé comme une partie de XSL, le langage des feuilles de style de XML. XSL spécifie les règles de présentation d'un document XML en utilisant XSLT pour décrire comment le document peut être transformé en un autre document qui utilise le vocabulaire de formatage.
XSLT est aussi conçu pour être utilisé indépendamment de XSL. Cependant, XSLT n'est pas censé être utilisé comme un langage de transformation XML à vocation générale. Il a surtout été conçu pour les types de transformations nécessaires lorsque XSLT est utilisé comme une partie de XSL. Nous utilisons XSLT pour transformer des documents MusicXML en documents SVG, tous deux définis en XML, et pour stocker les règles de transformation, dont les règles de mise en page.

W3C:
http://www.w3.org/
World Wide Web Consortium.
Le W3C développe des technologies "interopérables" (spécifications, lignes directrices, logiciels, et outils) afin de conduire le Web vers son potentiel maximum comme forum pour l'information, la communication, et la compréhension collective. Il regroupe les principaux acteurs d'Internet, les industriels fournisseurs des technologies informatiques comme les grands utilisateurs publiques ou privés.

Web ou World Wide Web:
Le Web est la partie d'Internet concernant la consultation de sites, généralement en format HTML. C'est la vitrine et la partie visible d'Internet, accessible à travers un navigateur.

Références bibliographiques

Bibliographie:

Travaux précédents du laboratoire:

La notation musicale aux prises avec l'ordinateur, Nabil Bouzaïene 1996
Une bibliothèque informatique pour la notation musicale baroque, Nabil Bouzaïene, Loïc Le Gall, Emmanuel Saint-James, in Electronic Publishing, Artistic Imaging, and Digital Typography, Springer 1998
Infographie musicale, Etat de l'art & Perspectives, Nabil Bouzaïene, Emmanuel Saint-James, in JIM 1998
Edition distribuée de partitions musicales multi-polices, Nabil Bouzaïene, Catherine Guastavino, Emmanuel Saint-James, in JIM 1999
Justification automatique de partitions, in JIM 2000
Typographie Coopérative de Partitions Musicales par Navigation Interprétative de Contours, thèse de doctorat de l'Université Paris 6 spécialité informatique de Nabil Bouzaïene, juillet 2000.

XML:

XML Schema Part 0: Primer; W3C 30 mars 2001
Unleashed XML; Michael Morrison, ed. Sams Publishing 2000
SVG 1.0 Specification, W3C Candidate Recommandation 2000
XML Langage et applications, Alain Michard, Eyrolles 3e tirage 1999
Le programmeur XML, Simon North et Paul Hermans, CampusPress 1999
XML and Java: Developing Web Application; Hiroshi Maruyama, Kent Tamura, Naohiko Uramoto (IBM), ed. Addison-Wesley 1999
De l'écrit au numérique -constituer, normaliser et exploiter les corpus électroniques-, Benoît Habert, Cécile Fabre, Fabrice Issac, InterEditions Masson 1998
Compilation d'articles sur les représentations musicales en XML, par un étudiant de Gérarg Assayag .
Rapport MusiqueXML de François Chastanet.

Programmation:

La Programmation Applicative, Emmanuel Saint-James, Hermes 1993
Programmation Java, Jean-François Macary et Cédric Nicolas, Eyrolles 1996
The Java Programming Language Third Edition; Ken Arnold, James Gosling, David Holmes, ed. Sun Microsystem 2000
Plug-in Guide, Communicator 4.0, January 1998 (http://developer.netscape.com/docs/manuals/communicator/plugin/index.htm)
Création de fontes en typographie numérique, Jacques André, IRISA + IFSIC 1993

Typographie générale:

Gravure haute fidélité; Martine Boussel
Music Printing and Publishing
Nouveau manuel complet de Typographie; A. Frey, éd. Léonce Laget 1979

Typographie numérique:

Ligatures & informatique; Jacques André, Irisa/Inria de Rennes, in Cahiers GUTenberg n°22 de septembre 1995
L'écriture typographique: vers une prise de conscience; Ladislas Mandel (annuaires téléphoniques, Messidor, Galfa), conférence des Rencontres Internationales de Lure d'août 1988
Dynamic optical scaling and variable-sized characters; Jacques André (Irisa/Inria) et Irène Vatton (Cnrs/Inria) in Electronic Publishing 7(4), pp231-250, december 1994
Automatic generation of script font ligatures based on curve smoothness optimisation; Michael Kokula (Fraunhaufer Institute for Computer Graphics, Darmstadt) in Electronic
Publishing 7(4), pp217-229, december 1994
Random fonts for the simulation of handwrinting; Luc Devroye and Michael McDougall (School of Computer Science, McGill University), in Electronic Publishing 8(4), pp281-294, december 1995
Additing Fonts to the Java Runtime; Unicode Font Support in JDK 1.1; Sun Microsystems, Inc. 1997
Manuel de référence du langage PostScript, Adobe Systems Incorporated, 2e édition, éditions Addison-Wesley
The LaTeX Companion 1994
The LaTeX Graphics Companion 1997

Notation musicale informatisée:

NIFF (Notation Interchange File Format):

       NIFF Technical Coordinator; Cindy Grande, Grande Software, Inc., August 31, 1995
       The Development of the Notation Interchange File Format; Cindy Grande and Alan Belkin in CMJ 20:4, pp 33-43, Winter 1996
       NIFF Documentation
       NIFF SDK User's Guide; Tim Butler & Cindy Grande, 1996
       NIFF.h; 11 nov 1995
       NIFF listing1
       NIFF listing2

CMN (Common Music Notation):

Stella: Persitent Score Representation and Score Editing in Common Music; CMJ 17:4, pp38-50, Winter 1993
Common Music Notation

SMDL (Standard Music Description Language):

SMDL Specifications, ISO 1992?
A Brief Discussion of SMDL; Steph R. Mounce

Comparaison de logiciels:

       Comparison of features between Igor and some other notation programs; 1996
       List of known music notation programs; Dennis O'Neill MIT 1995
       The Acquisition, Representation and Reconstriction of Printed Music by Computer: A Review
       On the Standardisation of Musical Editing Systems; Laurie Spiegel in CMJ 8:3 of Winter 1984. Bibliographie IHM (Interfaces Hommes-Machines) 2000

Représentation musicale numérique:

Analyse des standards de notation musicale en vue de leur utilisation pour la transcription de la musique en Braille et l'étude d'une base de données musicales, thèse de doctorat de Didier Langolff à l'université Paul Sabatier de Toulouse, 2000
Musique & Notations, Musique en scène, Lyon 1997
Restitution de la place du texte dans les éditions musicales de la Renaissance (1520-1580): théorie et usage, maîtrise de musicologie de Valérie Otéro, Centre d'Etudes Supérieures de la Renaissance, 1999
A programmer's environnement for Music Analysis, Donncha Sean O Maidin, University of Limerick, 1995
recueil d'articles:

Using Music Corpora to verify Hypotheses; Donncha O Maidin.
Towards a Standard Independent Score Processor; John Morris.
Developpement of Novel Multimedia Browser Interface Mechanisms - the first prototype; Mickael Fernstrom.
A programmer's Environment for Music Analysis; Donncha O Maidin. (http://boethius.music.ucsb.edu - This server is the site for the Society for Music Theory and music at UC Santa Barbara. - http://www.societymusictheory.org/mto/docs/ - A Journal of Criticism, Commentary, Research, and Scholarship)

Music Representation and Scoring 3; CMJ 18:1, Spring 1994:

Music Notation Software and Intelligence; Donald Byrd
Threader: A Computer Interace for the Graphic Entry, Encoding, and Analysis of Musical Scores; John Wm Schaffer
Macintosh Notation Software: Present and Future; Alan Belkin

Compilation d'articles faite par un thésard de Gérarg Assayag sur les réprésentations musicales en XML:

MCML - Music Contents Markup Language; J. Schimmelpfennig & F. Kurth, University of Bonn
Content based navigation in digital music files, links, query results.
XML4MIR: Extensible Markup Language for Music Information Retrieval; Perry Roland, University of Virginia, Digital Library Reseach Group

The Computational Score, Languages and Programs for Music Encoding and Processing; Francesco Giomi
Computer Music-Notation Software; Dr Jody Nagel, March 1997
Digital Notation Representation an Online Retrieval of Musical Information: A Discussion of Current Options and Practices; Dr Elizabeth Hinkle-Turner, Florida International University 1998

Développements particuliers:

Musical Notation Markup Language (MNML); Internet Research and Development Unit (IRDU), nov 1995
Syntax Specification for the MNML format to be used for Internet music transfert and music archiving (version 1.3); IRDU 1996
Enigma Entry Pool: File Format Publication; 2/8/96
The design of a Pen-Based Music Notation System; CNMAT August 8, 1995 (http://www.cnmat.berkeley.edu/ - Center for New Music and Audio Technologies)
The Calliope Music Notation Editor; (http://www.cl.cam.ac.uk/~wfc/calliope-further.html - NeXT wysiwyg)
A Toolbox for Music Notation; Computer Printing, Storage, and Transfert of Musical Scores; Gérard Assayag & Dan Timis, IRCAM
ABC2MTEX, An easy way of transcribing folk and traditional music; Chris Walshaw, University of Greenwich, january 1997
Bringing Music to the Web; Jacco van Ossenbrugen (http://www.cwi.nl/~jrvosse/) & Anton Eliens (http://www.cs.vu.nl/~eliens/)
Diffusion de documents électroniques: De LaTeX à HTML, WWW et Acrobat; Cahiers GUTenber n°19 de janvier 1995:

Introduction Pratique à SGML; Michel Goossens (CERN Genève)
L'édition structurée et le World-Wide Web; Vincent Quint (Inria) et Irène Vatton (CNRS);
Ecrire de la musique en TEX; Daniel Taupin (taupin@lps.u-psud.fr)

Sites internet:

XML & Co:

Extensible Markup Language (XML):
http://www.w3.org/XML/
The XML Cover Pages:
http://www.oasis-open.org/cover/xml.html
A comprehensive online reference work for the Extensible Markup Language (XML):
http://xml.coverpages.org/
A consultancy specializing in systems for document and data exchange:
http://www.megginson.com/
Amaya:
http://www.w3.org/Amaya/
The MusiXML DTD :
http://www.s-line.de/homepages/gerd_castan/compmus/MusiXML.DTD
Recordare MusicXML:
http://www.musicxml.org/
Common music notation and Computers:
http://www.s-line.de/homepages/gerd_castan/compmus/index_e.html
X3C XML Schema:
http://www.w3.org/TR/xmlschema-0/
Unicode:
http://www.unicode.org/unicode/reports/tr27/

Java & Co:

Sun:
http://www.javasoft.com/
Java Technology & XML:
http://www.javasoft.com/xml/
Cours sur Java de l'ENST:
http://www.inf.enst.fr/~charon/coursJava/
Deux cafés, l'addition ! - Mémoire de fin d'études sur Java, par Jérôme Avrillon et Erik Dasque.
http://www.multimania.com/edasque/cafe_intro.html
Gamelan, site pour développeurs java:
http://softwaredev.earthweb.com/java
Welcome to earthweb-developer-1-text!
JavaWorld, journal hebdomadaire:
http://www.javaworld.com/
Apache XML Project:
http://xml.apache.org/
Xerces - XML parsers in Java, C++ (with Perl and COM bindings):
http://xml.apache.org/xerces-j/index.html
Xalan - XSLT stylesheet processors, in Java and C++ :
http://xml.apache.org/xalan/index.html
Batik - A Java based toolkit for Scalable Vector Graphics (SVG)
http://xml.apache.org/batik/index.html
XML4J - Parser d'IBM:
http://www.alphaworks.ibm.com/formula/xml
The XML Parser for Java Version 3.1.1 Release (XML4J-3_1_1)
XML programming styles, interfaces and products:
http://www.xml.com/programming/

SVG & Co:

SVG:
http://www.w3.org/Graphics/SVG
SVG Resources:
http://wdvl.internet.com/Authoring/Languages/XML/SVG/
Adobe's SVG:
http://www.adobe.com/svg/
SVG Adobe's Tutorial:
http://www.adobe.com/svg/basics/getstarted.html
Java Image Coding:
http://www.geocities.com/marcoschmidt.geo/java-image-coding.html
Transforming XML into SVG:
http://www-106.ibm.com/developerworks/education/transforming-xml/xmltosvg/index.html
Doug Tidwell: Cyber Evangelist, developerWorks XML Team
svg2pdf:
http://www.digapp.com/newpages/svg2pdf.html
SVG2PDF will run on MacOS, Windows 95/98/2000 and NT, it will convert an SVG document into a PDF document that can then be viewed by anyone using Adobe Acrobat or similar products.

Abonnements à des listes de discussion:

You have been added to xmlsoftware@listbot.com.

You have been added to our mailing list info@recordare.com.

XSL-list:
http://www.mulberrytech.com/

Acknowledgment: I have added the address
barkati@edite-de-paris.com.fr
to the xerces-j-user mailing list.

Acknowledgment: I have added the address
barkati@edite-de-paris.com.fr
to the batik-users mailing list.

Acknowledgment: I have added the address
barkati@edite-de-paris.com.fr
to the xalan-dev mailing list.

Acknowledgment: I have added the address
barkati@edite-de-paris.com.fr
to the announcements mailing list.

Annexes

Ci-joint:

un tableau synoptique du modèle de documents utilisé par DOM;
les nouveaux symboles musicaux d'Unicode;
le code source des programmes et fichiers suivants :

idealOut.svg, un fichier SVG saisi manuellement afin de tester les appels graphiques et de définir un objectif syntaxique correct
MusicXML2SVG.java, un programme qui utilise la librairie Xalan d'Apache pour transformer un document XML en un autre selon les règles indiquées par une feuille de style XSLT,
mutshortshort.xml, une partition de Schubert décrite en XML d'après les DTD MusicXML et tronquée par deux fois,
musicxml2svg05.xsl, une feuille de style XSLT qui contient les règles de transformation XML,
et enfin out.svg, le fichier SVG produit par le processeur XSLT.

Modèle de document utilisé par le DOM:

Noeud	Noeuds fils possibles
Document	Element (1), ProcessingInstuction, Comment, DocumentType
DocumentFragment	Element, ProcessingInstuction, Comment, Text, CDATASection, EntityReference
DocumentType	Notation, Entity
Entity	Element, ProcessingInstuction, Comment, Text, CDATASection, EntityReference
Element	Element, ProcessingInstuction, Comment, Text, CDATASection, EntityReference
Attribute	Text, EntityReference
ProcessingInstruction	-
Comment	-
Text	-
CDATASection	-
EntityReference	-
Notation	-

Nouveaux symboles musicaux d'Unicode:

12.10 Byzantine Musical Symbols (new section)

Byzantine Musical Symbols: U+1D000-U+1D0FF

Byzantine musical notation first appeared in the seventh or eighth century CE, developing more fully by the tenth century. Byzantine Musical Symbols are chiefly used to write the religious music and hymns of the the Christian Orthodox Church, though folk music manuscripts are also known. In 1881, the Orthodox Patriarchy Musical Committee redefined some of the signs and established the New Analytical Byzantine Musical Notation System, which is in use today. About 95% of the more than 7000 musical manuscripts using this system are in Greek. Other manuscripts are in Russian, Bulgarian, Romanian, and Arabic.

Processing. Computer representation of Byzantine Musical Symbols is quite recent, although typographic publication of religious music books began in 1820. Two kinds of applications have been developed: applications to enable musicians to write the books they use, and applications which compare or convert this musical notation system to the standard Western system. (See Musical Symbols, U+1D100..U+1D1FF.)

Byzantine Musical Symbols are divided into fifteen classes according to function. Characters interact with one another in the horizontal and vertical dimension. There are three horizontal "stripes" in which various classes generally appear, and rules as to how other characters interact within them. These rules are still being specified, and at present the plain-text manipulation of Byzantine musical symbols, like that of Western musical symbols, is outside the scope of the Unicode Standard.

12.11 Musical Symbols (new section)

Musical Symbols: U+1D100-U+1D1FF

The Musical Symbols encoded in the Unicode Standard are intended to cover basic Western musical notation and its antecedents: mensural notation, and plainsong (or Gregorian) notation. The most comprehensive coded language in regular use for representing sound is the common musical notation (CMN) of the Western world. Western musical notation is a system of symbols that is relatively, but not completely, self-consistent and relatively stable but still, like music itself, evolving. It is an open-ended system that has survived over time partly because of its flexibility and extensibility. In the Unicode Standard, Musical Symbols have been drawn primarily from CMN. Commonly recognized additions to the CMN repertoire, such as quarter-tone accidentals, cluster noteheads, and shape-note noteheads have also been included.

Graphical score elements are not included in the Musical Symbols block. These are pictographs usually created for a specific repertoire (sometimes even a single piece). Characters which have some specialized meaning in music but are found in other character sets, are also not included. These include numbers for time signatures and figured basses, letters for section labels and Roman numeral harmonic analysis, etc.

Musical Symbols are used worldwide in a more-or-less standard manner by a very large group of users. The symbols frequently occur in running text and may be treated as simple spacing characters with no special properties, with a few exceptions. Musical symbols are used in contexts such as theoretical works, pedagogical texts, terminological dictionaries, bibliographic databases, thematic catalogues, and databases of musical data. The Musical Symbol characters are also intended to be used within higher-level protocols, such as music description languages and file formats for the representation of musical data and musical scores.

Because of the complexities of layout and of pitch representation in general, the encoding of musical pitch is intentionally outside the scope of the Unicode Standard. The Musical Symbol block provides a common set of elements for interchange and processing. Encoding of pitch, and layout of resulting musical structure, involves not only specifications for the vertical relationship between multiple notes simultaneously, but in multiple staves, between instrumental parts, and so forth. These musical features are expected to be handled entirely in higher-level protocols making use of the proposed graphical elements. Lack of pitch encoding is not a shortcoming, but is a necessary feature of the encoding.

Three characters, U+266D MUSIC FLAT SIGN, U+266E MUSIC NATURAL SIGN, and U+266F MUSIC SHARP SIGN, which occur frequently in music notation are encoded in the Miscellaneous Symbols block (U+2600..U+267F). However, four characters also encoded in that block are to be interpreted merely as dingbats or miscellaneous symbols, not as representing actual musical notes. These are:

U+2669 QUARTER NOTE
U+266A EIGHTH NOTE
U+266B BEAMED EIGHTH NOTES
U+266C BEAMED SIXTEENTH NOTES

The punctum, or Gregorian brevis, a square shape, is unified with the U+1D147 MUSICAL SYMBOL SQUARE NOTEHEAD BLACK. The Gregorian semi-brevis, a diamond or lozenge shape, is unified with U+1D1BA MUSICAL SYMBOL SEMIBREVIS BLACK. Thus, Gregorian notation, medieval notation, and modern notation require either separate fonts in practice, or need font features to differentiate subtly different shapes where required.

Processing. Most musical symbols can be thought of as simple spacing characters when used in-line within texts and examples, even though they behave in a more complex manner in full musical layout. Some characters are meant only to be combined with others to produce combined character sequences, representing musical notes and their particular articulations. Musical symbols can be input, processed, and displayed in a manner similar to mathematical symbols. When embedded in text, most of the symbols are simple spacing characters with no special properties. There are a few characters with format control functions which are described below.

Input Methods. Musical symbols can be entered via standard alphanumeric keyboard, piano keyboard or other device, or by a graphical method. Keyboard input of the musical symbols may make use of techniques similar to those used for Chinese, Japanese, and Korean. In addition, input methods utilizing pointing devices or piano keyboards could be developed similar to those in existing musical layout systems. For example, within a graphical user interface, the user could choose symbols from a palette-style menu.

Directionality. There are no known bidirectional implications for Musical Symbols. When combined with right-to-left texts, in Hebrew or Arabic for example, the music notation is still written left-to-right as usual. The words are divided into syllables and placed under or above the notes in the same fashion as for Latin scripts. The individual words or syllables corresponding to each note, however, are written in the dominant direction of the script.

Format Characters. Extensive ligature-like beams are used frequently in music notation between groups of notes having short values. The practice is widespread and very regular, and is amenable to algorithmic handling. The format characters U+1D173 MUSICAL SYMBOL BEGIN BEAM and U+1D174 MUSICAL SYMBOL END BEAM can be used to indicate the extents of beam groupings. In some exceptional cases, beams are left-unclosed on one end. This can be indicated with a U+1D159 MUSICAL SYMBOL NULL NOTEHEAD character if no stem is to appear at the end of the beam.

Similarly, format characters have been provided for other connecting structures. The characters U+1D175 MUSICAL SYMBOL BEGIN TIE, U+1D176 MUSICAL SYMBOL END TIE, U+1D177 MUSICAL SYMBOL BEGIN SLUR, U+1D178 MUSICAL SYMBOL END SLUR, U+1D179 MUSICAL SYMBOL BEGIN PHRASE, and U+1D17A MUSICAL SYMBOL END PHRASE indicate the extent of these features. Like beaming, these features are easily handled in an algorithmic fashion.

These pairs of characters modify the layout and grouping of notes and phrases in full music notation. When musical examples are written or rendered in plain text without special software, the start/end format characters may be rendered as brackets or left uninterpreted. To the extent possible, more sophisticated in-line software may interpret them in their actual format control capacity, rendering slurs, beams, and so forth as appropriate.

Precomposed Note Characters. For maximum flexibility, the character set includes both precomposed note values and primitives from which complete notes may be constructed. The precomposed versions are provided mainly for convenience. However, if any normalization form is applied, the characters will be decomposed. For further information, see Unicode Standard Annex #15, Unicode Normalization Forms. The canonical equivalents for these characters are given in the Unicode Character Database, and illustrated in the table below. In this table and subsequent examples, the names of the Unicode Musical Symbol characters are abbreviated by omitting the phrases MUSICAL SYMBOL or MUSICAL SYMBOL ORNAMENT.

Precomposed note Equivalent to

1D15E HALF NOTE 1D157 VOID NOTEHEAD + 1D165 COMBINING STEM

1D15F QUARTER NOTE 1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM

1D160 EIGHTH NOTE 1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D16E COMBINING FLAG-1

1D161 SIXTEENTH NOTE 1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D16F COMBINING FLAG-2

1D162 THIRTY-SECOND NOTE 1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D170 COMBINING FLAG-3

1D163 SIXTY-FOURTH NOTE 1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D171 COMBINING FLAG-4

1D164 ONE HUNDRED TWENTY-EIGHTH NOTE 1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D172 COMBINING FLAG-5

Alternative Noteheads. More complex notes built up from alternative noteheads, stems, flags, and articulation symbols are necessary for complete implementations and complex scores. Examples of their use include American shape-note and modern percussion notations. For example:

1D147 SQUARE NOTEHEAD BLACK + 1D165 COMBINING STEM

1D143 X NOTEHEAD + 1D165 COMBINING STEM

Augmentation Dots and Articulation Symbols. Augmentation dots and articulation symbols may be appended to either the precomposed or built-up notes. In addition, augmentation dots and articulation symbols may be repeated as necessary to build a complete note symbol. Examples of the use of augmentation dots are shown in the table below.

1D160 EIGHTH NOTE + 1D16D COMBINING AUGMENTATION DOT 1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D16E COMBINING FLAG-1 + 1D16D COMBINING AUGMENTATION DOT

1D15F QUARTER NOTE + 1D17C COMBINING STACCATO 1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D17C COMBINING STACCATO

1D160 EIGHTH NOTE + 1D16D COMBINING AUGMENTATION DOT + 1D16D COMBINING AUGMENTATION DOT + 1D17B COMBINING ACCENT 1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D16E COMBINING FLAG-1 + 1D17B COMBINING ACCENT + 1D16D COMBINING AUGMENTATION DOT + 1D16D COMBINING AUGMENTATION DOT

Ornamentation Chart. Included below is a list of common eighteenth-century ornaments and the combining sequences of characters from which they can be generated.

1D19C STROKE-2 + 1D19D STROKE-3

1D19C STROKE-2 + 1D1A0 STROKE-6 + 1D19D STROKE-3

1D1A0 STROKE-6 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D19D STROKE-3

1D19C STROKE-2 + 1D19C STROKE-2 + 1D1A0 STROKE-6 + 1D19D STROKE-3

1D19C STROKE-2 + 1D19C STROKE-2 + 1D1A3 STROKE-9

1D1A1 STROKE-7 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D19D STROKE-3

1D1A2 STROKE-8 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D19D STROKE-3

1D19C STROKE-2 + 1D19C STROKE-2 + 1D19D STROKE-3 + 1D19F STROKE-5

1D1A1 STROKE-7 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D1A0 STROKE-6 + 1D19D STROKE-3

1D1A1 STROKE-7 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D19D STROKE-3 + 1D19F STROKE-5

1D1A2 STROKE-8 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D1A0 STROKE-6 + 1D19D STROKE-3

1D19B STROKE-1 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D19D STROKE-3

1D19B STROKE-1 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D19D STROKE-3 + 1D19E STROKE-4

1D19C STROKE-2 + 1D19D STROKE-3 + 1D19E STROKE-4

Copyright Â© 2001 Unicode, Inc. All Rights Reserved. The Unicode Consortium makes no expressed or implied warranty of any kind, and assumes no liability for errors or omissions. No liability is assumed for incidental and consequential damages in connection with or arising out of the use of the information or programs contained or accompanying this technical report.

Unicode and the Unicode logo are trademarks of Unicode, Inc., and are registered in some jurisdictions.

idealOut.svg:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20001102//EN"
"http://www.w3.org/TR/2000/CR-SVG-20001102/DTD/svg-20001102.dtd">
<svg width="800" height="300">
<defs>
    <g id="Staff1" style="stroke-width:1; stroke:black">
      <line x1="20" x2="780" y1="158" y2="158"></line>
      <line x1="20" x2="780" y1="172" y2="172"></line>
      <line x1="20" x2="780" y1="186" y2="186"></line>
      <line x1="20" x2="780" y1="200" y2="200"></line>
      <line x1="20" x2="780" y1="214" y2="214"></line>
    </g>
</defs>
<text x="400" y="62" style="font-family:Times Roman; font-size:42; text-anchor:middle">Mut</text>
<text x="780" y="100" style="font-family:Times Roman; font-size:24; text-anchor:end">Franz Schubert</text>
<use xlink:href="#Staff1"/>
    <g transform="translate(30,142)">
      <use xlink:href="MusicGlyphs.svg#GKEY"/>
    </g>
</svg>

MusicXML2SVG.java:

/*
MusicXML2SVG.java transforme un fichier MusicXML en un fichier SVG
en appliquant simplement une feuille de style XSLT.
Karim Barkati, Paris, Juin 2001.
Ce code utilise celui du fichier d'exemple SimpleTransform.java d'Apache.
*/

import util.Arguments;
import java.io.OutputStreamWriter;
import java.io.PrintWriter;
import java.io.UnsupportedEncodingException;

import org.xml.sax.SAXException;
import org.apache.xalan.xslt.XSLTProcessorFactory;
import org.apache.xalan.xslt.XSLTInputSource;
import org.apache.xalan.xslt.XSLTResultTarget;
import org.apache.xalan.xslt.XSLTProcessor;

/**
* Simple sample code to show how to run the XSL processor
* from the API.
*/
public class MusicXML2SVG
{
/** Default file names. */
private static final String
DEFAULT_IN_NAME = "mutshortshort.xml",
DEFAULT_XSL_NAME = "musicxml2svg05.xsl",
DEFAULT_OUT_NAME = "out.svg";

    public static void main(String[] argv)
    throws java.io.IOException,
           java.net.MalformedURLException,
           org.xml.sax.SAXException
{
        Arguments argopt = new Arguments();
        argopt.setUsage( new String[] {
                             "usage: java MusicXML2SVG (options) uri ...",
                             "",
                             "options:",
                             " -i name Specify MusicXML file by name.",
                             " -x name Specify stylesheet by name.",
                             " -o name Specify SVG output file by name.",
                             " -h       This help screen."} );

        // vars
        String inName = DEFAULT_IN_NAME;
        String xslName = DEFAULT_XSL_NAME;
        String outName = DEFAULT_OUT_NAME;

argopt.parseArgumentTokens(argv , new char[] { 'i', 'x', 'o' } );

        int   c;
        String arg = null;
        //while ( ( arg = argopt.getlistFiles() ) != null ) {
//System.out.println( "arg = " + arg );
outer:
            while ( (c = argopt.getArguments()) != -1 ){
                switch (c) {
                case 'i':
                    //System.out.println("in");
                    inName = argopt.getStringParameter();
                    //System.out.println( "inName = " + inName );
                    break;
                case 'x':
                    //System.out.println("xsl");
                    xslName = argopt.getStringParameter();
                    //System.out.println( "xslName = " + xslName );
                    break;
                case 'o':
                    //System.out.println("out");
                    outName = argopt.getStringParameter();
                    //System.out.println( "outName = " + outName );
                    break;
                case '?':
                case 'h':
                case '-':
                    argopt.printUsage();
                    System.exit(1);
                    break;
                case -1:
                    System.out.println( "-1" );
                    break outer;
                default:

                    break;
                }
            }
     //}
     if ((outName == null) && (inName != null))
{
      //outName = inName.replace( inName.lastIndexOf('.'), inName.lastIndexOf('.') + 4, ".svg");
}
     System.out.println( "inName = " + inName );
     System.out.println( "xslName = " + xslName );
     System.out.println( "outName = " + outName );

    // Have the XSLTProcessorFactory obtain a interface to a
    // new XSLTProcessor object.
    XSLTProcessor processor = XSLTProcessorFactory.getProcessor();

    // Have the XSLTProcessor processor object transform "birds.xml" to
    // System.out, using the XSLT instructions found in "birds.xsl".
    processor.process(new XSLTInputSource(inName),
                      new XSLTInputSource(xslName),
                      new XSLTResultTarget(outName));
   System.out.println("************* The result is in " + outName + " *************");
}
}

mutshortshort.xml:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE score-partwise PUBLIC
"-//Recordare//DTD MusicXML Partwise//EN"
"http://www.musicxml.org/dtds/partwise.dtd">
<score-partwise>
<work>
<work-number>D. 911</work-number>
<work-title>Winterreise</work-title>
</work>
<movement-number>22</movement-number>
<movement-title>Mut</movement-title>
<identification>
<creator type="composer">Franz Schubert</creator>
<creator type="poet">Wilhelm MÃ¼ller</creator>
<rights>Electronic edition Copyright Â© 2001 Recordare. All rights reserved.</rights>
<encoding>
   <encoding-date>2001-01-12</encoding-date>
   <encoder>Michael Good</encoder>
   <software>Finale 2001c for Windows</software>
   <encoding-description>MusicXML 0.1b example</encoding-description>
</encoding>
<source>Based on Dover reprint of Breitkopf & HÃ¤rtel edition of 1895. Original A-minor version; later transposed to G minor.</source>
</identification>
<part-list>
<score-part id="P1">
   <part-name>Singstimme.</part-name>
</score-part>
</part-list>
<part id="P1">
<measure number="1">
   <attributes>
    <divisions>4</divisions>
    <key>
     <fifths>0</fifths>
     <mode>minor</mode>
    </key>
    <time>
     <beats>2</beats>
     <beat-type>4</beat-type>
    </time>
    <clef>
     <sign>G</sign>
     <line>2</line>
    </clef>
   </attributes>
   <direction>
    <direction-type>
     <words xml:lang="de">Ziemlich geschwind, krÃ¤ftig</words>
    </direction-type>
   </direction>
   <note>
    <rest/>
    <duration>8</duration>
    <type>half</type>
   </note>
   <barline>
    <bar-style>light-heavy</bar-style>
   </barline>
</measure>
</part>
</score-partwise>

musicxml2svg.xsl:

<?xml version="1.0"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xlink="http://www.w3.org/1999/xlink">
<xsl:output method="xml"
    indent="yes"
    encoding="UTF-8"
    omit-xml-declaration="no"
    standalone="no"
    doctype-public="-//W3C//DTD SVG 20001102//EN"
    doctype-system="http://www.w3.org/TR/2000/CR-SVG-20001102/DTD/svg-20001102.dtd">
</xsl:output>

<xsl:variable name="PAGE_WIDTH" select="500"></xsl:variable>
<xsl:variable name="PAGE_HEIGHT" select="300"></xsl:variable>
<xsl:variable name="TOP_MARGIN" select="20"></xsl:variable>
<xsl:variable name="BOTTOM_MARGIN" select="20"></xsl:variable>
<xsl:variable name="LEFT_MARGIN" select="20"></xsl:variable>
<xsl:variable name="RIGHT_MARGIN" select="20"></xsl:variable>
<xsl:variable name="HEADER_SIZE" select="150"></xsl:variable>
<xsl:variable name="STAFF_LINE_SPACE" select="14"></xsl:variable>
<xsl:variable name="GKEY_BASELINE" select="58"></xsl:variable>

<xsl:template match="/">
    <xsl:element name="svg">
      <xsl:attribute name="width">
<xsl:value-of select="$PAGE_WIDTH"></xsl:value-of>
      </xsl:attribute>
      <xsl:attribute name="height">
<xsl:value-of select="$PAGE_HEIGHT"></xsl:value-of>
      </xsl:attribute>
      <xsl:apply-templates select="./score-partwise"></xsl:apply-templates>
      <xsl:apply-templates select="./score-timewise"></xsl:apply-templates>
    </xsl:element>
</xsl:template>

<xsl:template match="score-timewise">
</xsl:template>

<xsl:template match="score-partwise">

<xsl:apply-templates select="work"></xsl:apply-templates>
    <xsl:apply-templates select="movement-number"></xsl:apply-templates>
    <xsl:apply-templates select="movement-title"></xsl:apply-templates>
    <xsl:apply-templates select="identification"></xsl:apply-templates>
    <xsl:apply-templates select="part-list">
   <xsl:with-param name="y_offset">
     <xsl:value-of select="$TOP_MARGIN + $HEADER_SIZE">
     </xsl:value-of>
   </xsl:with-param>
    </xsl:apply-templates>

<xsl:for-each select="part/measure">

<xsl:element name="use">
<xsl:attribute name="xlink:href" namespace="http://www.w3.org/1999/xlink">
   <xsl:text>#Staff1</xsl:text>
</xsl:attribute>
      </xsl:element>

<xsl:apply-templates select="attributes/clef">
<xsl:with-param name="x_offset">
   <xsl:value-of select="$LEFT_MARGIN + 10">
   </xsl:value-of>
</xsl:with-param>
<xsl:with-param name="y_offset">
   
   <xsl:value-of select="$TOP_MARGIN + $HEADER_SIZE + (3 * $STAFF_LINE_SPACE) - $GKEY_BASELINE">
   </xsl:value-of>
</xsl:with-param>
      </xsl:apply-templates>

</xsl:for-each>
</xsl:template>

<xsl:template match="movement-title">
    <xsl:variable name="title" select="."></xsl:variable>
    <xsl:element name="text">
      <xsl:attribute name="x">
<xsl:value-of select="$PAGE_WIDTH * 0.5"></xsl:value-of>
      </xsl:attribute>
      <xsl:attribute name="y">
<xsl:value-of select="$TOP_MARGIN + 42"></xsl:value-of>
      </xsl:attribute>
      <xsl:attribute name="style">
<xsl:value-of select="'font-family:Times Roman; font-size:42; text-anchor:middle'"></xsl:value-of>
      </xsl:attribute>
      <xsl:value-of select="$title"></xsl:value-of>
    </xsl:element>
</xsl:template>

<xsl:template match="identification">
<xsl:apply-templates select="creator"></xsl:apply-templates>
</xsl:template>

<xsl:template match="creator">
    <xsl:if test="@type='composer'">
      <xsl:variable name="composer" select="."></xsl:variable>
      <xsl:element name="text">
<xsl:attribute name="x">
   <xsl:value-of select="$PAGE_WIDTH - $LEFT_MARGIN"></xsl:value-of>
</xsl:attribute>
<xsl:attribute name="y">
   <xsl:value-of select="4 * $TOP_MARGIN + 24"></xsl:value-of>
</xsl:attribute>
<xsl:attribute name="style">
   <xsl:value-of select="'font-family:Times Roman; font-size:24; text-anchor:end'"></xsl:value-of>
</xsl:attribute>
<xsl:value-of select="$composer"></xsl:value-of>
      </xsl:element>
    </xsl:if>
</xsl:template>

<xsl:template match="work">

</xsl:template>

<xsl:template match="movement-number">
    
</xsl:template>

<xsl:template match="part-list">

<xsl:element name="defs">

<xsl:for-each select="score-part">

<xsl:element name="g">

   <xsl:attribute name="id">
     <xsl:value-of select="'Staff1'"></xsl:value-of>
   </xsl:attribute>
   <xsl:attribute name="style">
     <xsl:value-of select="'stroke-width:1; stroke:black'"></xsl:value-of>
   </xsl:attribute>

   <xsl:element name="line">
     <xsl:attribute name="x1">
       <xsl:value-of select="$LEFT_MARGIN"></xsl:value-of>
     </xsl:attribute>
     <xsl:attribute name="x2">
       <xsl:value-of select="$PAGE_WIDTH - $RIGHT_MARGIN"></xsl:value-of>
     </xsl:attribute>
     <xsl:attribute name="y1">
       <xsl:value-of select="$y_offset"></xsl:value-of>
     </xsl:attribute>
     <xsl:attribute name="y2">
       <xsl:value-of select="$y_offset"></xsl:value-of>
     </xsl:attribute>
   </xsl:element>

   <xsl:element name="line">
     <xsl:attribute name="x1">
       <xsl:value-of select="$LEFT_MARGIN"></xsl:value-of>
     </xsl:attribute>
     <xsl:attribute name="x2">
       <xsl:value-of select="$PAGE_WIDTH - $RIGHT_MARGIN"></xsl:value-of>
     </xsl:attribute>
     <xsl:attribute name="y1">
       <xsl:value-of select="$y_offset + $STAFF_LINE_SPACE"></xsl:value-of>
     </xsl:attribute>
     <xsl:attribute name="y2">
       <xsl:value-of select="$y_offset + $STAFF_LINE_SPACE"></xsl:value-of>
     </xsl:attribute>
   </xsl:element>

   <xsl:element name="line">
     <xsl:attribute name="x1">
       <xsl:value-of select="$LEFT_MARGIN"></xsl:value-of>
     </xsl:attribute>
     <xsl:attribute name="x2">
       <xsl:value-of select="$PAGE_WIDTH - $RIGHT_MARGIN"></xsl:value-of>
     </xsl:attribute>
     <xsl:attribute name="y1">
       <xsl:value-of select="$y_offset + (2 * $STAFF_LINE_SPACE)"></xsl:value-of>
     </xsl:attribute>
     <xsl:attribute name="y2">
       <xsl:value-of select="$y_offset + (2 * $STAFF_LINE_SPACE)"></xsl:value-of>
     </xsl:attribute>
   </xsl:element>

   <xsl:element name="line">
     <xsl:attribute name="x1">
       <xsl:value-of select="$LEFT_MARGIN"></xsl:value-of>
     </xsl:attribute>
     <xsl:attribute name="x2">
       <xsl:value-of select="$PAGE_WIDTH - $RIGHT_MARGIN"></xsl:value-of>
     </xsl:attribute>
     <xsl:attribute name="y1">
       <xsl:value-of select="$y_offset + (3 * $STAFF_LINE_SPACE)"></xsl:value-of>
     </xsl:attribute>
     <xsl:attribute name="y2">
       <xsl:value-of select="$y_offset + (3 * $STAFF_LINE_SPACE)"></xsl:value-of>
     </xsl:attribute>
   </xsl:element>

   <xsl:element name="line">
     <xsl:attribute name="x1">
       <xsl:value-of select="$LEFT_MARGIN"></xsl:value-of>
     </xsl:attribute>
     <xsl:attribute name="x2">
       <xsl:value-of select="$PAGE_WIDTH - $RIGHT_MARGIN"></xsl:value-of>
     </xsl:attribute>
     <xsl:attribute name="y1">
       <xsl:value-of select="$y_offset + (4 * $STAFF_LINE_SPACE)"></xsl:value-of>
     </xsl:attribute>
     <xsl:attribute name="y2">
       <xsl:value-of select="$y_offset + (4 * $STAFF_LINE_SPACE)"></xsl:value-of>
     </xsl:attribute>
   </xsl:element>

</xsl:element>

</xsl:for-each>
    </xsl:element>
    
</xsl:template>

<xsl:template match="clef">
    
    <xsl:element name="g">
      <xsl:attribute name="transform">
<xsl:text>translate(</xsl:text>
<xsl:value-of select="$x_offset"></xsl:value-of>
<xsl:text>,</xsl:text>
<xsl:value-of select="$y_offset"></xsl:value-of>
<xsl:text>)</xsl:text>
      </xsl:attribute>

      <xsl:element name="use">
<xsl:attribute name="xlink:href" namespace="http://www.w3.org/1999/xlink">
   <xsl:text>MusicGlyphs.svg#GKEY</xsl:text>
</xsl:attribute>
      </xsl:element>
    </xsl:element>
</xsl:template>

</xsl:stylesheet>

out.svg:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20001102//EN" "http://www.w3.org/TR/2000/CR-SVG-20001102/DTD/svg-20001102.dtd">
<svg xmlns:xlink="http://www.w3.org/1999/xlink" width="500" height="300">
    <text x="250" y="62" style="font-family:Times Roman; font-size:42; text-anchor:middle">Mut</text>
    <text x="480" y="104" style="font-family:Times Roman; font-size:24; text-anchor:end">Franz Schubert</text>
    <defs>
        <g id="Staff1" style="stroke-width:1; stroke:black">
            <line x1="20" x2="480" y1="170" y2="170"/>
            <line x1="20" x2="480" y1="184" y2="184"/>
            <line x1="20" x2="480" y1="198" y2="198"/>
            <line x1="20" x2="480" y1="212" y2="212"/>
            <line x1="20" x2="480" y1="226" y2="226"/>
        </g>
    </defs>
    <use xlink:href="#Staff1"/>
    <g transform="translate(30,154)">
        <use xlink:href="MusicGlyphs.svg#GKEY"/>
    </g>
</svg>

	Precomposed note	Equivalent to
	1D15E HALF NOTE	1D157 VOID NOTEHEAD + 1D165 COMBINING STEM
	1D15F QUARTER NOTE	1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM
	1D160 EIGHTH NOTE	1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D16E COMBINING FLAG-1
	1D161 SIXTEENTH NOTE	1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D16F COMBINING FLAG-2
	1D162 THIRTY-SECOND NOTE	1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D170 COMBINING FLAG-3
	1D163 SIXTY-FOURTH NOTE	1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D171 COMBINING FLAG-4
	1D164 ONE HUNDRED TWENTY-EIGHTH NOTE	1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D172 COMBINING FLAG-5

	1D147 SQUARE NOTEHEAD BLACK + 1D165 COMBINING STEM
	1D143 X NOTEHEAD + 1D165 COMBINING STEM

	1D160 EIGHTH NOTE + 1D16D COMBINING AUGMENTATION DOT	1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D16E COMBINING FLAG-1 + 1D16D COMBINING AUGMENTATION DOT
	1D15F QUARTER NOTE + 1D17C COMBINING STACCATO	1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D17C COMBINING STACCATO
	1D160 EIGHTH NOTE + 1D16D COMBINING AUGMENTATION DOT + 1D16D COMBINING AUGMENTATION DOT + 1D17B COMBINING ACCENT	1D158 NOTEHEAD BLACK + 1D165 COMBINING STEM + 1D16E COMBINING FLAG-1 + 1D17B COMBINING ACCENT + 1D16D COMBINING AUGMENTATION DOT + 1D16D COMBINING AUGMENTATION DOT

	1D19C STROKE-2 + 1D19D STROKE-3
	1D19C STROKE-2 + 1D1A0 STROKE-6 + 1D19D STROKE-3
	1D1A0 STROKE-6 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D19D STROKE-3
	1D19C STROKE-2 + 1D19C STROKE-2 + 1D1A0 STROKE-6 + 1D19D STROKE-3
	1D19C STROKE-2 + 1D19C STROKE-2 + 1D1A3 STROKE-9
	1D1A1 STROKE-7 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D19D STROKE-3
	1D1A2 STROKE-8 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D19D STROKE-3
	1D19C STROKE-2 + 1D19C STROKE-2 + 1D19D STROKE-3 + 1D19F STROKE-5
	1D1A1 STROKE-7 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D1A0 STROKE-6 + 1D19D STROKE-3
	1D1A1 STROKE-7 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D19D STROKE-3 + 1D19F STROKE-5
	1D1A2 STROKE-8 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D1A0 STROKE-6 + 1D19D STROKE-3
	1D19B STROKE-1 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D19D STROKE-3
	1D19B STROKE-1 + 1D19C STROKE-2 + 1D19C STROKE-2 + 1D19D STROKE-3 + 1D19E STROKE-4
	1D19C STROKE-2 + 1D19D STROKE-3 + 1D19E STROKE-4