[ Donnez votre avis ! ] Les caractères spéciaux dans LilyPond

Bonjour à tous,

J'ai fait un patch (avec le soutien de Mike) pour qu'il soit moins embêtant d'entrer des caractères spéciaux en LilyPond : http://codereview.appspot.com/4553056/
On entrera les caractères spéciaux en syntaxe HTML.

Ainsi, pour taper un espace fine insécable, on pourra taper "&nnbsp;" au lieu d'avoir à aller le chercher dans une table de caractères ou autre. Pour un s long, "&s;" suffira.

Vous pouvez voir en pièces jointes la liste des caractères spéciaux et l'effet de son utilisation.
Comme vous pouvez le constater, il sera facile d'ajouter des éléments à la liste des caractères spéciaux.
Cela pourra être autre chose qu'un caractère, d'ailleurs. Si on souhaite que tous les "abr." soient remplacés par "abréviation", ça marche aussi.

Seulement, il y a plusieurs hics, d'où la longue discussion autour de ce patch.
Pourriez-vous dire ce que vous pensez de ces points ?

  1. Cela vous sera-t-il utile avec la liste telle qu'elle est ou en la modifiant ?

  2. La liste est-elle trop petite ?
    Après avoir fait une grande liste, j'ai décidé de ne garder que les caractères pas évidents à faire avec un clavier français sous Linux.

  3. Est-il judicieux d'ajouter cette nouvelle syntaxe à LilyPond ?
    Certains pensent qu'il ne devrait pas y avoir de liste par défaut. Que ce serait à chaque utilisateur de créer sa liste.

Exprimez-vous, chaque voix dans un sens ou dans l'autre a de l'importance !

Merci,
Bertrand

3. Est-il judicieux d'ajouter cette nouvelle syntaxe à LilyPond ?

J'ai quelque fois été amené à utiliser des caractères spéciaux, et j'ai effectivement trouvé ça assez lourd pour trouvez sur internet le symbole que je cherchais.
Donc oui, ça nous faliciterai notre vie Lilypondienne.

   Certains pensent qu'il ne devrait pas y avoir de liste par défaut.

Il y a quelques symboles que tout musicien est amené à rencontrer et qui devrait donc faire partie de la syntaxe Lilypond.
Par exemple, dans les partitions, allegro est souvent abrégé en allº
Il faudrait aussi un caractère pour l'abréviation de allegretto. (tto surligné)
&numero pourrait servir aussi (bon peut-être uniquement pour la langue française)
La possibilité de se créer des raccourcis aussi semblent très prometteur.

En résumé, il faudrait pouvoir lister les caractères spéciaux qui font partis de la tradition de la musique.
Dans la liste que tu as donnée, &ordm en fait partie.

Gilles

Il y a quelques symboles que tout musicien est amené à rencontrer et qui devrait donc faire partie de la syntaxe Lilypond.

Par exemple, dans les partitions, allegro est souvent abrégé en allº

Bonne idée ! Je n'avais pas songé à ça.

Il faudrait aussi un caractère pour l'abréviation de allegretto. (tto surligné)

Là ça va se gâter : avec ce système, on ne peut remplacer que des chaînes de caractères par des chaînes de caractères. Pour le cas du "tto", il faudrait créer une 'markup'.

En fait j'ai fait ce patch à l’origine pour modifier globalement des règles de typographie.
Par exemple, si on veut ajouter des ligatures rares quand on utilise une fonte professionnelle.
Ou encore pour modifier tous les " ?" par des "&nnbsp;?" pour mieux correspondre aux règles de typographie française sans se prendre la tête à taper un espace fine insécable avant chaque '?'.
Oui, j'aime beaucoup chipoter...

La question est : doit-on prévoir plein de trucs préfabriqués ? Du genre remplacer '--' par un tiret moyen et '---' par un tiret long, comme dans LaTeX.

Merci,
Bertrand

C'est certainement utile, et activé de base. Les espaces insécables surtout (en
ce qui me concerne).
Et ça peut ouvrir d'autres possibilités insoupçonnées...

