Meilleure gestion des accolades formant les groupes de portées.
Correction d'un problème de sauvegarde des corrections.
Correction d'un affichage dans le tiroir quand la musique se jouait. |
|
|
| by Didier Guillion |  |
| |
|
Correction d'un problème de chargement MIDI
Correction des ressources Melody
Dans PDFtoMusic :
Meilleure localisation et traitement des accords.
Meilleure discrimination entre accords et paroles.
|
|
|
| by Didier Guillion | |
| |
|
Dans PDFtoMusic :
Correction de l'export en MusicXML compressé lors du traitement par lot.
Dans Harmony et PDFtoMusic :
Correction de la sauvegarde et du chargement des tableaux de mesures imposés en MusicXML.
Le positionnement des accords en MusicXML a été repris à la base. Cela donne de bien meilleurs résultats avec Finale et Sibelius.
La précision d'affichage des accords MusicXML a été grandement améliorée dans Harmony.
|
|
|
| by Didier Guillion | |
| |
|
Nous avons pu créer une version d'Harmony Assistant n'utilisant plus du tout GTK, Cairo ou Pango, les bibliothèques de gestion d'interface de haut niveau.
Pour cela,nous avons dû créer un module d'affichage d'alerte système sur X11 pur, mais ce dernier ne propose rien pour gérer des boutons ou pour formater facilement du texte. Nous avons donc fait au mieux, quelque chose de pas trop moche, mais qui ne nous demande pas trop de travail. Cela sera utilisé uniquement dans le cas d'alertes système (par exemple en cas de crash).
Ca donne quelque chose comme ceci :
Pour l'instant, cette pré-version alpha d'Harmony ne permet pas d'ouvrir un sélecteur de fichier, d'imprimante, ou d'imprimer une page. Tout ceci devra être écrit plus tard.
Nous avons essayé d'installer cette version d'Harmony Assistant indépendante de la distribution Linux sur Ubuntu 14.04, en 64 bits. Et c'est là que les ennuis ont commencé. Pour résoudre les fameuses dépendances de bibliothèques, qui sont à la convivialité ce que le Kraken est à Bambi, il nous faut installer X11 en version 32 bits. Et lui-même a des dépendances, dont certaines ne peuvent pas être résolues.
Pour l'instant, nous en sommes là, à tourner en rond, et à faire chauffer notre ligne ADSL pour savoir quel paquet installer pour satisfaire quelle dépendance. Car, bien sûr, lorsqu'une bibliothèque "x" manque, ce serait trop simple d'installer le paquet appelé "x". Pour "X11", ce sera "xorg", pour "freetype", "libfreetype", pour "alsa", "libasound", etc.
Mais que cela ne vous empêche pas de passer un bon week-end (cela ne nous en empêchera pas non plus, je vous rassure) |
|
|
| by Olivier Guillion |  |
| |
|
Nous sommes parvenus à tracer des formes polygonales pleines, et à convertir une figure formée d'un ensemble de courbes de Bezier en polygone pour pouvoir la tracer.
Il faut maintenant pouvoir tracer seulement le contour de la forme, sans la remplir.
I- Contours fins
L'idée est de conserver le principe des "scan lines" utilisé dans le remplissage, et de l'adapter au tracé de contour. La couleur d'un point dépend alors de la distance minimale qui le sépare d'un segment ou d'une extrémité de segment constituant le polygone.
Calculer, pour chaque point de l'image, la distance à chacun des segments ou extrémités de segment serait trop lourd et trop lent pour être viable. Il faut donc éliminer rapidement tous les segments qui n'ont aucune chance d'être à proximité immédiate du point considéré, et calculer uniquement les distances jusqu'aux segments proches.
Plusieurs méthodes ont été implémentées, mais n'ont pas d'effet sur le résultat, seulement sur la rapidité.
On obtient donc, même avant que la rapidité soit optimisée :
II- Contours épais
Il est assez facile de faire varier l'épaisseur du trait :
Lorsque la distance qui sépare le point considéré du plus proche segment est inférieure à la demi-épaisseur, on est dans le trait. Lorsqu'elle est supérieure, on est en dehors du trait.
III- La totale
On peut maintenant combiner les deux, traits et remplissage, et vérifier qu'ils s'ajustent correctement.
La même chose avec des traits encore plus épais :
IV- Performance
Il est assez difficile d'évaluer la performance du tracé. Cela dépend en effet de la complexité de la figure, de sa taille, et des capacités de la machine.
Cependant, sur un PC qui n'est plus de la première jeunesse, on obtient, pour le test précédent, une moyenne d'environ 1 milliseconde (1/1000e de seconde) par tracé de figure, donc 1 ms pour le remplissage du 1er polygone, 1 pour son contour... soit 6 millisecondes pour l'ensemble du dessin.
Pour ce que nous voulons en faire (nos programmes ne sont pas des jeux avec des centaines de formes dessinées en temps réel), cela nous paraît suffisant.
V- Implémentation
Ces algorithmes ont été mis en place dans ACAM-Winter, et essayés dans Harmony Assistant, pour le tracé des accolades et des liaisons entre les notes.
Nous avons pu comparer le rendu entre notre méthode et les courbes de Bezier traitées par cairo, la librairie système de notre Linux Ubuntu :
Les deux rendus sont tellement proches que nous avons dû superposer les images dans un logiciel de dessin pour pouvoir constater une différence sur quelques pixels.
On peut donc considérer que notre algorithme remplace parfaitement la bibliothèque système, nous permettant de nous affranchir complètement de cette dernière. Il y aura probablement quelques erreurs de tracé dans certains cas limites, que nous devrons corriger, mais cela pourra être détecté dans la version alpha ou beta du programme. |
|
|
| by Olivier Guillion | |
|
| |
|
Hier, nous étions parvenus à dessiner des polygones anticrénelés. Mais le but reste de dessiner des courbes. Peut-on, en créant suffisamment de segments, approximer une courbe par un polygone ?
I- Le test du disque
Afin de vérifier cela, et mettre également notre algorithme à l'épreuve, nous créons un polygone qui suit le contour d'un cercle. Un segment est créé pour chaque 5° d'angle, ce qui au final aboutit à un polygone à 72 cotés.
Nous lançons notre programme, et obtenons :
Le disque est correctement tracé et anticrénelé. Les pans coupés dont il est constitué ne sont pas visibles et la figure donne l'apparence d'une courbe douce.
II- La transparence
Afin de nous permettre de mieux visualiser nos résultats, plutôt que de tracer systématiquement nos figures en noir opaque, nous introduisons un niveau de transparence.
Notre dessin de test, avec un nouveau polygone de 6 points, et une transparence différence pour chaque élément, donne ceci :
III- Les courbes de Bezier
Dans les courbes de Bezier, chaque noeud de la figure est constitué d'un point par lequel passe la figure, et de deux points de contrôle, un de chaque coté du point, définissant l'angle de la courbe lors du passage au point.
Nos polygones précédents peuvent être considérés comme des courbes de Bézier en ne prenant qu'un point sur trois, et en considérant les deux autres comme les points de contrôle.
L'algorithme de De Casteljau nous permet de diviser chaque segment en deux, et de calculer le point de Bezier intermédiaire. Répété récursivement, il permet de lisser complètement la courbe.
Si on ne considère qu'un point sur trois dans nos deux polygones à angles vifs, on obtient 3 points (un triangle) pour le premier, et 2 points (une ligne ultrafine, invisible) pour le second.
L'algorithme de De Casteljau nous permet de calculer les points intermédiaires sur les courbes de Bezier définissant ces figures. Voici, avec une subdivision de chaque segment en 4 :
Puis avec une subdivision en 8 :
Puis avec une subdivision et en 16 :
On ne voit presque plus les "coins" des polygones. En améliorant l'algorithme de division de De Casteljau pour continuer à diviser tant que c'est visuellement nécessaire, on obtient nos premières courbes de Bezier lisses et anticrénelées :
Le plus difficile est maintenant derrière nous. Il nous faut maintenant être capable de tracer les contours au lieu des formes pleines, et inclure ces algoritmes dans notre bibliothèque de programmation.
(à suivre) |
|
|
| by Olivier Guillion | |
| |
|
Dans le cadre de la mise à jour de la bibliothèque de compatibilité "ACAM", nous avons dû nous pencher sur le tracé de courbes dites "de Bezier". En effet, il s'agit du seul type d'objet graphique qui nous oblige encore à utiliser les bibliothèques du système, cairo sur Linux ou GDI+ sur Windows.
L'idée était donc de tracer par nous-même des courbes de Bezier, et anticrénelées qui plus est, c'est-à-dire utilisant des niveaux de gris sur les arètes de la courbe pour les faire apparaître lisses.
Voici toutes les étapes de notre cheminement, jusqu'à la solution définitive.
I- Tracé simple de polygone
La première étape consiste à pouvoir dessiner des polygones remplis. Un polygone est une figure fermée, constituée d'un ensemble de points reliés entre eux deux par deux, le dernier point étant relié au premier.
Pour tracer, nous avons utilisé le système de "scan-lines" :
- On considère une à une les lignes horizontales (scan-lines) de l'aire contenant la figure.
- Pour chacune de ces lignes horizontales, on calcule le point d'intersection entre cette ligne et chacun des segments de la figure. Il y a toujours un nombre pair d'intersections (vous pouvez le vérifier avec un papier et un crayon).
- Il suffit alors de classer ces intersections par X croissant, les considérer deux à deux et remplir en noir entre chaque paire.
On obtient alors ceci, pour un polygone quelconque de 9 points :
Le tracé est mathématiquement exact, mais si on observe en détail la figure obtenue, on voit que les bords sont crénelés :
II- Anti-crénelage horizontal
Plutôt que de dessiner des points en noir ou blanc, on va traiter spécialement le premier et le dernier point de chaque ligne horizontale tracée, et choisir un niveau de gris représentant la proportion de noir dans le pixel.
Le balayage considérant des scan-lines horizontales, ce procédé ne fonctionne que sur les segments de polygone plutôt verticaux. Pour les autres, il faudrait que plusieurs points à la suite aient des gris différents. Nous verrons cela plus tard.
On obtient alors :
Sur le détail, on voit que les lignes verticales ont bien été traitées, mais que les lignes horizontales sont encore crénelées:
III- Anti-crénelage bidirectionnel
L'algorithme, jusqu'ici, est rapide, très rapide.
Plutôt que de s'embarrasser de calculs mathématiques complexes pour traiter les bords des segments plutôt horizontaux, ce qui ralentirait le tracé d'un facteur 3 ou 4, nous estimons qu'il est plus simple et probablement plus rapide de simplement doubler l'algorithme existant avec un balayage vertical, à même de traiter les segments restants.
Dans la littérature, de tels algorithme de "cross scanline" ont déjà été envisagés il y a 25 ans pour obtenir des anticrénelages de haute qualité.
On obtient maintenant ceci :
Le détail montre que tous les segments ont été correctement anticrénelés.
Maintenant, il va falloir s'assurer que des courbes aux formes douces peuvent être correctement approximées par des polygones.
(à suivre...) |
|
|
| by Olivier Guillion | |
| |
|
Nous n'étions plus habitués à progresser rapidement sur l'interface Acam Winter pour Linux. C'est pourtant ce à quoi nous avons eu droit aujourd'hui.
Les touches "mortes"
Tout d'abord, nous rencontrions des problèmes de clavier avec les "touches mortes" (dead keys) permettant de taper des lettres accentuées, qui n'étaient pas gérées par X11. Mais nous avons pu trouver, sur le site du consortium Unicode, un fichier texte contenant l'intégralité du jeu de caractères, avec, pour chaque code, son nom en clair.
Nous avons pu écrire un programme jetable (en Perl), qui analyse ce texte, et reconstitue les caractères précomposés en fonction des deux touches entrées.
Par exemple, si l'utilisateur entre le caractère "^", il sera traduit par le code
0302 CIRCUMFLEX ACCENT
Ensuite, s'il entre un petit "e", il correspondra au code
0065 LATIN SMALL LETTER E
Or, dans la même table unicode, on a un caractère
00EA LATIN SMALL LETTER E WITH CIRCUMFLEX
Par analyse des noms des caractères, nous avons donc pu établir une table de correspondance complète entre les couples accent-lettre, et la lettre accentuée correspondante.
Les Alt-codes
Pour obtenir des caractères n'étant pas disponibles sur le clavier, sur Windows (et repris depuis sur d'autres systèmes), on peut appuyer sur Alt et entrer le code numérique du caractère.
Nous avons géré cela, en permettant l'entrée numérique par Alt-code de tous les caractères Unicode.
Par exemple, on pourra entrer Alt 234 pour obtenir un ê, ou Alt 0EA (le 0 de départ indiquant qu'il s'agit d'une entrée en hexadécimal) pour obtenir le même caractère. En effet, la plupart des tables Unicode sont fournies en hexadécimal, et il sera donc possible d'entrer directement des codes dans cette base.
Harmony Assistant
Acam Winter étant suffisamment fonctionnel, nous avons alors recompilé la version Linux d'Harmony Assistant avec cette bibliothèque. Après quelques ajustements d'options de compilation, nous avons obtenu ceci :
L'application utilisant le nouveau système d'interface est donc quasi-fonctionnelle.
Quelques détails restent à régler. Entre autres :
1- Les curseurs souris dessinés par nos soins. Les fonctions X11 pour gérer cela sont assez difficiles à maitriser.
2- Quelques touches clavier (Page up/Page Down, Suppr...) ne sont pas bien gérées
3- Le bouton droit de la souris et sa molette ne sont pas correctement pris en compte
4- Toute la partie impression est à reprendre en utilisant un export PostScript et CUPS.
Mais tout cela attendra la semaine prochaine.
Bon week-end à tous, et joyeuses Pâques ! |
|
|
| by Olivier Guillion | |
|
| |
|
Correction de l'affichage du nom de la portée dans le menu des multi-voix quand le texte était stylé.
L'affichage des plans des multi voix était légèrement différent entre le mode page et l'impression et en particulier quand des notes se chevauchaient graphiquement, c'est corrigé.
Correction du positionnement des textes de parole en import NWC. |
|
|
| by Didier Guillion | |
| |
|
Les affichages de textes sont maintenant terminés. Nous avons géré les différents styles et écrit les routines permettant de créer ces styles lorsqu'aucune variation de la police n'est disponible.
Ainsi, les styles gras, italique, souligné, contour (pas facile, celui-ci), ombré, condensé ou étendu sont gérés sor toutes les polices, en toutes les tailles.
Le mode de fonctionnement de l'interface étant maintenant en MDI, c'est-à-dire une grande fenêtre de bureau contenant le menu et toutes les fenêtres et palettes de l'application, nous avons créé les ascenseurs qui permettent de voir les morceaux de fenêtres qui sont en dehors de l'aire du bureau. Ces ascenseurs ont été réduits au strict minimum pour éviter de gâcher de l'espace sur l'aire utile.
Dans l'image ci-dessous, l'ascenseur vertical est montré par une flêche :
On peut également y voir un texte en contour et ombré. Bizarrement, la bibliothèque d'affichage de texte Freetype ne semble pas fournir de fonction de tracé de contour de caractère, ce qui nous a obligé à gérer nous-même ce style. |
|
|
| by Olivier Guillion | |
| |
|
Sur demande d'utilisateur, il est maintenant possible de placer la tête d'une appoggiature entre parenthèses.
Par soucis d'uniformisation, c'est également appliquable aux notes normales :
|
|
|
| by Didier Guillion | |
| |
|
Les plus technophiles d'entre vous auront entendu parler, ces jours derniers, de Heartbleed, la faille de sécurité affectant les accès cryptés à certains sites Web.
L'impact et l'exemplarité de cet épisode méritent qu'on y revienne dessus.
Tout d'abord, de quoi s'agit-il exactement ?
Heartbleed, coté fonctionnement
Pour résumer (et simplifier un peu), le problème touche OpenSSL, qui gère les échanges sécurisés entre par exemple un serveur Web (gmail, facebook, yahoo, etc) et le client (vous, votre voisin, un hacker, un pirate ou un agent de la NSA) qui y accède.
Lors de ces échanges, le client peut demander des données au serveur, et, en exploitant une erreur de programmation, s'arranger pour recevoir, en plus de ces données, le contenu d'une zone mémoire utilisée préalablement par le serveur lors des échanges avec quelqu'un d'autre et malencontreusement non effacée.
Ainsi, n'importe qui peut s'arranger pour obtenir des données qui ne lui étaient pas destinées. Ces données peuvent être totalement inutiles, mais aussi des données sensibles (noms d'utilisateur, mot de passe, échanges privés...). En récupérant beaucoup, beaucoup de données par ce biais et en les triant, une personne mal intentionnée peut récupérer des noms d'utilisateurs et des mots de passe, et donc pirater des comptes ou accéder à des données privées. Imaginez ce que ça peut donner s'il s'agit du serveur de votre banque en ligne...
Heartbleed, coté programmation
On peut légitimement se poser la question : pourquoi les données sensibles se sont-elles retrouvées en clair dans une zone mémoire non utilisée ? N'aurait-il pas été plus sûr, si cette zone mémoire n'était pas censée être utilisée telle quelle, de l'effacer ?
OpenSSL est, sauf erreur, écrit en C. Un langage rapide, mais pas réputé pour la sécurité intrinsèque du code. En gros, on peut faire beaucoup de choses, qui vont très vite, mais ça crashe facilement, ça peut déborder, ça peut lire et écrire en dehors des endroits prévus, etc.
On peut alors choisir de privilégier la sécurité ou la performance. La sécurité, c'est, lorsqu'une zone mémoire va être utilisée ou est libérée, de l'effacer complètement. La sécurité, c'est aussi d'utiliser un gestionnaire de mémoire qui va générer une "exception" (un arrêt du programme ou l'inscription dans un journal d'alerte) lorsqu'on accède un peu en dehors des zones prévues.
La performance, c'est tout le contraire. Dans OpenSSL, on a visiblement choisi la performance.
Heartbleed, coté autorités
On ne sait pas vraiment depuis combien de temps la faille heartbleed est connue de certains. Il se murmure que la NSA l'exploite depuis plusieurs mois, voire plusieurs années, avec l'accord explicite des plus hautes autorités américaines. Et il est strictement impossible de savoir quelles données ont été lues par ce biais, d'en remonter la trace et ainsi de savoir qui a volé quoi.
Le saint-Grââl de l'espionnage informatique.
Heartbleed, coté philosophique
Cela nous amène à nous interroger. Comment une faille de cette importance, et présentant ces conséquences, a-t-elle pu perdurer dans l'un des programmes Open Source les plus utilisés au monde ? On nous a présenté l'Open Source comme un schéma dans lequel la sécurité était maximale, car tous les programmeurs avaient la possibilité d'examiner le code, trouver les erreurs, les signaler et les corriger. Ainsi, aucun défaut majeur ne pouvait perdurer bien longtemps avant d'être repéré et traité.
On s'aperçoit aujourd'hui que ce n'est pas vrai, en tout cas pas obligatoirement vrai.
Heartbleed, coté "Open"
Le beau scénario de l'Open Source ne peut fonctionner que si trois points sont respectés :
1- Il y a suffisamment de programmeurs compétents pour vérifier le code.
2- Le code est suffisamment clair pour permettre à tous de s'y retrouver facilement
3- Il y a plus de programmeurs "honnètes" pour chercher les failles que de pirates ou d'agents du gouvernement.
Pour 1-, le nombre de programmeurs chevronnés est probablement grandement surestimé. Et dans ceux-ci, beaucoup ont autre chose à faire que d'examiner du code qui fonctionne (ou qui semble fonctionner) correctement.
Pour 2-, sans avoir étudié le code source d'OpenSSL, beaucoup de projets Open Source semblent avoir été écrit avec les pieds par Hannibal Lecter. La syntaxe semble avoir été compliquée à dessein, les noms de fonctions et de variables semblent issus d'un manuel de codage russe, et les commentaires se résument souvent à une belle en-tête de fichier en ASCII Art.
Pour 3-, Heartbleed semble avoir prouvé que les pirates et les cyberespions possèdent maintenant un avantage en terme de moyens et de main-d'oeuvre par rapport à la poignée de bénévoles décidés à passer leur week-ends à relire l'intégrale du code d'OpenSSL, on se demande pourquoi.
Et maintenant, tout le monde est en train de se poser la même question : "celle-ci a été repérée, mais y en a-t-il encore beaucoup, des failles comme ça ?"... |
|
|
| by Olivier Guillion | |
|
| |
|
Pour finir la semaine :
Dans PdfToMusic, le nouveau traitement des accords pouvait "casser" la création des paragraphes de texte, c'est corrigé.
Certains affichages de texte n'étaient pas à la norme Unicode, ils ont été localisés et modifiés.
Nous avons fait pas mal de recherche sur les types de polices vectorielles que l'on peut rencontrer sur les différents OS, ceci afin de préparer des améliorations de l'export PostScript.
Sur Mac, on trouve des .dfont qui sont en fait une version particulière des anciennes polices TrueType type 1. Ce type de format est spécifique au Mac et ne sera donc pas traité puisque Mac/OS propose par défaut un export PostScript via le pilote d'impression.
Sur Linux, on trouve des .pfb qui sont des polices définies directement en PostScript. Elles devraient pouvoir être utilisées facilement.
Bon week-end ! |
|
|
| by Didier Guillion | |
| |
|
La gestion du presse-papier X11 est décidément bien complexe. Nous avions pratiquement abandonné l'idée de l'utiliser, ne parvenant pas à faire fonctionner ce système correctement.
Mais les conseils avisés de Bubu42 (que nous remercions au passage) nous ont poussés à persister encore un peu. Ne pouvant trouver aucune documentation digne de ce nom, nous sommes allés à la pêche aux extraits de code, et nous avons pu repérer quelques pistes que nous avons alors explorées une à une. Et au bout de quelques heures, bingo !
Tout notre code était correct. Simplement, nous interrogions le système pour lui demander de nous fournir le contenu du presse-papier sous la forme d'une chaine de caractères standard. Et, selon l'application dans laquelle le "copier" avait été effectué, cela pouvait ne rien donner. Dans ces cas-là, il fallait réitérer la demande, mais en demandant le résultat sous la forme d'une chaine de caractères encodée en UTF8, format non connu par défaut dans X11.
Introuvable par nous-même, et non documenté. Le top.
Enfin, bon, avec cela, ça commence à fonctionner. Tout au moins sous Ubuntu/Gnome. |
|
|
| by Olivier Guillion | |
|
| |
|
L'export PostScript a été repris à la base et gère maintenant les polices TTF qui seront désormais embarqué dans le fichier.
Ceci servira de base de travail à l'impression sous Acam Winter, le fichier .ps sera envoyé à Cups.
Dans PDFtoMusic, correction d'un problème de conflit dans les menus contextuels. |
|
|
| by Didier Guillion | |
| |
|
Pas de grandes avancées aujourd'hui. Il est extrêmement difficile d'obtenir des informations précises et claires sur le fonctionnement interne de X11 et de Gnome, KDE ou autre.
Par exemple, X11 gère un presse-papier (pour le copier/coller). Dans Ubuntu (Gnome), il y a également un presse-papier. Sont-ils les mêmes ? Pas sûr.
Les premiers tests montrent qu'en utilisant le presse-papier X11, on parvient bien à récupérer du texte copié depuis le Terminal, par exemple, mais pas celui copié depuis Gedit.
Est-ce un problème de format, une initialisation qui manque, ou simplement Gnome gère-t-il un presse-papier indépendant de celui de X11?
Dans ce dernier cas, cela nous obligerait à gérer des accès au presse-papiers différent pour chacun des environnements possibles, ce qui complique sensiblement la chose. |
|
|
| by Olivier Guillion | |
|
| |
|
Une première mouture de la traduction en allemand a été mise en place. D'un commun accord avec le traducteur nous laissons de coté pour l'instant la boite du mode expert car de toute façon, sans le manuel elle est difficilement utilisable et la traduction ne concerne pour l'instant que l'interface.
Le système de jeu de sons d'alerte signalant la fin de traitement a été reprise. Elle avait été basée sur celle d'OMeR qui utilisait des ressources sons. Nous l'avons réécrite de manière à utiliser des .myr, plus courts, ce qui permettra au passage aux utilisateurs de définir leurs propres signaux.
Enfin, des problèmes de traitement de noms des accords quand l'option "Autoriser les accords" étaient désactivée ont été corrigés. |
|
|
| by Didier Guillion | |
| |
|
La structure d'Acam Winter est entièrement en place, il nous "suffit" maintenant de remplir les blancs, et d'écrire les fonctions manquantes.
La prochaine étape devrait consister à trouver un moyen de tracer les courbes de Bezier sans utiliser Cairo. En effet, même si cette bibliothèque est largement répandue, il est dommage de conserver une dépendance vers elle seulement pour le tracé de ces courbes.
Ensuite, nous avons fait des essais d'impression avec CUPS. A priori, si nous parvenons à écrire un export au format PostScript performant, nous devrions pouvoir utiliser CUPS pour envoyer ces données à l'imprimante. Cela ne résoudra cependant pas le problème de la boîte de sélection d'imprimante, de taille papier, et de mise en page (orientation, etc)
Nous avons le week-end pour réfléchir à tout cela. Les Linuxiens sont étonnamment silencieux sur tous ces points. Ils semblaient beaucoup plus nombreux lorsqu'il s'agissait de réclamer que pour nous aider à trouver des solutions, mais je suppose qu'il fallait nous y attendre.
Bon week-end à tous ! |
|
|
| by Olivier Guillion | |
|
| |
|
Dans la correction manuelle du document, il est maintenant possible de demander d'ignorer un changement de métrique ou de le fixer à une valeur désirée.
Des problèmes ont été corrigés dans la reconnaissance du symbole de répétition de la mesure précédente.
Ce type de notation a été rencontré :
Elle est maintenant gérée par une duplication de la première partie de la mesure.
|
|
|
| by Didier Guillion | |
| |
|
Nous commençons à voir un peu mieux les points qui nous poseront problème dans Acam Winter version Linux, et nous avons pu établir une liste.
Pour rappel, nous essayons de porter notre système d'interface sur Linux en utilisant le strict, mais alors strict minimum de fonctionnalités du système ou de bibliothèques optionnelles (seulement Xlib, freetype et ALSA pour le son).
Voici la liste des difficultés recensées jusqu'ici :
1- Gestion des touches "mortes" du clavier (pour l'instant, aucune solution en vue)
2- Sélecteur de fichier (pour l'instant, aucune solution en vue)
3- Sélecteur d'imprimante (pour l'instant, aucune solution en vue)
4- Tracé de courbes de Bezier (par un module "custom" inclus dans le programme?)
5- Impression (par génération de fichier PS puis envoi par CUPS ?)
6- Gestion du drag & drop (géré par Xlib?)
7- Gestion des entrées clavier complexes, par exemple en japonais (IME, géré par Xlib?)
8- Gestion du presse-papier (à vérifier, mais devrait être géré correctement par Xlib)
9- Icône de l'application (à vérifier, mais devrait être géré correctement par Xlib)
10 - Import & export d'images au format jpg, bmp, tiff... (bibliothèque-s- à inclure dans nos projets ?)
Il y en aura peut-être d'autres, mais pour l'instant, nous essayons de nous documenter et de savoir ce que nous pouvons faire avec ces 10 premier points. |
|
|
| by Olivier Guillion | |
| |
|
Il y a quelques jours un utilisateur nous a envoyé toute une collection de très gros PDFs qui sont des BO complètes de film. Cela nous a permis d'optimiser les vitesses de traitement et d'affiner les calculs.
De nouvelles options sont apparues et sont en cours de test. Par exemple, il est inutile d'essayer de localiser des paroles et de les associer aux portées si l'on sait pertinemment qu'il n'y a aucun chanteur dans l'orchestration.
Enfin, un autre utilisateur nous a proposé de traduire PDFtoMusic en Allemand et nous sommes en train de travailler ensemble la dessus. |
|
|
| by Didier Guillion | |
| |
|
|
