de l'usage de \fill-line dans un \score.

Bonjour Nicolas, bonjour tout le monde,

je crois être tombé sur une limitation ennuyeuse de la commande
\markup, et je n'arrive pas à y remédier.

Pour pouvoir centrer un texte horizontalement sur la page (voire
remplir toute la largeur de la page), on utilise \fill-line. D'accord.

Sauf que...

\relative {
    \override Score.PaperColumn #'keep-inside-line = ##t
    c1 d e
    \mark \markup { \fill-line { "toto" "toto" } }
    f \break c d
    e^\markup { \fill-line { "toto" "toto" } }
    f
}

à chaque fois qu'on utilise \fill-line à l'intérieur d'un bloc \score,
la largeur de la ligne est calculée... à partir de l'endroit d'où part
le markup !
Dans l'exemple ci-dessus, un des "toto" disparaît, et le dernier reste
sur la page au prix d'une contorsion inénarrable... Si l'on ne définit
pas 'keep-inside-line, le dernier "toto" disparaît lui aussi.

Est-il possible, lorsque l'on indique \fill-line, de placer les objets
sur la *vraie* largeur de la page, et non en partant du milieu de
nulle part? Question subsidiaire: est-il possible de laisser le markup
(que ce soit avec \mark ou juste avec note^\markup) se balader sans
que ça n'affecte la taille des mesures et l'espacement des notes ?

Est-ce que ça aurait un rapport avec le bug 382 ? Sinon, je m'en vais
faire un rapport de bug détaillé et circonstancié, parce que quand
même c'est pénible zut.

Cordialement,
Valentin

Valentin Villenave a écrit :

Bonjour Nicolas, bonjour tout le monde,

je crois être tombé sur une limitation ennuyeuse de la commande
\markup, et je n'arrive pas à y remédier.

Pour pouvoir centrer un texte horizontalement sur la page (voire
remplir toute la largeur de la page), on utilise \fill-line. D'accord.

Sauf que...

\relative {
    \override Score.PaperColumn #'keep-inside-line = ##t
    c1 d e
    \mark \markup { \fill-line { "toto" "toto" } }
    f \break c d
    e^\markup { \fill-line { "toto" "toto" } }
    f
}

à chaque fois qu'on utilise \fill-line à l'intérieur d'un bloc \score,
la largeur de la ligne est calculée... à partir de l'endroit d'où part
le markup !
Dans l'exemple ci-dessus, un des "toto" disparaît, et le dernier reste
sur la page au prix d'une contorsion inénarrable... Si l'on ne définit
pas 'keep-inside-line, le dernier "toto" disparaît lui aussi.

Est-il possible, lorsque l'on indique \fill-line, de placer les objets
sur la *vraie* largeur de la page, et non en partant du milieu de
nulle part? Question subsidiaire: est-il possible de laisser le markup
(que ce soit avec \mark ou juste avec note^\markup) se balader sans
que ça n'affecte la taille des mesures et l'espacement des notes ?

Est-ce que ça aurait un rapport avec le bug 382 ? Sinon, je m'en vais
faire un rapport de bug détaillé et circonstancié, parce que quand
même c'est pénible zut.

Cordialement,
Valentin

Peut-être une piste pour toi. En supprimant des guillemets tu peux jouer sur l'espace entre les deux toto.
Bricolage tout de même.

valentin.ly (572 Bytes)

···

--
Phil.
Superbonus-Project (Site principal) <http://superbonus.project.free.fr>

Superbonus-Project (Plate-forme d'échange): <http://philippe.hezaine.free.fr>

Je comprends ce que tu veux dire, et ta frustration, mais

1) la ligne ne part pas de nul part comme tu dis, mais du point
d'accrochage du markup, ce qui tout à fait normal.

2) si tu veux changer la largeur de ligne utilisée pour tel markup,
il y a déjà ce qu'il faut (ie surcharger la valeur de la priopriété
line-width). Idem si tu veux décaler le point le plus à gauche.

