On Mon, 26 Aug 2013 23:57:58 -0700, Mike Solomon <m...@mikesolomon.org> wrote:
On 27 août 2013, at 09:01, "Keith OHara" <k-ohara5...@oco.net> wrote:
On Mon, 26 Aug 2013 22:37:17 -0700, Mike Solomon <m...@mikesolomon.org> wrote:
I'd argue that (2) is better.
What, then, is your argument ?
What I put below - namely, that it is consistent with the previous practice of
stencils separating layout information from graphical content.
That kind of separation is not always good.
We like having the 'staff-padding' between the staff and tempo mark separate from the
text "Adagio", because we usually want to control the padding globally for all
tempo marks.
We would like to keep the space request closely associated with the graphic in
{ d'2-\markup {\italic { c r e s c. } \pad-around #0.5 {- - -} } d' b b }
so that as the font and inter-word space change, the space request follows.
It's true that a new primitive works. But, it seems that, on a more systemic
level, this is not a tenable solution as it would lead to the creation of many
different stencil primitives for different types of padding.
The new stencil primitive in the patch set I have posted now does not assume
any kind of padding. You said the stencil expression should not contain data
influencing layout, so I went back to the patch set that simply turns off
skylines for markup using \with-dimensions and similar.
I withdrew the patches that preserve the space around the "- - -" leader,
because they put data based on the #0.5 into the stencil expression.
Of course I think it would be better to allow box dimensions in the stencil
expression. Boxes are simple enough to enter as coordinates in markup
expressions like \pad-to-box, they are a useful building block for arbitrary
skylines, and the current code builds skylines from the stencil expression.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel