lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Getting width of markup in a music function


From: Carl Sorensen
Subject: Re: Getting width of markup in a music function
Date: Wed, 12 May 2010 03:42:30 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Nathan Reed <nathaniel.reed <at> gmail.com> writes:

> 
> Hello,I'd like to be able to compute the width of a markup inside a 
> music function, 
> so that I can size another element based on the size of the markup.

> I've figured out how to compute the size inside a markup command:
> (ly:stencil-extent (interpret-markup layout props (markup ...)) X)

> This returns a pair of extents, and the difference of the cdr and 
> car is the width. 

There's actually a built-in scheme function (interval-length extent) that will
calculate the width for you, and it's safer to use that than to write your
own function, because the internal representation of an interval could change.

> This works great, but requires one to have the 'layout' and 'props' context,
>  which one does not inside a music function.  Is there some way to 
> combine the two approaches? 

This is a very difficult problem, because music functions are evaluated during
*parsing*.  During parsing, we use the parser and location variables as 
arguments to music functions.  Later, during translation/iteration, 
grobs are created and  markup functions are called.  At that time, the 
layout and props arguments are available.

In general, the way to do this is to write a scheme function that can be 
applied to
a grob, and then put it into the music tree.

I'm sorry that I can't give you good clear answers about this; 
it's still fuzzy to me.
I've been able to do some of it in working with autobeaming.  You can find an
example of this *kind* of work in scm/beam-settings.scm (starting at line 173).
Hopefully somebody can give you a better answer than I've given you.

One of the weaknesses of the LilyPond architecture is that it's very difficult 
to
work with coupling between the parsing and translation stages. 

Good luck with a difficult problem.  If you get a good solution, be sure to 
share
it with us all.

Thanks,

Carl





reply via email to

[Prev in Thread] Current Thread [Next in Thread]