3) ce que tu veux, c'est une façon de positionner automatiquement
la propriété line-width à la largeur séparant le point d'attache au
bord droit. Bref une nouvelle fonctionnalité, pas une correction de
bogue. Ca me semble très difficilement réalisable, dans la mesure où
les markups sont interprêtés *avant* le calcul de sauts de lignes, et
donc il ne sera pas possible de connaître la distance entre le point
d'attache du markup et le bord droit au moment où le markup est
interprêté.

4) Comme pour toute nouvelle fonctionnalité, il faut en justifier le
besoin, mais à vrai dire j'ai du mal à voir à quoi ça peut servir
en vrai (c'est dur d'être convaincu par un exemple à base de toto).

En relisant ton message, je réalise que j'ai peut-être mal compris ce
que tu voulais : que le markup à un endroit quelconque de la partition,
parte du début de la portée. C'est aussi une nouvelle fonctionnalité
(possiblement réalisable cette fois, mais cela nécessite de modifier
LilyPond, j'entends, la partie C++).

Nicolas

···

Le 25 avr. 08 à 02:35, Valentin Villenave a écrit :

Bonjour Nicolas, bonjour tout le monde,

je crois être tombé sur une limitation ennuyeuse de la commande
\markup, et je n'arrive pas à y remédier.

Pour pouvoir centrer un texte horizontalement sur la page (voire
remplir toute la largeur de la page), on utilise \fill-line. D'accord.

Sauf que...

\relative {
   \override Score.PaperColumn #'keep-inside-line = ##t
   c1 d e
   \mark \markup { \fill-line { "toto" "toto" } }
   f \break c d
   e^\markup { \fill-line { "toto" "toto" } }
   f
}

à chaque fois qu'on utilise \fill-line à l'intérieur d'un bloc \score,
la largeur de la ligne est calculée... à partir de l'endroit d'où part
le markup !
Dans l'exemple ci-dessus, un des "toto" disparaît, et le dernier reste
sur la page au prix d'une contorsion inénarrable... Si l'on ne définit
pas 'keep-inside-line, le dernier "toto" disparaît lui aussi.

Est-il possible, lorsque l'on indique \fill-line, de placer les objets
sur la *vraie* largeur de la page, et non en partant du milieu de
nulle part? Question subsidiaire: est-il possible de laisser le markup
(que ce soit avec \mark ou juste avec note^\markup) se balader sans
que ça n'affecte la taille des mesures et l'espacement des notes ?

Je comprends ce que tu veux dire, et ta frustration, mais

1) la ligne ne part pas de nul part comme tu dis, mais du point
d'accrochage du markup, ce qui tout à fait normal.

"Le milieu de nulle part", c'était juste une formulation :slight_smile:

Je ne dirais pas que c'est "normal", car quand on dit "fill-line", ce
qu'on veut c'est bien remplir la largeur de la page (tout comme quand
on utilise le \markup en top-level). Avec la fonctionnalité existante,
le markup sort de la page, même si on spécifie keep-inside-line...

2) si tu veux changer la largeur de ligne utilisée pour tel markup,
il y a déjà ce qu'il faut (ie surcharger la valeur de la priopriété
line-width). Idem si tu veux décaler le point le plus à gauche.

Oui, c'était le sens de ma question.

3) ce que tu veux, c'est une façon de positionner automatiquement
la propriété line-width à la largeur séparant le point d'attache au
bord droit. Bref une nouvelle fonctionnalité, pas une correction de
bogue. Ca me semble très difficilement réalisable, dans la mesure où
les markups sont interprêtés *avant* le calcul de sauts de lignes, et
donc il ne sera pas possible de connaître la distance entre le point
d'attache du markup et le bord droit au moment où le markup est
interprêté.

Flûte... c'est vraiment dommage ; de même qu'il est dommage qu'on ne
puisse pas utiliser \markuplines dans un bloc \score.

4) Comme pour toute nouvelle fonctionnalité, il faut en justifier le
besoin, mais à vrai dire j'ai du mal à voir à quoi ça peut servir
en vrai (c'est dur d'être convaincu par un exemple à base de toto).

