Aujourd'hui nous avons travaillé notamment sur la manière de gérer des vues en MyrScript, le langage de programmation intégré à Harmony Assistant.
Il fallait permettre de gérer tous les paramètres des vues, et d'altérer le contenu de chacune des vues, sans que les programmes déjà écrits en MyrScript ne nécessitent d'être repris.
Nous avons donc opté pour une solution relativement simple, mais qui ne permet pas de travailler extrèmement facilement sur plusieurs vues simultanément : la gestion d'une "vue courante", qui conditionne toutes les opérations effectuées ensuite sur les paramètres auxquels on accède.
Par exemple, pour faire apparaître la première portée du conducteur dans la première vue partielle, il faudra écrire quelque chose comme:
-- L'index 1 correspond à la vue générale
-- et l'index 2 à la premiere vue partielle
vue=score.Views[2]
-- Fixe la vue courante
score.SetCurrentView(vue)
-- A partir d'ici on travaille sur la vue n°2 (1e vue partielle)
score.FirstStaff.IsPrinted=true
-- La 1e portée est maintenant visible dans cette vue
Le système a l'air de bien fonctionner, et d'être relativement simple d'emploi.
Seule contrainte, lorsqu'on veut recopier un certain nombre de paramètres d'une vue sur une autre, il vaut mieux fixer la 1e vue comme vue courante, copier tous les paramètres désirés dans des variables locales, puis fixer la 2e vue comme vue courante et recopier les variables locales dans la 2e vue, plutôt que de passer d'une vue à l'autre à chaque paramètre.
Il ne reste plus qu'à mettre en place la création, suppression et déplacement de vue, et MyrScript devrait alors être complet sur ce point. |
|
|
| by Olivier Guillion |  |
|
| |
|
Parmi les nouveautés de la version 9.4, apparaît la notion d'accord sur les appogiatures. Malheureusement, l'onglet appogiature était déjà saturé et ressemblait à ceci :
L'édition des appogiatures à donc été épurée grâce à une liste :
A terme cela permettrait d'augmenter le nombre maximum d'appogiatures par note.
Ceci offre également la possibilité de réorganiser les appogiatures via un click long sur les éléments de la liste.
Nous allons maintenant attaquer tout ce qui est nécessaire pour proposer une version béta.
Au passage, que préfèrent les béta testeurs ? Une version 9.4 qui sauvegarde au format compatible avec la v9.3 mais bien sur sans la possibilité de mémoriser certaines nouveautés comme lpar exemple les vues, ou une version 9.4 complète dont les fichiers ne pourront être lus avec la v9.3 (Sachant que le format Music XML reste tout de même une excellente passerelle descendante) |
|
|
| by Didier Guillion |  |
|
| |
|
Dans le menu des vues, deux nouvelles options ont été ajoutées : vue suivante et vue précédente.
Un nouveau mode d'affichage pour les objets libres fait son apparition. Un objet libre peut s'afficher sur toutes les vues ou sur une vue spécifique. Un menu déroulant, dans la boîte d'édition des objets libres, permet de choisir la vue. Ceci permet par exemple,de créer par vue, une page de garde spécifique avec une description de cette vue.
Quand des vues sont définies dans un document et qu'un objet libre est ajouté, par défaut il n'est affiché que dans la vue courante.
Après quelques essais de manipulation, comme cela semble assez efficace, le même protocole d'appartenance à une vue est appliqué aux textes associés à la portée.
Ceci permet par exemple, de positionner un texte indiquant un début de mouvement à des positions différentes selon les vues.
Au passage, la gestion des vues via des fenêtres divisées en sous-fenêtres a été implémentée. Chaque sous-fenêtre peut avoir sa propre vue.
Dans la palette de lancement de musique, une nouvelle icône permet de choisir si l'on veut jouer la totalité du document ou uniquement la vue courante. Si quelqu'un a une idée pour représenter ceci via deux icônes, elle est bienvenue...
|
|
|
| by Didier Guillion | |
|
| |
|
Le module de gestion des vues est maintenant en place et semble fonctionnel. Bien sur il faut tester cela en profondeur car il s'agit d'un remaniement important dans le code. Des questions demeurent. Par exemple, que faire dans le cas où la fenêtre du document est divisée en sous-fenêtres ? Chaque fenêtre doit avoir sa vue ou la vue est commune à toutes les sous-fenêtres ?
Quelques nouveautés ont été introduites :
Le mode "concert" est préservé dans la vue, en espérant que cela répondra à certaines interrogation de l'Atelier.
Les groupes sont préservés (en option) dans chaque vue, ce qui permet par exemple, de définir par vue une position ou une présence de symbole des groupes.
Dans la fenêtre d'édition des vues, on peut reclasser les vues.
On nous a demandé de pouvoir afficher des textes associés aux portées sur un ensemble de vue. Nous avons implémenté une solution simple, si elle ne convient pas on étudiera quelque chose de plus complexe.
Chaque texte associé à une portée peut être défini comme global (il s'applique à toutes les vues) ou local (il ne s'affiche que sur cette portée).
Chaque vue définit si elle tient compte des textes globaux ou non.
Donc, pas de position spécifique à chaque vue par texte ou de texte spécifique à une vue, à voir si cela sera suffisant.
La prochaine session de béta test va être chaude... |
|
|
| by Didier Guillion | |
|
| |
|
La gestion des vues a drastiquement progressé ces jours-ci. De nombreuses interrogations ont été soulevées, auxquelles nous avons essayé de répondre au coup par coup.
Tout d'abord d'un point de vue ergonomique, où loger le menu de gestion et sélection des vues ?
En premier abord, nous l'avions placé dans le menu "Partition". La manipulation en était un peu difficile. Nous l'avons donc déplacé dans le menu général de l'application entre "Portées" et "Instruments", ce qui le met directement accessible :
Le premier élément permet d'ouvrir la boîte d'édition des vues, les autres de sélectionner la vue, sachant qu'il y a toujours une vue générale représentant le document complet.
Peut être prévoir des raccourcis clavier : "vue précédente" et "vue suivante" ?
Le nom de la vue courante est affiché dans le titre de la fenêtre du document :
Ensuite, que gérer via une vue ?
Cela semblait un peu difficile d'anticiper les besoins futurs des utilisateurs.
Nous avons opté pour l'option "Luxe", sachant que qui peut le plus peut le moins...
Une vue est donc définie par son nom et le type d'information qu'elle va mémoriser. Une fois qu'une vue est créée, aucune modification, dans une autre vue, des informations dont elle est propriétaire ne pourra l'affecter. L'utilisateur peut choisir, par vue, les informations à mémoriser.
Mise en page La vue définit tout ce que l'on trouve dans Fichier>Options d'impression : les marges, modes de justification, pied et en-tête de page et tutti quanti. A noter qu'un nouveau "tag" : $V permet d'afficher le nom de la vue en pied et en-tête.
Par exemple, la numérotation des mesures d'une portée pourra changer selon la vue.
Mode gravure Chaque vue a un paramétrage différent du mode gravure. (Partition>Configurer mode gravure)
Configuration graphique de la partition Chaque vue a un paramètrage différent de son aspect graphique. (Partition>Configurer affichage)
Positions fines Par exemple, l'écartement des portées sera différent d'une vue à l'autre ou la taille des mesures. Ou, sur une vue, les paroles seront omises mais pas sur une autre.
Configuration graphique des portées Tout ce que l'on peut configurer via "Portées>Aspect graphique" est configurable selon la vue.
Par exemple, avoir une portée de taille réduite selon la vue dans laquelle on se trouve.
Afficher les tempi et Afficher les nuances globales permettent de reporter sur la première portée affichée de la vue les objets globaux. A noter que seule leur présence est sélectionnable. Pas de position particulière à chaque vue, ceci sera à étudier, mais proposer un positionnement des objets spécifique à chaque vue serait très complexe à implémenter. Pas impossible, mais ardu.
A noter que dans une vue, une portée ne peut se trouver qu'une fois, mais qu'une même portée peut se trouver dans plusieurs vues.
Cela permet de créer par exemple une vue "Chant+Piano", une vue "Chant+Guitare", etc.
L'ordre des portées dans la vue sera toujours l'ordre des portées dans le document.
Un petit plus : dans la boîte d'édition des vues, un bouton permet de créer automatiquement une vue par groupe de portées (portées jointes par une accolade ou portées sans accolade)
Dans le sous-menu "Impression" une nouvelle entrée imprime l'ensemble des vues mises bout à bout, ceci va rendre obsolète le script "Imprimer parties séparées"
La sauvegarde des vues dans le document a été implémentée, il ne reste plus qu'à tester tout cela.
Je garde en mémoire certaines propositions de l'Atelier que je n'ai pas intégrées, soit parce que je n'étais pas convaincu de leur utilité, soit qu'elles nécessiteraient une refonte de plusieurs modules.
Par exemple, pouvoir ajouter un objet libre spécifique à une ou plusieurs vues, choisir la vue dans le Myriad Music Plug-in, etc. A débattre.
Une autre question est que le mode page est censé représenter le document tel qu'il sera imprimé. Il n'est pas possible d'afficher en mode page l'ensemble des vues mises bout à bout, Seul l'aperçu avant l'impression le permet.
Ah! Et une dernière chose, les vues n'affectant que le mode page, elles seront réservées à Harmony Assistant et absentes de Melody.
|
|
|
| by Didier Guillion | |
|
| |
|
Plusieurs améliorations ont été finalisées ou entamées.
- La possibilité de couper les barres d'accroche sous les crochets de tuplets a été finalisée, laissant toute latitude dans les découpes possibles :
- Les appoggiatures en accord ont été mises en place. C'est encore à l'état de prototype, mais ces appoggiatures peuvent d'ores et déjà être affichées et jouées :
- Il nous avait été demandé, lorsqu'on copie/colle un groupe de note et que l'option d'accroche automatique est désactivée, que les barres d'accroche restent identiques à ce qu'elles étaient à l'origine, sans modification. Cela est malheureusement impossible, car les tiges de notes marquées "automatique" vont se recalculer en fonction de la position des notes collées sur la nouvelle portée. Et si certaines tiges changent de sens, les groupes de notes accrochées vont créer un résultat très étrange.
Alors, nous avons mis en place ceci:
les accroches ne sont recalculées que si la portée sur laquelle on colle n'est pas de même type que celle depuis laquelle on a copié les notes.
Ainsi, si on copie et on colle sur une portée en clé de sol, les accroches resteront identiques. Par contre, si on copie depuis une portée en clé de sol et qu'on colle sur une portée en clé de fa, les accroches risquent de se recalculer. |
|
|
| by Olivier Guillion | |
|
| |
|
Nous avons décidé d'attaquer la gestion des "vues". A notre avis, ce sera une fonctionnalité essentielle de cette nouvelle version d'Harmony. Après une analyse "papier", la première tranche des travaux a été entamée : un prototype de l'interface de définition des vues a été construit ainsi que le squelette de gestion des objets attachés à la vue.
Pour l'instant seuls les paramètres de mise en page, ce qui inclut la présence ou non des portées selon la vue est géré. Il nous faut valider ceci en profondeur avant de poursuivre plus avant.
|
|
|
| by Didier Guillion | |
|
| |
|
Ces derniers jours nous avons commencé à éplucher les demandes de l'Atelier Démocratique pour en extraire les plus précises et plébiscitées.
Le mode gravure se voit enrichi de la possibilité de définir les espacements pour les triples et quadruples-croches.
Dans les gestion des groupes de portées, un symbole de groupe (accolade, crochet) peut être associé à une portée unique. Nous avons en effet en main, dans la collection des PDF recueillis pour PDFtoMusic, des exemples de cet acabit. Je ne vois pas trop la signification musicale de faire un groupe avec une seule portée, mais bon...
Par contre il arrive assez souvent que dans de groupes présentants plusieurs portées, et si l'option "masquer les mesures vides" est active, un groupe apparaisse localement avec une seule portée. Une nouvelle option permettra d'afficher le symbole de groupe dans ce cas.
Lorsqu'une note avec double tige était un pointé, il pouvait arriver que deux points consécutifs s'affichent. Un nouvel attribut de la note permettra de choisir une position alternative du point afin d'obtenir deux points l'un en dessous de l'autre.
Le cas particulier d'un coulé démarrant ou finissant sur une note liée est maintenant mieux traité.
Nous travaillons en ce moment sur la possibilité d'afficher un tuplet avec une accroche partielle, comme dans cet exemple :
Parallèlement à ceci MyrScript a été enrichi des nouveaux attributs.
Bien sûr, ceci devra faire l'objet de test sévères lors de la prochaine Béta qui nous prévoyons pour très bientôt. En attendant, n'hésitez pas à consulter fréquemment l' Atelier Démocratique où des choix importants attendent votre avis.
Parmi les demandes qui restent en attente, deux nécessiteraient un gros travail et nous continuons à y réfléchir.
La première serait de pouvoir définir numériquement un grand nombre de paramètres de mise en page.
Je dois avouer ne pas être pleinement convaincu de la nécessité de pouvoir entrer sous forme de nombres ce que l'on peut déjà éditer graphiquement.
La seconde proposerait un ensemble de "vues" de la même partition que l'utilisateur pourrait définir et sélectionner à loisir. Cela pourrait être une alternative efficace au script "Impression des parties séparées".
J'en oublie certainement, n'hésitez pas à les réactiver dans l'Atelier. |
|
|
| by Didier Guillion | |
|
| |
|
Nous travaillons activement en ce moment à l'analyse et au traitement des différentes demande d'améliorations plebiscitées par les utilisateurs. Ceci devrait aboutir, d'ici quelques mois, à la version 9.4 d' Harmony Assistant.
Les principales doléances sont du domaine de la mise en page et de la présentation des documents musical.
Le chantier de ces jours ci à été d'essayer d'améliorer la représentation des liés en mode gravure.
Dans la version actuelle un cas limite donne ceci :
C'est la même mesure, mais l'une avec des liés, l'autre non.
Les notes liés sont affichées en rouge. Les limitations de l'algorithme actuel viennent du fait que la distance entre les notes est calculée selon leur durée et les paramètres d'espacement du mode gravure. Dans le cas de plusieurs notes liées, les têtes sont réparties proportionnellement dans l'espace graphique alloués à la durée totale.
Tout ceci a été repensé : La distance d'affichage nécessaire à un lié est maintenant calculé pour chacune des notes le constituant.
Le même exemple donne :
Ce qui est, je pense, plus satisfaisant : liées ou non, l'espacement des notes reste le même.
Bien sur, ceci pourra entraîner une différence d'aspect des partitions existantes.
|
|
|
| by Didier Guillion | |
|
| |
|
Après avoir examiné les alternatives aux pilotes Twain sur Macintosh, nous avons fait de même sur Windows.
D'après ce que nous avons compris, c'est plus compliqué mais pas nécessairement mieux.
Au tout début, chaque constructeur de scanner fournissait le logiciel d'acquisition spécifique. Puis très rapidement, tout le monde s'est mis à la norme TWAIN.
Ensuite, à partir de Windows 98, Microsoft a introduit StillImage, une architecture de pilote permettant de gérer scanners, appareils photos, et tout autre périphérique permettant de produire une image fixe. Ces pilotes sont censés permettre un plus grand contrôle de l'interface graphique du pilote (boites de saisie, de configuration du scanner) dans un format normalisé. Et surtout, un pilote StillImage peut lancer l'application qui traite son acquisition d'image, alors que pour le TWAIN, c'est à l'application de demander au scanner.
Par exemple, c'est grâce à StillImage que lorsque vous appuyez un bouton sur votre scanner, cela peut lancer l'application d'acquisition correspondante.
TWAIN est donc considéré comme "obsolète" par Microsoft, mais il est demandé aux développeurs de pilotes de conserver la compatibilité.
Donc, les pilotes compatibles StillImage sont censés offrir également un accès compatible TWAIN. Et c'est apparemment le cas.
De toute façons, StillImage n'est disponible que sur Windows 98, ME, XP et probablement Vista, et absent de 95, NT et 2000. Mais d'autres sources le donnent disponible pour 95, 98 et 2000.
Puis, histoire de simplifier tout cela, Microsoft, avec Windows Millenium (donc deux ans après StillImage) a sorti le "standard" WIA (Windows Image Acquisition), qui semble être une surcouche à StillImage.
Là aussi, un pilote WIA est censé assurer une compatibilité TWAIN.
WIA serait disponible sur Windows ME et XP, probablement Vista, et absent de 95,98, 2000 et NT.
Donc, en conclusion, tous ces nouveaux types de pilotes, même s'ils pourraient faciliter l'acquisition d'images, ne sont pas disponibles sur tout les systèmes, et tous les constructeurs ne les ont peut-être pas adoptés.
Donc, plutôt que d'écrire, dans ScanToMusic, un module d'acquisition TWAIN, un autre pour StillImage et un autre pour WIA, avec un test de présence de chacune de ces technologies, il est apparemment plus facile et plus sage de s'en tenir au TWAIN, même s'il peut apparaître un peu spartiate.
Les trois technologies ayant un noyau commun, le TWAIN, on est donc à peu près assuré de respecter une compatibilité maximale en utilisant celui-ci. |
|
|
| by Olivier Guillion | |
| |
|
Nous avons commencé à regarder comment gérer le pilotage des scanners directement depuis le logiciel.
L'expérience OMeR nous avait montré que l'utilisation des accès aux pilotes à la norme TWAIN faisait souvent apparaître des problèmes de compatibilité.
Les pilotes, souvent assez mal écrits, ne suivent quasiment jamais les spécifications complètes de la norme. Ils sont testés par les constructeurs sur les logiciels ténor du marché de l'infographie, et apparemment débuggés spécifiquement sur ceux-ci.
Cela veut dire en gros que si votre logiciel n'accède pas exactement aux mêmes fonctions du pilote du scanner, ou pas dans le même ordre que Photoshop, vous prenez le risque de rencontrer quelques problèmes sympas, qui ne surviendront par exemple qu'avec la version 3.94 du pilote du scanner Agfanon SuperFine 1293 S. 
Sur Mac OS X, le principe annoncé du système est de s'affranchir au maximum des accès direct au périphériques et d'offrir au développeurs des interfaces de haut niveau permettant de piloter les périphériques, par exemple, les scanners.
Nous avons donc téléchargé le kit "Image Capture", présenté comme un sur-ensemble au TWAIN. Cela semblait alléchant, documentations, exemples en Carbon et Cocoa d'acquisition depuis un scanner, tout le toutim. Le kit gère lui-même l'interface d'acquisition et obtenir une image est des plus simple pour le développeur : un simple appel à ICAImportImage et Mac OS X gère les paramètres d'acquisition, la prévisualisation, le choix de la source.
Magnifique ! En théorie... Car les applications d'exemple fournies ne fonctionnent pas et datent de 2005.
Une recherche sur l'Internet montre que les problèmes sont évidents et signalés par tous les développeurs. Sans aucun correctif d'Apple. Il faut dire que le développement d'IPod et d'IPhone a du les épuiser, les pôôvres.
Donc sur Mac OS X nous en resterons aux accès basiques au TWAIN, faute de mieux. |
|
|
| by Olivier Guillion | |
| |
|
Nous avons mis en place, sur notre site, plusieurs protections permettant d'éviter qu'un utilisateur surcharge le serveur. Il faut garder en mémoire que l'accès à une page dynamique (blog, forum), fait tourner un petit programme sur le serveur, et donc que le résultat (la page) n'est pas délivré instantanément.
Imaginons maintenant que quelqu'un demande 200 pages différentes d'un coup, cela va faire tourner 200 "instances" du programme en même temps, surchargeant et ralentissant le serveur. Cela peut arriver lorsque quelqu'un utilise un "aspirateur de site" (voir cet autre article du blog)
Nous avons donc mis en place des barrières, qui bannissent d'office de notre site ces visiteurs indélicats.
Cependant, les moteurs de recherche tels que Google, Yahoo ou Microsoft MSN doivent récupérer toutes les pages du site de temps en temps, et nous ne désirons pas les bannir.
Ces "spiders" devant respecter certains critères, tels que la prise en compte du fichier "robots.txt"ou l'attente d'un certain délai entre deux saisies de pages, ils ne se faisaient pas prendre dans les pièges tendus aux aspirateurs de site personnels. En Anglais, de tels pièges sont appelés "honeypot" (pot de miel).
Mais depuis quelques mois, le robot de MSN, appelé MSNBot, ne tient apparemment plus compte des interdictions qui lui sont adressées, et tombe alors dans le pot de miel.
Résultat, les adresses MSN se retrouvent bannies et interdites d'accès à notre site, ce qui fait qu'à la visite suivante le robot croit que notre serveur ne fonctionne plus.
Cela aura pour conséquence, à terme, de faire disparaître toutes nos pages des recherches par MSN.
Etant donné qu'il me paraît difficile de contacter M. Microsoft pour lui demander gentiment de corriger ce problème, je suppose qu'une fois de plus, nous devrons mettre en place des systèmes spécifiques afin de tout faire fonctionner quand même. C'est l'éternelle histoire du pot de fer contre le pot de miel  |
|
|
| by Olivier Guillion | |
|
| |
|
Le développement de ScanToMusic a repris. Une réorganisation complète des fichiers "source" de l'application a été entamée, afin de classer les différentes fonctions par thème.
Cela devient obligatoire lorsqu'un projet grossit, afin de nous permettre de trouver rapidement l'endroit où chercher telle ou telle fonction lorsque nous avons besoin de l'améliorer ou de la débugger.
Pour donner une idée, un projet comme Harmony Assistant est consitué de près de 700 fichiers source, et PDFtoMusic d'environ 250.
Dans ScanToMusic, nous allons essayer de réutiliser au maximum le temps déjà investi dans PDFtoMusic. Toute la partie d'analyse de "haut niveau" de ce dernier, qui, à partir des commandes graphiques trouvées dans un PDF, reconstitue une partition éditable, va resservir.
Le problème se résume donc ainsi : à partir d'une page scannée, recréer une collection de commandes graphiques (basiquement, tracé de ligne, affichage de caractère et affichage d'image) qui aurait pu être utilisée pour créer la page. En fait, "vectoriser" l'image scannée, mais de manière logique compte tenu des règles d'écriture musicale.
Cela réduit le problème à sa portion congrue, mais ne le résout pas pour autant. Il faut maintenant attaquer les divers modules de détection/reconnaissance qui manquent, et améliorer ceux qui ont été déjà écrits. |
|
|
| by Olivier Guillion | |
|
| |
|
Avec mon nouveau PC, je me suis enfin décidé à franchir avec allégresse un fossé technologique, et j'ai pris un clavier et une souris sans fil.
Auparavant, j'utilisais un bête clavier pas hype du tout, et une souris optique de base.
Au premier abord, tout ceci fonctionne bien. La souris est précise, la frappe sur le clavier est agréable, et on peut les emporter à l'autre bout de la pièce, ça continue à fonctionner. Bon, d'accord, il n'y a aucun intérêt, puisqu'on ne voit plus ce qu'on tape ni le pointeur de la souris, mais c'est fun.
Mais très vite, on se rend compte que toute médaille a son revers. Pour économiser les piles, le clavier ne consomme du courant que lorsqu'on tape sur une touche. Donc, exit les petites lumières du verrouillage des majuscules et du pavé numérique. C'est remplacé par un indicateur "logiciel" en bas de l'écran, et un gros texte vert en surimpression pendant quelques secondes lorsqu'on utilise ces touches de verrouillage. Pas toujours évident, surtout quand on utilise des machines virtuelles en fenêtre, où chacune a un état différent pour ces touches.
r2SULTAT/ PARFOIS JE ME M2LANGE UN PEU LES PINCEAUX ;
Pour la souris, ça se complique encore plus. Précise, d'accord. Mais alourdie par le poids des piles, on ressent l'inertie.
Sinon, ergonomiquement ce n'est pas trop mal, même si, peut-être est-ce poussé par la force de l'habitude, je n'ai jamais utilisé les deux petits boutons supplémentaires au-dessous de la roulette, ni la possibilité de pousser cette roulette vers la droite ou vers la gauche pour faire je ne sais quelle opération.
Mais le plus gros problème, ce sont les piles. Le petit animal en consomme une quantité étonnante, et régulièrement, la petite lumière clignotante qui annonce un niveau faible finit de sécher les derniers mW des alcalines longue durée. Lorsque je déplace la souris sur la table, il me semble même entendre un petit bruit de succion.
Je sais, il y a des modèles avec des batteries, qu'on peut poser sur un support lorsqu'on ne s'en sert pas. Mais je me connais, je sais pertinemment que j'oublierais de la reposer sur sa base (si, si, je le sais, j'ai un téléphone sans fil).
Alors, au prochain changement de pile, je crois que je vais exhumer ma bonne vieille souris filaire. Ca ne devrait pas être pour dans très longtemps, voila la petite lumière qui se remet à clignoter. |
|
|
| by Olivier Guillion | |
|
| |
|
Sur notre serveur Web (l'ordinateur qui vous délivre les pages que vous voyez en ce moment), de petits programmes permettent d'obtenir des pages "dynamiques", c'est-à-dire qui dépendent de choix effectués par l'utilisateur.
Certains scripts tournent depuis si longtemps que nous finissons -presque- par en oublier l'existence. Ainsi, il y a plus de 3 ans, nous mettions en place celui que nous appelons "lostcode", et qui permet aux clients qui ont égaré leur code d'enregistrement de le retrouver automatiquement par e-mail.
Ce petit programme nous fait économiser un temps considérable, en nous évitant de rechercher à la main quotidiennement plusieurs dizaines de demandes.
Il y a donc sur notre serveur une base de données fortement cryptée (au cas où un hacker ne passe par là), contenant les adresses e-mail de nos clients et les codes d'enregistrement associés à chacune d'elles. Nous mettons cette base de données à jour manuellement de temps en temps, ce qui explique que cette recherche automatique risque de ne pas donner de résultat si votre achat date de moins d'un mois.
De même, les personnes qui ont, depuis l'époque de leur achat, changé d'adresse e-mail doivent demander une recherche manuelle qui est généralement traitée rapidement.
Les cas les plus complexes, du type : "j'ai déménagé et changé d'adresse e-mail, je m'appelais M. Sapue, mais j'ai fait changer mon nom - vous imaginez pourquoi - et je m'appelle maintenant M. Sassan", quelques échanges d'e-mails sont nécessaire afin que nous vérifiions que ce n'est pas un voisin ou une connaissance qui essaie de "piquer" le code d'un utilisateur dûment enregistré.
Il y a malheureusement encore énormément de personnes qui n'ont pas connaissance de notre robot "lostcode" et qui écrivent directement au support technique. Nous en recevons plusieurs chaque jour, et dans 99% des cas, le message est du type : "Mon PC est mort, et j'avais tout dessus. J'ai dû reformater mon disque dur, et j'ai perdu le mail contenant mes code,".
Nous les dirigeons alors vers "lostcode". Mais, au risque de nous répéter... faites régulièrement des copies de vos documents et de vos e-mails, ou, mieux, imprimez le mail contenant vos numéros d'enregistrement, rangez-le dans un classeur, et effacez l'e-mail, comme nous le préconisons.
Ce n'est pas de la paranoïa, mais l'espérance de vie d'un disque dur est largement inférieure à celle d'une simple feuille de papier rangée au sec et à l'obscurité, et il nous est arrivé de voir passer des codes d'enregistrement dans des messages envoyés à leur insu par des clients infectés par un virus.  |
|
|
| by Olivier Guillion | |
| |
|
Nous avons travaillé sur des améliorations de la mise en page. Certains changements que nous avons apportés pourront changer la taille des mesures, donc modifier la disposition sur le papier de documents créés avec les versions précédente.
- Les tailles du couple de mesures affectées à un signe de répétition des deux mesures précédentes ont été réglées de manière à obtenir deux mesures de égales. Ceci peut changer la taille d'une ligne de mesures, donc générer des retours à la ligne là où il n'y en avait pas auparavant.
- Lorsque des altérations étaient écrites entre parenthèses, la taille des symboles de parenthèses n'était pas prise en compte dans les calculs permettant d'éviter le chevauchement des symboles. C'est maintenant chose faite, mais cela peut entraîner un changement dans la mise en page de ces mesures.
- Enfin, le paramétrage du mode gravure lors d'un export MYR depuis PDFtoMusic / PDFtoMusic Pro a été corrigé. Les fichier .myr qui seront exportés avec la nouvelle version, une chargés dans Harmony Assistant, se retrouveront en mode gravure, avec les paramètres par défaut. Donc avec la prochaine version de PDFtoMusic, si vous exportez un fichier que vous aviez déjà traité auparavant, son aspect graphique sous Harmony Assistant sera différent.
|
|
|
| by Olivier Guillion | |
|
| |
|
On nous a fait remarquer que la police de caractères utilisée pour montrer les résultats de la reconnaissance n'était pas celle du document original.
En effet, le résultat de la reconnaissance est destiné à montrer le texte qui a été déterminé par l'analyse, et nous avions considéré que l'afficher en police "Times" était suffisant.
Mais, pour l'export XML ou Harmony, le programme choisit une police "standard" qui est supposée être proche de la police originale, encapsulée dans le document PDF. Donc, utiliser cette information dans l'affichage des résultats de la reconnaissance était possible, et permettait d'obtenir un meilleur aspect.
A partir d'un PDF qui contient ceci :
la version actuelle montre ceci :
alors que la prochaine version montrera cela :
ce qui "colle" beaucoup plus à l'aspect original. |
|
|
| by Olivier Guillion | |
|
| |
|
Après plusieurs jours passés à tenter vainement de contacter France Télécom, nous avons enfin réussi à avoir quelqu'un.
Comme nous nous y attendions, nous nous sommes vus opposer un refus catégorique: "Nous connectons là où il y a de la place. L'abonné ne peut pas décider de l'endroit où il est connecté."
On pourrait se satisfaire de cette réponse si la "cartographie" du réseau était claire et bien établie. Mais dans une rue où, dans un même bâtiment, les différentes lignes téléphoniques sont connectées à des noeuds différents, on peut se dire qu'ils choisissent en fonction de leurs petites contraintes techniques (2m de fil à tirer en plus, 2 connexions à faire au lieu d'une) et s'assoient sur la demande de leur client, sans se soucier de ce qui a pu être promis avant.
Donc, pour le déménagement futur de notre ligne principale, même si on nous affirme que cette ligne sera connectée là où on veut, on ne le saura vraiment qu'au moment où ça sera fait.
Il faut trouver une autre solution.
Nous lorgnons donc vers Internet par le câble. J'ai eu quelques échos diffus me laissant à penser que cela ne fonctionne pas très bien, et le fait que les offres les plus puissantes (100 Mbps) aient un quota maximal mensuel de trafic de 50 Go de données me conforte dans le sentiment qu'ils redoutent l'effondrement total de leur réseau si les clients se mettent à s'en servir vraiment.
L'interdiction, dans les Conditions Générales de Vente, d'héberger un serveur sur la connexion câble est proprement ahurissante, et m'amène à penser qu'ils ont vraiment des problèmes.
50 Go, c'est ce que nous avons fait en 8 jours en proposant le CD-ROM en Peer-to-Peer (à propos, doit-on considérer qu'utiliser le P2P équivaut à faire tourner un serveur?). Si cela continuait à ce rythme-là pendant un mois, la même chose sur un abonnement câble à 100Mbps nous reviendrait à 170¤ (30¤ d'abonnement + 14 tranches de 10 Go au-delà des 50 permis, à 10¤ chacune).
Nous allons donc probablement nous orienter sur la formule 30 Mbps à 20¤ par mois, qui, elle, n'est pas limitée par un quota. Et puis de toute façon, après vérification, l'offre 100Mbps n'est pas disponible sur Toulouse
Si l'un d'entre vous a déjà pu tester ce type de connexion à Internet, les opinions, témoignages et avis sont bienvenus. |
|
|
| by Olivier Guillion | |
|
| |
|
|