Je viens de poster une revue de ton patch. Il me semble y avoir vu des problèmes
(de complexité algorithmique) dans la fonction C++ qui effectue le remplacement,
mais j'ai peut-être mal compris. Comme c'est une fonction qui est appelée sur
chaque chaîne de texte, il faut être faire attention à l'impact sur les perfos
(pas de goulot d'étranglement). As-tu fais des mesures avant/arpès pour voir ?
(avec un gros bouquin plein de chaînes de différentes tailles).

Nicolas

···

Le 7 juin 2011 à 12:51, Bertrand Bordage a écrit :

Bonjour à tous,

J'ai fait un patch (avec le soutien de Mike) pour qu'il soit moins embêtant d'entrer des caractères spéciaux en LilyPond : http://codereview.appspot.com/4553056/
On entrera les caractères spéciaux en syntaxe HTML.

Ainsi, pour taper un espace fine insécable, on pourra taper "&nnbsp;" au lieu d'avoir à aller le chercher dans une table de caractères ou autre. Pour un s long, "&s;" suffira.

Vous pouvez voir en pièces jointes la liste des caractères spéciaux et l'effet de son utilisation.
Comme vous pouvez le constater, il sera facile d'ajouter des éléments à la liste des caractères spéciaux.
Cela pourra être autre chose qu'un caractère, d'ailleurs. Si on souhaite que tous les "abr." soient remplacés par "abréviation", ça marche aussi.

Seulement, il y a plusieurs hics, d'où la longue discussion autour de ce patch.
Pourriez-vous dire ce que vous pensez de ces points ?

1. Cela vous sera-t-il utile avec la liste telle qu'elle est ou en la modifiant ?

2. La liste est-elle trop petite ?
    Après avoir fait une grande liste, j'ai décidé de ne garder que les caractères pas évidents à faire avec un clavier français sous Linux.

3. Est-il judicieux d'ajouter cette nouvelle syntaxe à LilyPond ?
    Certains pensent qu'il ne devrait pas y avoir de liste par défaut. Que ce serait à chaque utilisateur de créer sa liste.

Il faut penser que ça doit fonctionner aussi dans les lyrics, et qu'il n'y ait
pas trop de confusion pour les utilisateurs entre mots-clé -- (hyphenation) et
un possible raccourci -- pour tiret moyen.

···

Le 7 juin 2011 à 21:35, Bertrand Bordage a écrit :

La question est : doit-on prévoir plein de trucs préfabriqués ? Du genre remplacer '--' par un tiret moyen et '---' par un tiret long, comme dans LaTeX.

Bonjour à tous,

Coucou,

J'ai fait un patch (avec le soutien de Mike) pour qu'il soit moins embêtant
d'entrer des caractères spéciaux en LilyPond
: http://codereview.appspot.com/4553056/

Intéressant.

1. Cela vous sera-t-il utile avec la liste telle qu'elle est ou en la
modifiant ?

Pas à moi personnellement (je préfère saisir directement mes
caractères spéciaux en UTF-8). Mais pourquoi pas.

2. La liste est-elle trop petite ?
    Après avoir fait une grande liste, j'ai décidé de ne garder que les
caractères pas évidents à faire avec un clavier français sous Linux.

C'est très arbitraire... Dans l'idéal il nous faudrait une librairie
toute prête de HTMLdecode.

3. Est-il judicieux d'ajouter cette nouvelle syntaxe à LilyPond ?

Justement, je n'en suis pas certain.

    Certains pensent qu'il ne devrait pas y avoir de liste par défaut. Que
ce serait à chaque utilisateur de créer sa liste.

Non : on fait bien des diagrammes d'accords prédéfinis, il n'y a pas
de raison qu'on n'ait pas des caractères spéciaux prédéfinis.

Cela étant, je serais d'accord avec Nicolas : une solution entièrement
en Scheme, dans define-markup-commands.scm par exemple, et qui serait
manuellement invoquée par les utilisateurs.

···

2011/6/7 Bertrand Bordage <****@****>:

2011/6/7 Nicolas Sceaux <****@****>:

C'est certainement utile, et activé de base. Les espaces insécables surtout (en
ce qui me concerne).
Et ça peut ouvrir d'autres possibilités insoupçonnées...

