En préparation d'une nouvelle beta (1.4.3b4), maintenant imminente, nous avons :
- corrigé quelques problèmes de conversion de caractères,
- mis en place l'interface graphique permettant de sélectionner le niveau de réflexion du programme lorsqu'il tente de suivre les portées d'un système à l'autre
- Complété et corrigé les documentations
- vérifié la conformité des fichiers de données entre la version Macintosh et Windows
- Généré et testé l'installateur en version Windows
Encore quelques tests, et si tout fonctionne, nous devrions publier ça demain pour les beta-testeurs motivés.
|
|
|
| by Olivier Guillion |  |
| |
|
Un utilisateur nous a soumis certaines de ses partitions, qui ont été générées par un programme. Elles flirtent avec les limites du logiciel, avec un nombre de notes très important (jusqu'à 200 par mesure), dans des "clusters" très serrés et très nombreux.
Ceci nous a permis de mettre en évidence les parties de notre code qui méritaient d'être accélérées. L'effet sera bien entendu moins sensible avec des partitions "normales", mais la fluidité générale devrait être améliorée. Nous veillons cependant à ce que le résultat reste exactement identique à la version précédente en toute circonstance, pour éviter un changement d'aspect des partitions.
Ainsi, ont été grandement accélérés:
- les calculs des positions des notes de la partition en mode gravure
- l'application de décalages (+/- un demi-ton, une interligne, une octave) sur une sélection ou l'ensemble de la partition
- le recalcul automatique des positions des liaisons pour éviter les notes, lorsque ces dernières sont modifiées |
|
|
| by Olivier Guillion | |
| |
|
Nous commençons à bien comprendre la structure des fichiers de police TTF, qui est plutôt complexe.
Nous devrions être capables de mettre en place un export sélectif des polices en format PostScript, permettant de réduire la partie exportée aux caractères réellement utilisés dans le document.
Et, petit à petit, la syntaxe du langage PostScript nous revient en mémoire. Étonnamment, le fait que ce langage utilise la notation polonaise inverse ne nous a absolument pas posé de problème (c'est comme le vélo, ça ne s'oublie pas) mais par contre la syntaxe est parfois un peu ardue (par exemple cvrs pour convertir un nombre décimal dans une autre base, ça ne se trouve pas tout seul). |
|
|
| by Olivier Guillion | |
|
| |
|
Nous avons tenté de mettre en place le nouvel export Postscript (.EPS ou .ps) sur Windows, et nous avons rencontré quelques difficultés. A noter que tout ceci servira également à terme pour toutes les impressions d'Acam-Winter sur Linux.
- Tout d'abord, il n'y a pas de moyen standard d'interroger le système pour savoir quel fichier de police (.ttf) est utilisé pour tracer les caractères d'une police donnée.
Nous avons donc dû nous résoudre à balayer le répertoire des polices systèmes (Windows\Fonts) et à rechercher à l'intérieur de chaque fichier ttf le nom de la police correspondante.
- Ensuite, certaines polices Windows sont au format ttc, c'est-à dire une collection de polices ttf regroupées dans un seul fichier. Nous pensons avoir trouvé comment prendre en compte ces polices, mais ne l'avons pas encore mis en place, étant donné que ce format est somme toute peu utilisé, et uniquement pour des polices asiatiques.
- Enfin, de nombreuses polices du système ont une table "post" (table qui donne le nom Postscript des différents glyphes) de type 3, ce qui n'est pas géré par le module qui encapsule les polices dans le fichier Postscript. Ceci est vraiment gênant, car la résolution de ce problème est ardue, et cela est absolument nécessaire pour pouvoir utiliser les polices Windows dans l'export. Nous y travaillons. |
|
|
| by Olivier Guillion | |
| |
|
Dans PDFtoMusic (/pro), l'abandon du traitement par l'utilisateur (clic sur la case de fermeture de la fenêtre de traitement du document) n'empêchait pas la totalité des pages d'être lues. Un fichier de 136 pages scannées faisait planter le logiciel au bout de quelques minutes, et le processus ne pouvait donc pas être abandonné.
Ceci a été corrigé, et la prise en compte de l'abandon par l'utilisateur est faite dès que la page courante a fini d'être lue.
Sur Windows, un petit programme appelé Myrpref est livré avec nos applications. Il permet d'aller visiter le dossier des préférences, ou, sur Windows Vista et supérieur, le dossier des fichiers système cachés, appelé VirtualStore, à l'origine de très nombreux problèmes.
L'ouverture de ce dossier ne fonctionnait pas toujours correctement, empêchant donc certains utilisateurs qui suivaient nos instructions d'effacer correctement le contenu.
Cela a été corrigé pour la prochaine version, et la version de MyrPref téléchargeable sur notre site a été mise à jour.
Dans Harmony Assistant, lorsqu'on éditait les paramètres d'une note, entrer dans la valeur de la note un numéro d'octave compris entre 30 et 40 transformait la note en silence, qui ne pouvait pas être changé à nouveau en note en restant dans la même boîte. Cela a été corrigé. |
|
|
| by Olivier Guillion | |
| |
|
Nous nous sommes attaqués sérieusement à CUPS, le système d'impression unifié pour Linux, créé par Apple, et donc également intégré à Mac OS X.
Une tentative vers un peu plus de facilité de programmation a apparemment été tentée, avec la documentation complète proposée par défaut sur les pages Web du serveur CUPS.
La tentative s'arrête là.
Des changements d'optique des programmeurs de ce module rendent obsolètes la plupart des programmes écrits pour des versions précédentes, des nouvelles fonctions qui semblent tout simplement ne pas fonctionner, des documentations sur les fonctions qui oublient de préciser ce que représentent les paramètres, des relations avec les fonctions de bas niveau (IPP) documentées à l'arrache et incompréhensibles en l'état, tout ceci rend la programmation difficile, pour ne pas dire périlleuse.
Et, pour la première fois, une recherche Google de code source déjà écrit avec les fonctions de CUPS ne donne qu'une poignée de résultats, la plupart étant des copies de la documentation, les autres le code source de CUPS lui-même.
Au bout d'une journée de piétinement, nous avons attaqué CUPS au plus bas niveau, en interrogeant la couche basse du serveur d'impression (IPP), et avons obtenu les premiers résultats probants : la liste des imprimantes connectées, avec, pour chacune d'elles, la taille du papier par défaut.
Sur tous les autres systèmes, cela demande 3 lignes de code et 10 minutes. Sur Linux, 300 lignes (et encore, en trichant et en utilisant des fonctionnalités non autorisées), 1 jour et demi, et la validation d'un doctorat en documentation quantique (la même information y est et n'y est pas, à plusieurs endroits différents, et tout ça en même temps) |
|
|
| by Olivier Guillion | |
| |
|
La journée a été passée à tenter de rattraper le retard dans le traitement du très long week-end dernier, et à pester contre le système de bibliothèque dynamique de Linux.
Si la plupart des bibliothèques que nous utilisons (X11, Freetype, Alsa, Zlib, Vorbis, etc) sont disponibles en deux versions, dynamique et statique, on se rend compte assez rapidement qu'il ne s'agit que d'une illusion de choix, la version statique ne fonctionnant tout simplement pas.
Lorsqu'elle est utilisée, soit elle ne contient pas toutes les fonctionnalités demandées par le programme, soit des alertes sur des risques de problèmes et des options de compilation apparaissent, soit sa version dynamique continue à être requise malgré tout.
Nous allons donc en rester là pour nos tentatives de jouer finement, et nous reconcentrer sur l'objectif de produire une version alpha utilisable au plus vite.
|
|
|
| by Olivier Guillion | |
| |
|
|