En fait, il y a aussi un problème majeur qui est que keep-inside-line
ne marche pas dans ces cas, et que du coup le texte se barre en dehors
de la page. J'ai rempli un rapport de bug sur
http://code.google.com/p/lilypond/issues/detail?id=609

Si tu n'aimes pas "toto", peut-être que le préambule de la GPL te convaincra :slight_smile:

Mon problème est que j'édite un opéra comprenant beaucoup
d'indications de mise en scène, j'ai donc besoin d'intégrer beaucoup
d'éléments textuels (regarde par exemple la partition de l'Enfant et
les sortilèges, où il y a fréquemment des paragraphes entiers
au-dessus des systèmes, pour indiquer le déroulement de l'action -- ou
bien l'Histoire de Babar, c'est encore plus parlant).

Le code actuel est parfait pour mettre du texte entre des pièces (ton
Couperin le montre bien). Par contre, dès qu'il s'agit d'intégrer
véritablement du texte dans un \score, c'est très limité.

En relisant ton message, je réalise que j'ai peut-être mal compris ce
que tu voulais : que le markup à un endroit quelconque de la partition,
parte du début de la portée. C'est aussi une nouvelle fonctionnalité
(possiblement réalisable cette fois, mais cela nécessite de modifier
LilyPond, j'entends, la partie C++).

Ah, là ça m'intéresse grandement. Est ce que cela nécessiterait de
créer un nouveau grob, ou d'implémenter ça dans l'architecture
existante ? (je me doute que ça sera au-dessus de mes compétences,
mais je suis trop geek pour ne pas vouloir essayer :slight_smile:

Valentin

···

Le 25 avril 2008 21:03, Nicolas Sceaux <****@****> a écrit :

Le 25 avril 2008 21:03, Nicolas Sceaux <****@****> a écrit :

Je comprends ce que tu veux dire, et ta frustration, mais

1) la ligne ne part pas de nul part comme tu dis, mais du point
d'accrochage du markup, ce qui tout à fait normal.

"Le milieu de nulle part", c'était juste une formulation :slight_smile:

Je ne dirais pas que c'est "normal", car quand on dit "fill-line", ce
qu'on veut c'est bien remplir la largeur de la page (tout comme quand
on utilise le \markup en top-level). Avec la fonctionnalité existante,
le markup sort de la page, même si on spécifie keep-inside-line...

Non, fill-line ça veut dire que le markup va avoir la largeur d'une
ligne, que l'on remplit d'un bout à l'autre. Il n'y a pas de raison
pour que ça change le point d'attache. Ensuite, si le markup fait la
largeur d'une ligne, et que son point d'attache n'est pas le plus à
gauche possible, il est impossible que keep-inside-line puisse
fonctionner. Tu ne peux pas tasser suffisamment ce qu'il y a avant
le point d'attache pour que le markup rentre en entier dans la ligne.

Flûte... c'est vraiment dommage ; de même qu'il est dommage qu'on ne
puisse pas utiliser \markuplines dans un bloc \score.

Compte-tenu de la façon dont les markups peuvent être utilisés dans une
pièce à l'heure actuelle (en TextScript ou RehearsalMark), ça n'a pas
de sens.

4) Comme pour toute nouvelle fonctionnalité, il faut en justifier le
besoin, mais à vrai dire j'ai du mal à voir à quoi ça peut servir
en vrai (c'est dur d'être convaincu par un exemple à base de toto).

En fait, il y a aussi un problème majeur qui est que keep-inside-line
ne marche pas dans ces cas, et que du coup le texte se barre en dehors
de la page. J'ai rempli un rapport de bug sur
Google Code Archive - Long-term storage for Google Code Project Hosting.

Ce bug restera certainement lettre morte pour la raison que j'ai donnée
plus haut. S'il n'est pas possible de tasser tout ce qui est à gauche du
d'attache du markup, celui-ci ne pourra pas tenir dans la ligne, puisqu'il
est de la même largeur que la ligne.