Je viens de poster une revue de ton patch. Il me semble y avoir vu des problèmes
(de complexité algorithmique) dans la fonction C++ qui effectue le remplacement,
mais j'ai peut-être mal compris. Comme c'est une fonction qui est appelée sur
chaque chaîne de texte, il faut être faire attention à l'impact sur les perfos
(pas de goulot d'étranglement). As-tu fais des mesures avant/arpès pour voir ?
(avec un gros bouquin plein de chaînes de différentes tailles).

On discutait l'autre jour avec Graham et Mike des capacités de
typographie de LilyPond, ce serait super d'avoir des règles d'espaces
fines automatiques (à la SPIP) selon la langue de l'utilisateur.

Cordialement,
Valentin.

Alors écrit UNE espace :-p

···

Le mardi 7 juin 2011, Bertrand Bordage a écrit :

un espace fine insécable avant chaque '?'.
Oui, j'aime beaucoup chipoter...

--
Cordialement, Daniel Cartron
« Une chose n'est pas nécessairement vraie parce qu'un homme meurt pour elle.
»
Oscar Wilde

Merci à tous deux pour vos réponses !

Merci particulièrement à Nicolas pour la revue.
J'ai fait un test sur un livre de cantates de 60 pages (plein de paroles et un peu de texte) :
Avec le patch et la liste par défaut : 55 secondes.
Sans le patch : 54 secondes.
Je vais tester avec ton Atys pour voir tout de même. Je démarre mon hexacore !
Tu penses vraiment que ça pourrait aller plus vite en scheme avec des regexps compilés ?
Dans la doc de guile il y a une mise en garde sur la vitesse des regexps, alors j'ai considéré que c'était mieux en c.
Et je ne me suis pas penché sur les regexp en C. Sont-ils optimisés avec de l'assembleur ?
Quoiqu'il en soit, je vais faire les tests nécessaires.
Par ailleurs, je suis tout à fait d'accord avec tes idées pour simplifier l'interface utilisateur.

Merci aussi Valentin. Ta réponse me laisse un peu perplexe : ça me gêne aussi d'ajouter cette syntaxe HTML. Mais comment faire autrement ? Avec des '' ça ne peut pas marcher. Je suis vraiment preneur d'une meilleure idée :o\

On discutait l'autre jour avec Graham et Mike des capacités de
typographie de LilyPond, ce serait super d'avoir des règles d'espaces
fines automatiques (à la SPIP) selon la langue de l'utilisateur.

C'est sûr ! On va être amenés à faire notre petit babel. Et là ça devrait être fait en scheme, car il y aura besoin des fonctionnalités de markup.

Bertrand

Je vais tester avec ton Atys pour voir tout de même. Je démarre mon hexacore !

C'est pas si long :slight_smile: 5-6 minutes avec un intel core duo pas trop péchu.
Par contre il faut de la RAM (genre 4 Go) sinon ça ne finira pas.

Tu penses vraiment que ça pourrait aller plus vite en scheme avec des regexps compilés ?

J'ai dit une connerie à coup sûr, je n'avais pas fait gaffe au fait que la
chaîne manipulée était modifiée sur place.

Nicolas

···

Le 7 juin 2011 à 23:30, Bertrand Bordage a écrit :

C'est pas si long :slight_smile: 5-6 minutes avec un intel core duo pas trop péchu.
Par contre il faut de la RAM (genre 4 Go) sinon ça ne finira pas.

Euh, avec un intel SU4100 (double cœur) et 3Gio de RAM j'ai abandonné au bout d'une demi-heure de compilation... Là je réinstalle ubuntu sur mon gros PC avant de lancer lilypond main.ly.
Bon, pendant ce temps-là je retourne à mon étude de MetaFont.

Pour Atys :
Test effectué plusieurs fois dans les mêmes conditions :

Sans patch : 3 minutes 18.8 secondes
Avec patch : 3 minutes 19.5 secondes

Il n'y a peut-être pas tant de texte que ça dans ton Atys, mais tout de même.
Ça pourrait être pire comme différence !

Bertrand

J'entends simplement par là qu'à mon avis il vaudrait mieux éviter de
changer le comportement par défaut des strings.

Je proposerais soit d'ajouter une commande de markup :

\markup \HTMLdecode "toto &eacute;rit"

soit éventuellement une propriété :

\set Score.HTMLdecode = ##t

\markup "toto &eacute;rit"

L'intérêt de la première solution étant qu'il n'y a aucun overhead
lorsque l'on ne l'utilise pas.

Cordialement,
Valentin.

···

2011/6/7 Bertrand Bordage <****@****>:

Merci aussi Valentin. Ta réponse me laisse un peu perplexe : ça me gêne
aussi d'ajouter cette syntaxe HTML. Mais comment faire autrement ? Avec des
'\' ça ne peut pas marcher. Je suis vraiment preneur d'une meilleure idée

+1 pour la commande de \markup, et j'aime bien l'idée d'adopter la syntaxe d'un langage de balisage connu (ou de pouvoir choisir entre plusieurs langues de balisage). comme ça, les gens pourront copier et coller du texte HTML ou LaTeX dans leurs documents LilyPond. je ne pense pas que \set marcherait dans ce cas puisque \set communique avec les contextes (et donc les graveurs) alors que \markup agit directement sur les textes.

A+,
~Mike

···

On Jun 8, 2011, at 10:18 AM, Valentin Villenave wrote:

2011/6/7 Bertrand Bordage <****@****>:

Merci aussi Valentin. Ta réponse me laisse un peu perplexe : ça me gêne
aussi d'ajouter cette syntaxe HTML. Mais comment faire autrement ? Avec des
'\' ça ne peut pas marcher. Je suis vraiment preneur d'une meilleure idée

J'entends simplement par là qu'à mon avis il vaudrait mieux éviter de
changer le comportement par défaut des strings.

Je proposerais soit d'ajouter une commande de markup :

\markup \HTMLdecode "toto &eacute;rit"

soit éventuellement une propriété :

\set Score.HTMLdecode = ##t

\markup "toto &eacute;rit"

L'intérêt de la première solution étant qu'il n'y a aucun overhead
lorsque l'on ne l'utilise pas.

Cela me paraît tout à fait convenable ! Merci beaucoup Valentin !

L'idéal serait peut-être même de proposer cela comme module upstream
(c'est-à-dire chez Guile). Par exemple en réimplémentant la fonction
php HTMLdecode canonique :
http://svn.php.net/viewvc/php/php-src/trunk/ext/standard/html.c?view=markup

En voici une traduction en JavaScript :
http://www.strictly-software.com/scripts/downloads/encoder.js

Vu que Guile 2.0 sait (plus ou moins) interpréter le JavaScript, ce
serait peut-être une piste ?
http://wingolog.org/archives/2009/02/22/ecmascript-for-guile

Valentin.

···

2011/6/8 Bertrand Bordage <****@****>:

Cela me paraît tout à fait convenable ! Merci beaucoup Valentin !

L'idéal serait peut-être même de proposer cela comme module upstream
(c'est-à-dire chez Guile).

J'aime l'idée, mais je sens que ça ne va pas être facile à mettre en application :smiley:

Le 07/06/2011 23:30, Bertrand Bordage disait :

Merci à tous deux pour vos réponses !

Merci particulièrement à Nicolas pour la revue. [...] Tu penses
vraiment que ça pourrait aller plus vite en scheme avec des regexps
compilés ? Dans la doc de guile il y a une mise en garde sur la
vitesse des regexps, alors j'ai considéré que c'était mieux en c. Et
je ne me suis pas penché sur les regexp en C. Sont-ils optimisés avec
de l'assembleur ? Quoiqu'il en soit, je vais faire les tests
nécessaires. Par ailleurs, je suis tout à fait d'accord avec tes
idées pour simplifier l'interface utilisateur.

Merci aussi Valentin. Ta réponse me laisse un peu perplexe : ça me
gêne aussi d'ajouter cette syntaxe HTML. Mais comment faire autrement
? Avec des '\' ça ne peut pas marcher. Je suis vraiment preneur d'une
meilleure idée :o\

On discutait l'autre jour avec Graham et Mike des capacités de
typographie de LilyPond, ce serait super d'avoir des règles
d'espaces fines automatiques (à la SPIP) selon la langue de
l'utilisateur.

C'est sûr ! On va être amenés à faire notre petit babel. Et là ça
devrait être fait en scheme, car il y aura besoin des fonctionnalités
de markup.

La babelilypondisation est peut-être une piste intéressante à suivre :
en plus des ligatures absentes par défaut, et pour lesquelles Nicolas
nous a fourni le code, certaines règles ne sont pas forcément les mêmes
selon la langue.

Quant à la technique de saisie, je n'ai pas de préférence.

@+
Jean-Charles

Il y en a pas mal à la fin, et puis, des paroles. J'ai sur mon repo github
une autre version avec le livret complet (sur 30 pages), mé bon...
En ce qui me concerne, cette mesure me convient tout à fait !

J'ai repensé à tout ça, et sortir la fonction de remplacement de texte
côté Scheme n'offre rien du tout. Tu peux ignorer mes remarques, à part
celle sur la façon de faire une boucle sur une liste qui n'est pas
idiomatique.

Nicolas

···

Le 8 juin 2011 à 03:38, Bertrand Bordage a écrit :

Pour Atys :
Test effectué plusieurs fois dans les mêmes conditions :
Sans patch : 3 minutes 18.8 secondes
Avec patch : 3 minutes 19.5 secondes

Il n'y a peut-être pas tant de texte que ça dans ton Atys, mais tout de même.
Ça pourrait être pire comme différence !

@Jean-Charles :
C'est une de mes grandes envies depuis un moment (comment ça, j'ai des goûts bizarres ?). Il faudra aussi créer un truc pour les hyphenations automatiques.
Pour les ligatures, hélas, on ne peut pas faire grand chose. Century Schoolbook ne contient que fi et fl. Quand on met une fonte avec d'autres ligatures communes comme ffi, LilyPond fait les ligatures automatiquement. Mais pas pour les ligatures rares.
Hélas on ne peut rien faire pour ces dernières car chaque fonte les place à des emplacement différents.

@Nicolas :
Ok ! Merci d'avoir pris le temps d'étudier tout ça. Je ferai un nouveau patch set d'ici la fin de semaine.

Bertrand

  1. Cela vous sera-t-il utile avec la liste telle qu'elle est ou en la
    modifiant ?

Ce qui me manque dans ta liste, c'est :

  • le e dans l'o œ,
  • la jolie apostrophe ’
  • les majuscules accentuées É À Ç
  • les guillements français « » ou anglais “ ”

Merci,

Frédéric