L'import XML dans Harmony est donc réécrit en C, pour remplacer le script qui existait dans les versions précédentes. Jusqu'ici, nous avons principalement traité les informations du fichier XML permettant de jouer la partition correctement (clés, notes, altérations, etc). Cela nous permet déjà d'écouter directement le résultat de la reconnaissance du PDF. Nous attaquons maintenant les informations de pagination et de position des objets sur la page, avec les marges, position des systèmes et des portées, largeur des mesures, retours à la ligne, etc. Ce n'est pas toujours facile, car le format MusicXML contient beaucoup de redondances, de valeurs écrites plusieurs fois dans le fichier, ou dont la somme doit correspondre à un total également écrit. Mais voila, parfois les valeurs ne sont pas égales, ou la somme ne correspond pas à celle attendue. Le problème est alors de savoir que faire pour s'en sortir avec le moins de dégâts possibles Une fois cela fait, il restera à finir de prendre en compte les objets qui manquent encore, tels que les ornements, les textes libres et autres petits gadgets... |
|
|
by Olivier Guillion | | | |
|
Lorsque le nombre de systèmes permettant à chacun de s'exprimer augmente, on voit apparaître un nombre toujours plus grand de petits malins qui en profitent pour les pervertir et les rendre inutilisables. Ainsi, lorsque nous avons démarré ce blog, nous avons volontairement laissé la porte ouverte et la lumière allumée, nous disant que nous aurions peut-être de temps en temps à faire le ménage, mais que cela ne serait pas une trop lourde tâche. Monumentale erreur. Les événements nous ont amenés à mettre tout un tas de filtres et de protections diverses, que nous avons voulu invisibles pour l'utilisateur de bonne foi, mais qui nous permettraient d'éviter que l'espace réservé aux commentaires des utilisateurs ne se transforme rapidement en décharge à ciel ouvert. Voici donc un petit bilan édifiant de la collecte automatique des déchets des deux mois écoulés, qui me fait frémir en pensant que sans ces protections, il aurait fallu que nous fassions le tri sélectif à la main: - 3861 messages de spam ont été arrêtés avant qu'ils ne soient postés sur ce blog (non, pardon, 3863, le temps que j'écrive ces lignes) - Ces messages représentaient 2,44 Mo de texte Les gagnants sont : - Le mot "ringtone", présent 4925 fois - Le mot "finance", présent 1289 fois - Le mot "pharmacy", 1282 fois - Le mot "viagra", présent 1251 fois Et, pendant le même temps, d'autres robots-gardiens faisaient leur travail en silence : - 67468 e-mails étaient effacés avant même d'atteindre nos boîtes aux lettres, représentant un total de 1,1 Go - un autre filtre arrêtait 419 inscriptions de spammeurs sur notre forum de discussion, avant même qu'ils aient pu accéder à la page de rédaction d'un message - 183 personnes essayaient de trouver une faille dans notre point d'accès Internet - 15 personnes voyait leur accès à la totalité de notre site interdit, parce qu'ils essayaient de récupérer toutes les pages, en occupant la majeure partie de la bande passante du serveur J'aimerais connaître, dans le monde, la puissance de calcul nécessaire au fonctionnement de tous ces filtres, firewalls, anti-spam, antivirus, anti-spyware, etc. A mon avis, ce serait suffisant pour calculer toutes les données du SETI en quelques jours. Ils doivent bien se ficher de nous, les extra-terrestres qui nous observent... |
|
|
by Olivier Guillion | | |
| |
|
1990. Le succès de la "Vie du Lac" attira l'oeil d'un autre laboratoire d'EDF où des chercheurs travaillaient sur l'écologie du saumon. Il se rendirent compte que ce type de vulgarisation scientifique était un moyen original de montrer leur travaux sur les problèmes de remontée des saumons et obstacles artificiels. On nous demanda de concevoir un logiciel basé sur le même principe que la Vie du Lac.Toutes les informations scientifiques à faire passer étaient définies, mais pour le reste, nous avions carte blanche. Nous choisîmes de priviligier l'aspect ludique de la remontée du saumon, qui fut présentée comme une course aux obstacles contre la montre. Le logiciel sortit sur Atari ST, PC et Macintosh. Il fut décliné en plusieurs versions, dont une version courte, spécial stand, présentée lors d'une exposition à La Villette. Une version, plus spécifique, présentant le bassin Adour-Garonne, fut développée pour la Maison de l'Environnement de Toulouse. Comme "la vie du Lac", "Salmo l'aventure du saumon" fut un vrai succès. Il est dommage qu'il n'ait jamais été réactualisé pour profiter de la puissance de calcul des ordinateurs actuels. |
|
|
by Didier Guillion | | | |
|
En 1989, nous entrâmes dans la phase "Didacticiels" de notre histoire. Elle allait durer plusieurs années... Tout a débuté par un contact avec un chercheur du CNRS. Je revenais assez régulièrement dans les labos de l'Université pour faire un petit "coucou" et éventuellement dépanner un des Macintosh, puisque le service de maintenance de l'Université Paul Sabatier refusait d'y toucher. Jean-Marc T***, travaillait sur la modélisation de l'écologie des systèmes lacustres, en collaboration avec une chercheuse d'EDF, Marie-José S***. Ils avaient développé un programme en Fortran qui simulait, sur plusieurs années, l'évolution thermique d'un lac et ses conséquences sur le plancton. Apprenant que je travaillais dans les jeux vidéo, ils me demandèrent si je pensais possible d'adapter leur modèle sur un micro-ordinateur. Il faut dire que leur code tournait sur un Cray... Leur objectif était de créer un programme didactique expliquant au grand public, les bases de l'écosystème d'un lac. Le sujet était passionnant, c'était pour nous l'occasion de toucher un autre domaine que celui des jeux vidéo, tout en réinvestissant une bonne partie de nos codes et de notre savoir-faire dans le domaine de l'éducation. En un mois, nous pûmes leur fournir une maquette présentant les notions de phytoplancton, zooplancton, équilibre trophique, thermocline, etc, sous forme de pages interactives animées. La maquette, soumise à la Mission Environnement d'EDF fut acceptée et un contrat signé. Jean Marc et Marie-José travaillèrent dur pour simplifier leur modèle à l'extrème sans le rendre inexact. Et passer de la puissance de calcul d'un Cray a celle d'un Atari ST c'était dur ! La Vie du Lac fut édité par nos soins et proposée sur Atari ST et PC. La Mission Environnement guère convaincue de l'avenir du Macintosh, avait refusé cette version. Comme nous défendions le Macintosh, cette version sortit tout de même, mais à nos frais. Ce projet fut vraiment très intéressant : nous n'avions pas totalement carte blanche car "EDF et environnement" ont toujours été un sujet sensible mais un très (vraiment très) fort degré de liberté nous a permis de nous amuser. Ce premier logiciel didactique fut un vrai succès auprès du public et des écoles. Il ouvrit la voie à d'autres. |
|
|
by Didier Guillion | | | |
|
Petit retour sur l'OMNI de l'étape 48. En fait, je trouve quand même pas mal de partitions qui utilisent cette notation. J'ai donc décidé de le traiter comme une vraie altération, même s'il n'est pas possible de spécifier, en MusicXML que l'altération doit s'afficher à cette place. N'oublions pas que PDFToMusic est censé jouer la partition, et qu'une altération qui saute, ça s'entend ! L'algorithme a donc été adapté. A noter que cela ne perturbe pas (à priori) les altérations placées sur les mordants ou groupetto (Cf Kolo de S. Machefert) ou les altérations décalées sur les notes en accord. Dans mes recherches je n'ai pas trouvé d'altérations de ce type en dessous de la portée, cela peut-il exister ? Tout exemple est bienvenu... La semaine prochaine va se diviser en deux phases de travail, Olivier devrait avancer sur l'import MusicXML, de mon coté je vais reprendre les sources un par un pour les relire, vérifier les commentaires et les compléter. Cela semble souvent étrange, mais en programmation, il y a plus de lignes de commentaires que de lignes de code ! |
|
|
by Didier Guillion | | |
| |
|
La gestion des voix commence à fonctionner furieusement bien ! Cela nous permet d'explorer une très grande quantité de documents PDF. Le taux de réussite à 100% (pas une erreur par document) approche une bonne moitié des documents en notre possession. Pour la plupart des autres documents, les erreurs sont vraiment mineures, un coulé mal accroché, un staccato non vu, un tenuto en trop, un texte légèrement décalé, un pied de page pris pour une ligne de paroles, etc. Quelques documents résistent encore, mais c'est le dernier carré. Par contre, la progression est de plus en plus lente : toute modification des algorithmes ou de leur paramétrage nécessite de re-valider une plus grande quantité de fichiers. Certains documents ne pourrons pas être traités dans l'état actuel du projet : ce sont les fichiers PDF ne comportant qu'une image bitmap de la partition et non des informations vectorielles. Ils sont heureusement très rares. Ou encore, les documents utilisant une police textuelle non standard pour afficher des textes, il faudrait implémenter une reconnaissance de caractères non musicaux, ce qui reste néanmoins dans notre calendrier... La partie la plus incomplète reste l'import MusicXML dans Harmony/Melody. Ce sera l'étape de la semaine prochaine. Elle devra gérer toutes les additions au format MusicXML que nous avons été obligés de faire (images, textes libres, volume des instruments, etc). La première version Beta de PDFToMusic est toujours prévue pour Septembre et il est évident qu'une version Beta d'Harmony Assistant sera proposée simultanément. |
|
|
by Didier Guillion | | | |
|
Une question s'est posée : lorsque l'utilisateur intervient sur le document PDF pour apporter des corrections ou des modifications à la reconnaissance de PDFToMusic, que faire de ces modifications ? Une possibilité aurait été de considérer que les modifications étaient volatiles et non préservées lors de la fermeture du document. Ceci n'aurait pas porté préjudice au fonctionnement dans le cas de l'utilisation de PDFToMusic en tant que convertisseur de document PDF vers le MusicXML. Mais, lorsque PDFToMusic est utilisé comme visualiseur/interpréteur musical de documents PDF, l'utilisateur pouvait être amené à revenir souvent sur le même document et donc devoir refaire à chaque fois les mêmes modifications. Une solution classique a été envisagée : laisser à l'utilisateur la possibilité de sauvegarder sur demande, les modifications apportées dans un fichier indépendant. C'est possible. Mais auquel cas, lors du rechargement du document PDF, il faudrait choisir de nouveau d'appliquer ce fichier de modifications qui reste spécifique au document PDF. C'est juste informatiquement, mais humainement contraignant. Une autre réponse a été trouvée au problème. Nous avons choisi de sauvegarder automatiquement toutes les modifications de l'utilisateur, lors de la fermeture du document PDF, dans un dossier particulier des documents utilisateur. Ainsi, lors du chargement ultérieur du fichier PDF, les dernières modifications associées au fichier sont retrouvées de manière totalement transparente. C'est souple et pratique mais avec néanmoins quelques désavantages. Il est difficile d'envoyer à quelqu'un un document PDF avec les modifications correspondantes puisqu'il s'agit de deux fichiers à des positions différentes sur le disque. L'idéal aurait été de pouvoir mémoriser les modifications directement dans le document PDF, mais cela est techniquement complexe et surtout, source de confusion possible pour les visualiseurs de PDF autres que PDFToMusic. |
|
|
by Didier Guillion | | |
| |
|
Merci à tous pour vos cogitations sur l'OMNI de l'étape 48 ! Pour l'instant, nous envisageons de le traiter comme un caractère texte non interprété, en attendant de pouvoir faire mieux. Il faut en effet éviter de perturber la reconnaissance des autres documents, pour un cas qui est vraiment très particulier. L'interface à progressé avec la mise en place des préférences générales, de nouveaux paramètres de configuration du calcul et les prémices d'un nouveau mode de représentation qui "linéarise" le document PDF en affichant les systèmes de gauche à droite plutôt que de haut en bas. Ceci devrait ressembler, à terme, un peu au mode ruban d'Harmony Assistant et permettre à l'utilisateur de définir manuellement les liens entre portées dans le cas ou PDFToMusic ferait une erreur. La prochaine étape va donc être la mise en place de tout ce qui concerne les corrections accessibles à l'utilisateur afin de pallier aux déficiences de PDFToMusic. Nous allons implémenter les plus évidentes, comme l'attribution des instruments aux différentes portées (image) mais le reste viendra petit à petit en concertation avec les Beta Testeurs. |
|
|
by Didier Guillion | | |
| |
|
En 1988, nous nous lançons dans l'aventure Myriad. Jusqu'à cette date, nous étions étudiants mais cela faisait déjà plusieurs années que nous gagnions notre vie en temps qu'auteurs indépendants de logiciels, et plus précisemment de jeux vidéo. Il nous a donc semblé évident que nous devions continuer dans cette voie. De nos cartons, où nous entassons toutes les idées de logiciel qui nous viennent à l'esprit, nous extrayons une idée de jeu d'arcade. Le principe de base est que le joueur peut se déplacer sur toutes les parois d'un labyrinthe, y compris sur le plafond, comme une mouche. Une impulsion bien placée, et profitant de l'impesanteur il vole dans la pièce. A partir de cette idée nous bâtissons un lieu avec des zones remplies de monstres à dégommer mais aussi des jeux de sport, un genre de hockey où les rayons laser déplacent le palet. La répartition des tâches sera la même que pour nous autres créations : Gilles Soulet sera chargé des musiques, je m'occuperai du scénario, des graphismes et d'une partie du code C, Olivier et Jean-Michel du portage sur les différents ordinateurs et en particulier des multiples routines en assembleur. Le jeu sortira sur les trois machines les plus intéressantes du moment : Atari ST, Amiga 500 et PC. Au dernier moment, le jeu sera renommé d' "Albédo 0.0" ( le planétoïde où se déroule l'action ayant une Albédo de zéro pour le rendre quasi invisible) en "Albédo", comme on nous l'avait fait remarquer à juste titre, ceci pouvait se confondre avec un numéro de version. Edité par nos soins, distribué par Loriciels, je jeu sera un succès honorable mais qui nous satisfera car maintenant que nous n'étions plus simplement auteurs, mais éditeurs, la part sur chaque exemplaire vendu était beaucoup plus confortable. Je peux maintenant livrer le code, qui entré dans le jeu, ouvre toutes les options : PPDANS (Pour Passer Directement Au Niveau Supérieur ou Patrick Poivre d'Arvor Nous Saoûle). Si vous arrivez à faire tourner Albédo sur un émulateur, essayez-le... |
|
|
by Didier Guillion | | |
| |
|
Un nouveau site, proposant de nombreuses partitions au format PDF, nous a été indiqué : http://www.fac-simile.org. En particulier, il renferme de nombreuses partitions avec tablature pour Luth. Dans l'état actuel, PDFToMusic ne reconnait pas ces tablatures, dont l'écriture est un peu "alambiquée". Par exemple, voici comment une clef de sol est notée : Là, aussi, si nous en avons la demande, nous verrons ce que l'on peut faire... Mais, rien n'empèche de charger le MusicXML avec Harmony et de demander un affichage pour Luth. Sinon, un nouvel OMNI (Objet Musical Non Identifié) a été rencontré : Si quelqu'un a une explication de la signification de cette altération, elle est bienvenue... Addendum: Voici la partition originale, voyez en fin de page 3 http://www.myriad-online.com/images/blog/1_Cima_a1_adiuro.pdf |
|
|
by Didier Guillion | | |
| |
|
La majeure partie des paramètres de la reconnaissance sont maintenant accessibles à l'utilisateur dans ce que l'on pourrait appeler un mode "Super Utilisateur". L'édition des paramètres ressemble à ceci : Ceci correspond à environ une centaine de paramètres modifiables, classés en 21 groupes. On nous a demandé si la reconnaissance de la notation grégorienne était prévue. A priori, sans être insurmontable cela soulève tout de même quelques problèmes. Outre le fait qu'il n'existe, à ma connaissance, que très peu de partitions grégoriennes au format PDF sur l' Internet, le format MusicXML ne permet pas de mémoriser ce genre de notation. Il faudrait passer par une extension du format. Dans l'état actuel du projet, je pense que nous allons faire l'impasse sur cette notation, mais si plusieurs personnes ont vraiment besoin de cette fonctionnalité elles peuvent me contacter pour en discuter. |
|
|
by Didier Guillion | | | |
|
Un problème intéressant nous a été proposé, recupérer d'anciennes partitions créées sous IDD-Studio. A priori, pas de problème si ce n'est que certains documents présentent l'artefact suivant : Non, vos yeux ne sont pas fatigués, les lignes horizontales des portées ne sont pas jointives ! Un paramétrage plus permissif de l'imprécision des lignes horizontales dans le code de PDFToMusic permet tout de même de faire fonctionner la reconnaissance, mais je doute que l'on puisse laisser ce paramétrage pour toutes les partitions. Je pense qu'il va falloir envisager un mode de fonctionnement "avancé" de PDFToMusic où l'utilisateur pourra définir de manière fine tous les paramètres de la reconnaissance et ainsi créer une configuration spécifique à un type donné de logiciel. |
|
|
by Didier Guillion | | | |
|
Et la semaine se termine sur un dessert, proposé par Sylvain, les textes colorés avec rotation ! Nous allons essayer de faire notre possible mais le MusicXML est largement dépassé dans ce domaine. Cela reste relativement rare dans les partitions, ceci étant certainement du au petit nombre de logiciels qui gérent la rotation de texte. Mais si vous avez des exemples (autres bien sur que ceux générés par Harmony) ils sont les bienvenus. Le projet coté Macintosh a été adapté pour se compiler sous XCode et ainsi pouvoir obtenir un executable sous MacTel. Cela permet également de pouvoir enfin réutiliser Shark pour optimiser le code. La dernière version d'XCode est aussi instable, inergonomique, lente et pitoyable au niveau vitesse que les précédentes, c'est à désespérer de travailler sur Mac. A priori, la semaine prochaine devrait être consacrée à la validation de la gestion des voix et des "pseudos-accord" (voir étape 32). Une fois cette étape franchie, il va falloir éplucher, page par page, symbole après symbole, quelques centaines de document PDF pour localiser les erreurs et voir si elles sont corrigeables. Il nous tarde de pouvoir passer à la prochaine tranche : voir si les tous les algorithmes mis en place pourrons fonctionner sur des images bitmap (scannées) et non plus sur des PDF vectoriels. Ils ont été pensés en ce sens, mais rien n'est sur... Si les résultats sont probants cela pourrait aboutir à un Super OMeR. |
|
|
by Didier Guillion | | |
| |
|
Armé d'un jeu de rustines logicielles et de colle binaire nous avons traqué les pertes de mémoire de PDFToMusic, certaines était redoutables mais l'application est maintenant "propre". Malheureusement, j'ai eu le malheur de vouloir faire la mise à jour de XCode comme recommandé par Apple et une fois de plus cela à entraîné un dysfonctionnement total de Shark, l'outil d'analyse de code d'Apple qui devient inutilisable. Cela arrive tellement fréquemment que ça en devient fatiguant. Heureusement, il nous reste nos propres outils sous Windows. Si Apple allouait 10% de l' énergie qu'ils dépensent à prouver qu'ils sont les meilleurs à tester leurs logiciels cela nous épargnerait des jours de travail... Un cas de figure un peu particulier à été traité : certains logiciels traitent leurs coulés en deux parties, la première moitié pour la note de départ, la seconde pour la note d'arrivée. Les mesures multi-silences se sont avérées "casser" l'import MusicXML du Dolet, un rapport à été envoyé à l'équipe du MusicXML. De même les mesures invisibles semblent avoir des problèmes, ceci a également fait l'objet d'un rapport. |
|
|
by Didier Guillion | | | |
|
L'algorithme de détermination des voix s'est retrouvé difficilement compatible avec le format MusicXML qui n'accepte que 6 voix simultanées. Olivier a donc mis en chantier une troisième façon de traiter le problème, ce devrait être la bonne ! Certains fichiers PDF particulièrement denses, en particulier des partitions d'orchestre avec plus de trente portées par page (Belkin) ont dépassés les limites de précision de calcul de la position des symboles. Un mécanisme plus subtil a été mis en place. Une nouvelle manière de gérer les différentes pages du document est en cours d'implémentation, elle devrait permettre de naviguer de façon fluide d'une page à l'autre sans trop consommer de mémoire. Actuellement le temps de traitement d'un document de 32 pages est de 55 secondes dont 47 secondes sont passées dans la collecte des informations du fichier PDF et le reste dans l'analyse, nous allons essayer d'optimiser ceci. Il va falloir également tester la "porosité" de l'application (perte de mémoire due à une allocation non suivie par une désallocation). Mais ça avance ! Une bonne proportion de fichiers donnent un résultat quasiment à l'identique de l'original. |
|
|
by Didier Guillion | | |
| |
|
Un nouveau type de document PDF a été rencontré (Belkin), créé par raboutage de plusieurs documents PDF, il présente la particularité d'avoir des polices différentes par sous document, bien que le nom de la police reste le même. Ceci est maintenant géré. Un premier prototype de l'export des données privées en MusicXML (pages de garde, textes libres, images) a été écrit. Cela ne semble pas perturber le Dolet (importeur MusicXML de Recordare). Il va falloir maintenant écrire la partie "symétrique" : extraction et interprétation de ces données privées par l'importeur MusicXML d'Harmony. L'un dans l'autre, le projet avance quand même plutôt bien, nous devrions passer en Beta en Septembre. Vous pouvez vous inscrire dores et déjà en m'envoyant un email. Vous serez ainsi contactés en avant-première. |
|
|
by Didier Guillion | | | |
|
L'équipe du MusicXML a décidé que les informations manquantes dans le format ne seront pas étudiées avant 2007. Ceci concerne (entre autre) les pages de garde, les images embarquées et les textes sur des pages après la page 1. Nous allons devoir mémoriser ces informations dans des zones privées du fichier ce qui signifie que seuls nos programmes pourront les lire. C'est dommage... Mais un point positif est que le format MusicXML est suffisamment souple pour permettre à des applications de définir des zones qui ne seront lues que par elle-même. Sinon le projet continue à avancer avec des améliorations sur la gestion des coulés, des polices type 3, et des accroches. |
|
|
by Didier Guillion | | | |
|
La journée a été passée sur la validation du suivi des portées, qui fonctionne plutôt bien. Les notes avec une double tige, comme dans cet exemple ardu (Good): sont maintenant correctement reconnues, traitées et exportées en MusicXML. Le module de traitement des paroles a été adapté afin de gérer au mieux les tirets. Il reste à faire : - La gestion des accroches et des coulés d'une portée sur l'autre en export MusicXML - L'export de manière plus "intelligente" des accords - Les symboles brisés entre les systèmes. Pour l'instant seul les coulés sont traités, mais on peut rencontrer des crescendo/decrescendo ou des passages à l'octave qui continuent d'un système à l'autre, voire même sur une autre page. - La gestion des documents où certaines pages ont subit une rotation à 90° (passage de mode portrait à paysage) - L'intégration éventuelle de Virtual Singer pour chanter les paroles. Ensuite, nous pourrons, en fonction des résultats obtenus, définir la liste des interventions que l'utilisateur devra pouvoir appliquer pour corriger les erreurs de reconnaissance. |
|
|
by Didier Guillion | | | |
|
Le module de reconnaissance de crescendo/decrescendo a été réécrit, et accepte maintenant les symboles penchés bien que, comme le fait remarquer Sylvain, ce ne sera pas représenté à l'identique dans Harmony qui ne supporte que les symboles horizontaux. Ce sera une des choses à étudier pour la prochaine version, avec entre autre, les accords en appoggiature. La première version du suivi des portées d'un système sur l'autre a été intégrée au projet PDFToMusic et traite dans l'état actuel les exemples en notre possession de manière exacte. Il reste encore quelques jours de travail pour la valider entièrement. Nous n'excluons pas la possibilité de laisser à l'utilisateur une intervention manuelle sur le résultat obtenu. Tout un lot de PDF de partitions pour guitare fourni par Laurier (frescores.iespana.es) à commencé à être traité avec des résultats quasiment parfait. Toutefois, il apparaît une forme de notation qui me laisse perplexe. Que signifie la parenthèse dans ces partitions ? Si quelqu'un peut m'éclairer... |
|
|
by Didier Guillion | | |
| |
|
Le suivi des portées d'un système sur l'autre a été mis en chantier. C'est Olivier qui se charge de ce module. Différents paramètres vont être utilisés : nom et nom abrégé des portées, taille de la portée, présence de paroles, coulés coupés, etc. Nous faisons l'hypothèse que même si des portées disparaissent ou apparaissent d'un système à l'autre l'ordre des portées reste le même. Mais si vous avez un contre-exemple, où des portées changent de position, l'une passant devant l'autre selon le système, il est le bienvenu ! Sur un autre sujet, un exemple assez sympathique présente des crescendo et decrescendo penchés (Belkin) Ceci remet en question le module de localisation des crescendo/decrescendo qui devra être repris en profondeur... |
|
|
by Didier Guillion | | |
| |
|
La journée a été passée sur l'affichage et l'interprétation de PDF "exotiques"... "BWV659_score.pdf" (Chamade) trace les accroches entre les notes par des images "clippées" dans des aires complexes. Pourquoi faire simple quand on peut faire compliqué... "SV.pdf" (Belkin) organise les informations PDF d'une manière étonnante. Je serait curieux de savoir par quel générateur de PDF il a été créé. Ceci nous a permis d'améliorer la gestion des aires de fenêtrage sur les documents et l'affichage des images. Il peut sembler vain de passer une journée sur deux fichiers qui ne représentent même pas un millième des exemples en notre possession, mais peut être ce qui est l'exception à cette date, sera largement rencontré dans le futur. Mais c'est promis, demain, on attaque le chainage des portées entre les systèmes, cela va être amusant. |
|
|
by Didier Guillion | | | |
|
|