Mon problème est que j'édite un opéra comprenant beaucoup
d'indications de mise en scène, j'ai donc besoin d'intégrer beaucoup
d'éléments textuels (regarde par exemple la partition de l'Enfant et
les sortilèges, où il y a fréquemment des paragraphes entiers
au-dessus des systèmes, pour indiquer le déroulement de l'action -- ou
bien l'Histoire de Babar, c'est encore plus parlant).

Le code actuel est parfait pour mettre du texte entre des pièces (ton
Couperin le montre bien). Par contre, dès qu'il s'agit d'intégrer
véritablement du texte dans un \score, c'est très limité.

OK.
Donc tu veux pouvoir insérer des markups entre systèmes d'une même pièce,
comme si c'était des markups top-level. Si tu veux vraiment essayer de voir
ça, regarde comment sont gérés les labels (PageMarker, qui servent à
associer des identifiants à des numéros de page, pour faire référence à
des numéros de page dans des markups, typiquement dans une table des
matières). Le début au moins sera à faire de la même façon : un nouveau type
d'évènement musical, par exemeple InterSystemMarkupEvent, détectés par le
Paper_column_engraver. Puis au niveau page-breaking, quand un InterSystemMarkup
est rencontré, faire en sorte que le markup en question soit inséré entre
deux systèmes. Voilà en très gros.

Nicolas

···

Le 25 avr. 08 à 22:02, Valentin Villenave a écrit :

Non, fill-line ça veut dire que le markup va avoir la largeur d'une
ligne, que l'on remplit d'un bout à l'autre. Il n'y a pas de raison
pour que ça change le point d'attache. Ensuite, si le markup fait la
largeur d'une ligne, et que son point d'attache n'est pas le plus à
gauche possible, il est impossible que keep-inside-line puisse
fonctionner. Tu ne peux pas tasser suffisamment ce qu'il y a avant
le point d'attache pour que le markup rentre en entier dans la ligne.

... ce qui revient à dire qu'on ne peut utiliser \fill-line autrement
qu'en top-level (car personne n'a envie de voir ses markups
disparaître hors de la page). Qu'on appelle ça bug ou non, il faut le
documenter (ça tombe bien, c'est justement moi qui travaille sur cette
partie de la doc).

Ce bug restera certainement lettre morte pour la raison que j'ai donnée
plus haut. S'il n'est pas possible de tasser tout ce qui est à gauche du
d'attache du markup, celui-ci ne pourra pas tenir dans la ligne, puisqu'il
est de la même largeur que la ligne.

Tu noteras que dans ce rapport de bug je ne fais pas intervenir
fill-line, mais je fixe simplement line-width à 40, ce qui laisserait
largement la place de faire tenir les markups à l'intérieur de la
ligne ; d'ailleurs sur les trois systèmes de mon exemple, l'un marche
très bien (curieusement, quand on attache le markup à une note ça
marche à peu près, et quand on l'attache à un MultiMeasureRest ou un
RehearsalMark ça se barre complètement ???).

OK.
Donc tu veux pouvoir insérer des markups entre systèmes d'une même pièce,
comme si c'était des markups top-level. Si tu veux vraiment essayer de voir
ça, regarde comment sont gérés les labels (PageMarker, qui servent à
associer des identifiants à des numéros de page, pour faire référence à
des numéros de page dans des markups, typiquement dans une table des
matières). Le début au moins sera à faire de la même façon : un nouveau
type
d'évènement musical, par exemeple InterSystemMarkupEvent, détectés par le
Paper_column_engraver. Puis au niveau page-breaking, quand un
InterSystemMarkup
est rencontré, faire en sorte que le markup en question soit inséré entre
deux systèmes. Voilà en très gros.

Je vais y jeter un coup d'oeil. C'est exactement ce que je cherche...
et avec cette fonctionnalité, le fait de pouvoir faire appel à
\markuplines reprendrait d'ailleurs tout son sens.

Merci,
Valentin

···

Le 25 avril 2008 22:52, Nicolas Sceaux <****@****> a écrit :